| 1 |
On 08/15/2016 03:15 PM, Dirkjan Ochtman wrote: |
| 2 |
> On Mon, Aug 15, 2016 at 3:03 PM, Kristian Fiskerstrand <k_f@g.o> wrote: |
| 3 |
>> Could you please elaborate a bit? In particular from perspective of (i) |
| 4 |
>> integration into current workflow, (ii) complexity in application |
| 5 |
>> maintenance/hosting (iii) cost/benefit considerations |
| 6 |
> |
| 7 |
> Well, I think stabilization (and, to some extent, keywording) is a |
| 8 |
|
| 9 |
Thank you for elaborating |
| 10 |
|
| 11 |
> very different process from handling bugs and feature requests. It |
| 12 |
> would be great if we had tooling that focuses on these instead of |
| 13 |
> trying to fit into the bug tracker. It would entail a different |
| 14 |
|
| 15 |
I'm not sure I agree on this point, my perspective is the state of the |
| 16 |
stable tree is exactly dependent on it being considered as part of the |
| 17 |
regular workflow of developers, which has at least been implied in the |
| 18 |
past[0] - resulting in e.g InVCS. |
| 19 |
|
| 20 |
Part of the discussion in that case is the number of developers running |
| 21 |
full testing (~arch) and might not care too much about the state of the |
| 22 |
stable tree, and having stabilization as part of the specific workflow |
| 23 |
will help the state of the stable tree by requiring the developer to |
| 24 |
care about it. |
| 25 |
|
| 26 |
> workflow, obviously, but I think that's a plus in this case, and we |
| 27 |
> could make sure we have the command-line tools to make it easy to work |
| 28 |
> with. |
| 29 |
> |
| 30 |
|
| 31 |
as long as it doesn't become a disconnect to maintainer's |
| 32 |
responsibilities. The state of stable tree isn't a separate issue that |
| 33 |
belongs with the arch teams; it is an integrated and important part of |
| 34 |
maintaining any package to begin with. |
| 35 |
|
| 36 |
> Development/maintenance/hosting is an issue, though it's a bit hard to |
| 37 |
> say something definitive about it before there's more of a plan of how |
| 38 |
> such a tool could work. It's enough of a pain for me that I could see |
| 39 |
> myself investing some time in development. |
| 40 |
> |
| 41 |
> Perhaps some kind of middle ground would be to handle this stuff in a |
| 42 |
> separate Bugzilla product, and then making sure we have some tooling |
| 43 |
> around that to better present the data. |
| 44 |
|
| 45 |
See comment in previous chapter |
| 46 |
|
| 47 |
> |
| 48 |
> Cheers, |
| 49 |
> |
| 50 |
> Dirkjan |
| 51 |
> |
| 52 |
|
| 53 |
Notes: |
| 54 |
[0] but I don't recall any specific policies / council meeting summaries |
| 55 |
on it offhand and don't have time to search but feel free to provide it |
| 56 |
if easily available to anyone - the last discussion I see on this was |
| 57 |
https://archives.gentoo.org/gentoo-dev/message/df7dee4ad61fe1c9bac866d15e0babfb |
| 58 |
|
| 59 |
|
| 60 |
-- |
| 61 |
Kristian Fiskerstrand |
| 62 |
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net |
| 63 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives