Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

[james]

On 08/15/2016 12:37 AM, Kent Fredric wrote:
> On Mon, 15 Aug 2016 16:29:43 +1200
> Kent Fredric <kentnl@g.o> wrote:
>
>>>  * The b.g.o workflow, bugs should not be considered fixed until the
>>>    fix has reached the stable tree. Today the InVCS keyword exists for
>>>    this purpose, but it is used to varying degree amongst developers.
>>>    Will a workflow change to introduce a new status, e.g RESOLVED
>>>    NeedsStable (name for illustration purpose only) incentivize
>>>    developers to not close bugs before it is fixed?
>
> Also, if its already stable, the fix may go directly into stable.
>
> Does this need to also spend time in "NeedsStable" state?
>
> I'd assume not. But this is going to need clear definitions and lots of usecase
> writeups.
>

As a user, on the pathway to dev level comprehension and gentoo-skills, 
*documentation is king*. So put what is universal (on the processes) 
into a master document and the slight project variations, is a 
subordinate "group" or "project" document, so that flexibility is 
afforded to the collectives. Some devs do not like this level of 
organization, but, it is for the good of the entire gentoo community, so 
when one wants/needs to know, they can just read about it. Perhaps those 
in proxy-maint in  a given project, could be the front line maintainers 
of these subordinate documents, as they are the ones most sensitive to 
the accuracy needs for these documents.


This effort would drastically 'settle the peace' because devs, for what 
ever reason, that need to attend to codes in areas they normally do not 
work on, can quickly refresh the main points of culture and guidance
on a given project and thus function more cohesively as an extended if 
not transient team member. I.E. less ruffled feathers, imho. These 
efforts will greatly facility the ability of gentoo to expand the number 
of dev, working in a productive manner, by avoiding conflict and yet 
letting the smaller collectives tune the rules, to their liking and 
under the tutelage of the Lead(s) on that (project) collective. This 
also empowers folks to 'take ownership' which leads to better quality 
and increases in productivity, imho.


The ability for other members of the gentoo community to read and learn, 
at their own pace:: *priceless*.


ymmv,
James