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

[Daniel Campbell]

On 10/04/2016 10:25 AM, Ian Stakenvicius wrote:
> On 20/08/16 08:30 PM, Daniel Campbell wrote:
>> On 08/15/2016 12:42 PM, Rich Freeman wrote:
>>> On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel  
>>> wrote:
 1) Stabilization is a simpler and much more formalized process compared to
 normal bug resolution.
 * There is one version to be stabilized.
 * One precise package version
>>>
>>> Can you clarify what this means?  Do you mean that at any time only
>>> one version of any particular package/slot is marked stable?
>>>
>>> That seems like it would be problematic for ranged deps.  Granted,
>>> those are problematic in and of themselves since they can create
>>> conflicts that are hard to resolve.  However, this extends conflicts
>>> between package you might not want to install at the same time to
>>> situations where you don't even need both of the conflicting packages.
>>>
>> I believe he's just talking about a per-bug or per-stablereq basis. So
>> each version gets its own opportunity to have bugs surface or
>> stabilization issues instead of attempting to stabilize a bunch of
>> versions at once.
>>
>> (Correct me if I'm wrong; I don't see the value of a single stable
>> version for each package and it would create a lot of noise in git log)
>>
> 
> Even though some projects (mozilla, for instance) do request
> stabilizations of multiple packages and/or versions in a single go,
> that doesn't mean we should and I have no issues changing our process
> to something more atomic.
> 
> What should be noted here is that if we work towards adopting new
> tools or methods here, we absolutely need to do so in a way that is
> beneficial to the workflow of our AT's, especially those that perform
> large numbers of stabilizations like ago.  If this new process doesn't
> make things at least incrementally easier for them, it needs to be
> re-thought.
> 
> 
What sort of things would fit best into AT workflow? Different bug
states make it easier to filter bugs for ourselves. Is there another
mechanic you'd rather see?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

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

[Ian Stakenvicius]

On 20/08/16 08:30 PM, Daniel Campbell wrote:
> On 08/15/2016 12:42 PM, Rich Freeman wrote:
>> On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel  
>> wrote:
>>> 1) Stabilization is a simpler and much more formalized process compared to
>>> normal bug resolution.
>>> * There is one version to be stabilized.
>>> * One precise package version
>>
>> Can you clarify what this means?  Do you mean that at any time only
>> one version of any particular package/slot is marked stable?
>>
>> That seems like it would be problematic for ranged deps.  Granted,
>> those are problematic in and of themselves since they can create
>> conflicts that are hard to resolve.  However, this extends conflicts
>> between package you might not want to install at the same time to
>> situations where you don't even need both of the conflicting packages.
>>
> I believe he's just talking about a per-bug or per-stablereq basis. So
> each version gets its own opportunity to have bugs surface or
> stabilization issues instead of attempting to stabilize a bunch of
> versions at once.
> 
> (Correct me if I'm wrong; I don't see the value of a single stable
> version for each package and it would create a lot of noise in git log)
> 

Even though some projects (mozilla, for instance) do request
stabilizations of multiple packages and/or versions in a single go,
that doesn't mean we should and I have no issues changing our process
to something more atomic.

What should be noted here is that if we work towards adopting new
tools or methods here, we absolutely need to do so in a way that is
beneficial to the workflow of our AT's, especially those that perform
large numbers of stabilizations like ago.  If this new process doesn't
make things at least incrementally easier for them, it needs to be
re-thought.




signature.asc
Description: OpenPGP digital signature

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

[Daniel Campbell]

On 08/15/2016 12:42 PM, Rich Freeman wrote:
> On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel  
> wrote:
>> 1) Stabilization is a simpler and much more formalized process compared to
>> normal bug resolution.
>> * There is one version to be stabilized.
>> * One precise package version
> 
> Can you clarify what this means?  Do you mean that at any time only
> one version of any particular package/slot is marked stable?
> 
> That seems like it would be problematic for ranged deps.  Granted,
> those are problematic in and of themselves since they can create
> conflicts that are hard to resolve.  However, this extends conflicts
> between package you might not want to install at the same time to
> situations where you don't even need both of the conflicting packages.
> 
I believe he's just talking about a per-bug or per-stablereq basis. So
each version gets its own opportunity to have bugs surface or
stabilization issues instead of attempting to stabilize a bunch of
versions at once.

(Correct me if I'm wrong; I don't see the value of a single stable
version for each package and it would create a lot of noise in git log)

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Raymond Jennings]

Strict compliance with the handbook would seem to forbid having a stable
package depend on an unstable package, and if you have to downgrade a
dependency and it causes a cascade, I would opine, that, perhaps, the
package in question should not have been stabilized to begin with.

That said, I as a user have noticed that packages tend to stall in
stabilization for awhile.

What about a script that can rank ~arch keyworded packages by some sort of
priority?

Maybe point out which one has the most reverse dependencies?  Or which one
has been stuck in ~arch the longest?  Or some sort of scoring mechanism
that can flag the most urgently needed stabilizations?

Come to think of it, I think debian has a system that flags the most
popular packages.  Does gentoo have a way to note what packages are most
important?

On Wed, Aug 17, 2016 at 1:50 AM, Pacho Ramos  wrote:

> El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
> > [...]
> > Well, I wasn't suggesting that breaking the depgraph is great.  Just
> > that I think it is better than calling things stable which aren't.
> >
> > A better approach is a script that does the keyword cleanup.
> >
> > So, if you want to reap an ebuild you run "destabilize
> > foo-1.2.ebuild".  It searches the tree for all reverse deps and
> > removes stable keywords from those.  Then you commit all of that in
> > one commit.
> >
> > If you want to be extra nice you stick it in a pull request in github
> > and point it out to the arch team and ask them if they're sure they
> > don't want to stabilize your package...  :)
> >
>
> Well, the reason I was suggesting to allow maintainers to stabilize
> after the 90 days timeout over *current* policy of allowing the
> dekeywording is that the dekeywording is completely unrealistic to do
> as some packages have a huge amount of reverse deps. Even with the
> script (and, well, I would like to see that script existing... because
> we are having this issue for ages, and that is the reason that nobody
> is moving things to testing actively), you will find many many cases of
> packages having so many reverse dependencies that if you try to move it
> to testing it becomes soon a hell.
>
> The main issue is that, once you start dekeywording one package, you
> jump to, for example, dekeywording another 3 reverse deps, then you
> need to continue with the reverse deps of that reverse deps... and at
> the end, it's completely impossible to manage it (I still remember how
> hard was to move to testing most of Gnome... and we even were lucky as
> we were able to do that with the jump to Gnome3).
>
> Then, my point it to allow the maintainer to keep stabilizing it
> *after* the 90 days timeout. If after that time, the arch team is
> unable to even reply, nobody has reported any build/runtime issues
> related with that arch, I would go ahead. Otherwise, it looks pretty
> evident to me that that arch is near to be used by nobody and maybe it
> should be moved completely to testing (or most of their packages moved
> to testing and only the core apps in stable).
>
>
>
>

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Daniel Campbell]

On 08/15/2016 03:21 AM, Kristian Fiskerstrand wrote:
> Better than developers marking it fixed without it hitting stable as too
> many are doing today.
Totally guilty of that one, sorry!

I think adding a status would be great. We could have CONFIRMED and even
RESOLVED still, but the goalpost could be moved to CONFIRMED/STABLE
instead of CONFIRMED/RESOLVED. Pushing the fix to git can still resolve
a problem, but the STABLE status would mean that the package that fixed
the bug then hit stable.

The problem with this, however, is that it turns every bug into the
subject of the bug *and* a stabilization bug. Are we to get rid of
stabilization bugs altogether? Or do we keep stabilization bugs and
merely update all the dependent bugs to CONFIRMED/STABLE once
stabilization happens?

A workflow suggestion would be great, because I care about fixing my
bugs and getting them to users as fast as what's reasonable.

(That said I have a busy weekend ahead of me with lighttpd...)

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Pacho Ramos]

El mié, 17-08-2016 a las 09:07 -0400, Rich Freeman escribió:
> I'm not sure I agree.  If it is scripted, then isn't it just a few
> more cpu cycles?

Well... until I see that script, I won't trust it. We are for a long
time supposedly allowing people to move things to testing after 90 days
and that is not working at all because of that. Simply try to go to our
current pending gnome stabilization, and you will see how difficult
does it turn (for example, another issue is with the optional reverse
dependencies, that would require to use.mask some USE flags for some
packages in some arches).

Once that script is ready... I am unsure about why are we even
discussing this as, after that dekeywording task can be feasible after
90 days, the picture in all exotic arches with change so much that we
would need to meet again in some months to evaluate the result 

The problem is that I don't think that is really feasible... and
looking to that script still being unavailable and we still discussing
about how to improve this makes me think it's a harder issue to achieve
:(

> Why even have a stable keyword?  What does it even mean if everything
> gets stabilized in 90 days whether it is tested or not, or whether it
> even builds?
> 
Well, personally I don't think why many of that arches are supposedly
still having a reliable stable tree. Most of them are relying on Ago
doing most of the work (that is mostly buildtime testing... and I have
no issue with that, as adding also runtime testing to all the packages
and arches is completely unrealistic). Anyway the "stable keyword"
would still give the packages 90 days of being in the tree (at least)
for the hypothetical bugs to appear. If they don't appear, maybe they
don't exist (like in most cases) or, in the worst case, that arches are
so few used that I am sure the burden would be high enough.

 
> Take the degenerate case.  Suppose an arch team is completely AWOL.
> If we go with my route and de-stabilize packages then you end up with
> an arch that is de-facto experimental with no stable packages (or
> maybe @system only) after some period of time.  If we instead
> stabilize anything after 90 days if there is no response then the
> AWOL
> arch team ends up having more stable packages than any other arch,
> because they're the only ones not reporting bugs.

Well, if we have the script, I am the first one preferring your
route... but that route is of dekeywording stuff is allowed for a long
time and we still have nothing, then, until that script is even a
draft, I don't consider it a real option.

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Rich Freeman]

On Wed, Aug 17, 2016 at 4:50 AM, Pacho Ramos  wrote:
>
> El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
> > [...]
> > Well, I wasn't suggesting that breaking the depgraph is great.  Just
> > that I think it is better than calling things stable which aren't.
> >
> > A better approach is a script that does the keyword cleanup.
> >
> > So, if you want to reap an ebuild you run "destabilize
> > foo-1.2.ebuild".  It searches the tree for all reverse deps and
> > removes stable keywords from those.  Then you commit all of that in
> > one commit.
> >
> > If you want to be extra nice you stick it in a pull request in github
> > and point it out to the arch team and ask them if they're sure they
> > don't want to stabilize your package...  :)
> >
>
> Well, the reason I was suggesting to allow maintainers to stabilize
> after the 90 days timeout over *current* policy of allowing the
> dekeywording is that the dekeywording is completely unrealistic to do
> as some packages have a huge amount of reverse deps. Even with the
> script (and, well, I would like to see that script existing... because
> we are having this issue for ages, and that is the reason that nobody
> is moving things to testing actively), you will find many many cases of
> packages having so many reverse dependencies that if you try to move it
> to testing it becomes soon a hell.
>

I'm not sure I agree.  If it is scripted, then isn't it just a few
more cpu cycles?

Sure, I get that de-stabilizing one package could trigger
de-stabilizing 200 others, but the list is finite, and the algorithm
is reasonably straightforward.  Just use the portage API and you can
find all the reverse deps for any package, using the same logic
portage will use.  Granted, I could see it getting a little tricky
because you might be de-keywording multiple versions at once, and
those impact multiple versions at once, and you need to trace all of
those, preferably pruning the search space for duplicates as you go.
It actually sounds a little like my iterative map-reduce I used to
compare the git and cvs trees (map expands the dep tree by one level
from all the known impacted packages, reduce prunes duplicates, then
repeat until you've found all the leaves, probably by storing a tag in
the parent record when you've mapped it and found no children so that
future maps skip it).

But, I won't disagree that somebody has to write it.

>
> Then, my point it to allow the maintainer to keep stabilizing it
> *after* the 90 days timeout. If after that time, the arch team is
> unable to even reply, nobody has reported any build/runtime issues
> related with that arch, I would go ahead. Otherwise, it looks pretty
> evident to me that that arch is near to be used by nobody and maybe it
> should be moved completely to testing (or most of their packages moved
> to testing and only the core apps in stable).
>

Why even have a stable keyword?  What does it even mean if everything
gets stabilized in 90 days whether it is tested or not, or whether it
even builds?

Take the degenerate case.  Suppose an arch team is completely AWOL.
If we go with my route and de-stabilize packages then you end up with
an arch that is de-facto experimental with no stable packages (or
maybe @system only) after some period of time.  If we instead
stabilize anything after 90 days if there is no response then the AWOL
arch team ends up having more stable packages than any other arch,
because they're the only ones not reporting bugs.

The whole point of a stable branch is that it is curated.  It is
supposed to "just work."  If changes make it in without any testing,
then it loses that quality, and it just becomes a stale testing
branch.  I'd rather have stable be @system only so that you always
have a system that at-least boots and then go from there, or maybe
leave it to individual projects to maintain their own stable branches
with their own QA, than have stuff just dumped in stable without even
a build test, let alone some kind of runtime testing.

I'd even buy that maybe we don't need stable (though I think that the
minor arches are where it is most needed, at least for @system so that
users can actually boot their stage3s).  However, it makes no sense to
go to the trouble to have a stable branch and not do anything to
ensure it is actually stable.

-- 
Rich

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Pacho Ramos]

El lun, 15-08-2016 a las 15:01 -0500, William Hubbs escribió:
> [...]
>  This works unless you are talking about packages in @system.
> I do see core packages on these arches also languish in ~ for months
> with open stable requests.
> 
> The only way to handle one of those would be to remove the old
> version
> and let their deptree break until they catch up.
> 
> William
> 

But, anyway, I would still put a timeout for allowing us to go ahead
and stabilize, otherwise we have the huge risk of having the users of
that arches facing a broken deptree for weeks/months until that teams
are able to stabilize the packages (and they needing to *manually*
keyword new versions of the packages... and hence needing to move
exactly to the same versions we (maintainer) could have stabilized
after the 90 days period) 

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Pacho Ramos]

El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
> [...]
> Well, I wasn't suggesting that breaking the depgraph is great.  Just
> that I think it is better than calling things stable which aren't.
> 
> A better approach is a script that does the keyword cleanup.
> 
> So, if you want to reap an ebuild you run "destabilize
> foo-1.2.ebuild".  It searches the tree for all reverse deps and
> removes stable keywords from those.  Then you commit all of that in
> one commit.
> 
> If you want to be extra nice you stick it in a pull request in github
> and point it out to the arch team and ask them if they're sure they
> don't want to stabilize your package...  :)
> 

Well, the reason I was suggesting to allow maintainers to stabilize
after the 90 days timeout over *current* policy of allowing the
dekeywording is that the dekeywording is completely unrealistic to do
as some packages have a huge amount of reverse deps. Even with the
script (and, well, I would like to see that script existing... because
we are having this issue for ages, and that is the reason that nobody
is moving things to testing actively), you will find many many cases of
packages having so many reverse dependencies that if you try to move it
to testing it becomes soon a hell. 

The main issue is that, once you start dekeywording one package, you
jump to, for example, dekeywording another 3 reverse deps, then you
need to continue with the reverse deps of that reverse deps... and at
the end, it's completely impossible to manage it (I still remember how
hard was to move to testing most of Gnome... and we even were lucky as
we were able to do that with the jump to Gnome3).

Then, my point it to allow the maintainer to keep stabilizing it
*after* the 90 days timeout. If after that time, the arch team is
unable to even reply, nobody has reported any build/runtime issues
related with that arch, I would go ahead. Otherwise, it looks pretty
evident to me that that arch is near to be used by nobody and maybe it
should be moved completely to testing (or most of their packages moved
to testing and only the core apps in stable).

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kent Fredric]

On Mon, 15 Aug 2016 09:37:33 -0400
Rich Freeman  wrote:

> 
> Today developers tend to use views that exclude resolved bugs.
> Perhaps tomorrow they'll tend to use views that exclude bugs that are
> resolved or waiting for stabilization.  Perhaps these views will
> become the defaults.

Can bugzilla have a selection of templated parameterized searches? 

I Know you can have predefined searches and predefined shared searches, but
I didn't notice any parameterizable ones.

Subsequently, I've been getting around this using 

https://metacpan.org/release/BZ-Client

And some perl scripts that help me out.

Pre-defined query types I have are:

"Stabilizing mode: Find packages I mention that have changed in  time"

"Keywording mode: Find packages I mention that have either STABLEREQ or 
KEYWORDREQ keywords in all time"

Those names I use are not very descriptive, because "Keywording mode" is more 
used for research into
why keywords are what they are than it is for actual keywording, and its for 
helping determine which packages
are "Redundant and can be pruned".

Importantly, these searches also search /comment text/, because stablereqs and 
keyword reqs for specific
packages can't be identified by their SUBJECT on a regular basis.

 KEYWORDING=1 perl ~/bin/bzquery.pl ExtUtils::MakeMaker
Searching for "(?i)ExtUtils(::|-)MakeMaker"
3 entries in summary
~ 6yr  3mo   317877 -   FIXED RESOLVE : Please keyword 
perl-core/ExtUtils-MakeMaker (and perl-core/ExtUtils-Command 
perl-core/ExtUtils-Manifest perl-core/ExtUtils-Install) (updated: ~ 6yr  3mo )
~ 6yr  3dy   330387 -   FIXED RESOLVE : Please stabilize 
virtual/perl-ExtUtils-MakeMaker and deps (updated: ~ 5yr 11mo )
~ 4yr  6mo   400469 - WONTFIX RESOLVE : Please stabilize 
=perl-core/ExtUtils-MakeMaker-6.590.0 (updated: ~ 4yr  5mo )
10 entries in description
~ 9yr  2mo   180246 -   FIXED RESOLVE : Please stabilize 
=dev-perl/PDF-Create-1.04 (was: dev-perl/PDF-Create-0.06.1b corrupted console 
output during compile) (updated: ~ 6yr  8mo )
~ 6yr  2mo   321235 -   FIXED RESOLVE : Please stabilize 
dev-perl/GnuPG-Interface-0.42 (updated: ~ 5yr 11mo )
~ 6yr  2dy   329525 -   FIXED RESOLVE : Please stabilize 
=dev-perl/FileHandle-Unget-0.16.23 (updated: ~ 5yr 10mo )
~ 5yr  5mo   357599 - WONTFIX RESOLVE : Please (re-)keyword 
perl-core/Module-Build, perl-core/CPAN-Meta, perl-core/Version-Requirements, 
perl-core/Module-Metadata, perl-core/Perl-OSType (updated: ~ 2yr  3mo )
~ 4yr  7mo   395297 -   FIXED RESOLVE : Please stabilize 
=dev-perl/Moose-2.40.200 (updated: ~ 4yr  4mo )
~ 4yr  4mo   410367 -   FIXED RESOLVE : Please stabilize 
=dev-perl/XML-Parser-2.410.0 (updated: ~ 4yr  2mo )
~ 4yr  2mo   418803 -   FIXED RESOLVE : Please stabilize 
=dev-perl/DateTime-TimeZone-1.460.0 and deps (updated: ~ 3yr 11mo )
~ 3yr  6mo   456568 -   FIXED RESOLVE : Please stabilize 
=dev-perl/DateTime-TimeZone-1.560.0 (updated: ~ 3yr  3mo )
~ 2yr  4mo   504786 -   FIXED RESOLVE : =dev-lang/perl-5.18.2-r1 and related 
virtuals stabilization (updated: ~ 1yr  9mo )
~ 8mo  5dy   567482 - CONFIRM : dev-lang/perl-5.22.2 perl-core/* 
virtual/perl-* stabilization (updated: ~ 2Hr 38Ms )


 STABILIZING=1 perl ~/bin/bzquery.pl ExtUtils::MakeMaker
Searching for "(?i)ExtUtils(::|-)MakeMaker"
0 entries in summary
4 entries in description
~ 3yr 10mo   435304 - WORKSFO RESOLVE : app-portage/g-cpan-0.16.* generates 
broken ebuild depending on perl-g-cpan instead of dev-perl modules (updated: ~ 
4dy  9Hr )
~ 8mo  5dy   567482 - CONFIRM : dev-lang/perl-5.22.2 perl-core/* 
virtual/perl-* stabilization (updated: ~ 2Hr 41Ms )
~ 2mo  4dy   585048 - CONFIRM : sys-apps/texinfo-6.1 has weird build 
system, likely causing unneeded perl-cleaner rebuilds (updated: ~ 1dy 12Hr )
~ 1mo  2dy   586718 - WORKSFO RESOLVE : app-misc/screen-4.4.0 - makeinfo 
./screen.texinfo -o screen.info : Can't locate Locale/Messages.pm in @INC (you 
may need to install the Locale::Messages module) (updated: ~ 1mo  4dy )

^^^ Doing anything like this on bugzilla directly is self abuse at present.





pgpwhzMbQK7xA.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Mon, 15 Aug 2016 21:30:04 +0200
"Andreas K. Hüttel"  wrote:

> 2) *If* we introduce a "Fixed-in" and maybe an "Introduced-in" field in 
> Bugzilla, which gives a precise $CATEGORY/$PVR where a problem is resolved or 
> introduced, the extraction of fixed or non-fixed bugs might even be 
> automatized. 

+1 , this would be useful, but would need some instruction on use
to ensure people don't just fill it with $LATEST all the time.

The downsides I see from looking at other things that do similar is "broken in"
is confusing, because 2 or more versions can be broken by given bug, and it can
become fixed in a subsequent version,and then broken again.

Leading to the instinct to write:

Broken In:
  1.2
  1.3
  1.6

Fixed In:
  1.4
  1.5
  1.7

Implying "Ranges" instead of specific versions makes their utility weaker as
far as "bug search" is concerned when one is trying to find "bugs that pertain
to the thing I'm stabilizing" 


pgptF_SmoyddX.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Mon, 15 Aug 2016 15:03:08 +0200
Kristian Fiskerstrand  wrote:

> Could you please elaborate a bit? In particular from perspective of (i)
> integration into current workflow, (ii) complexity in application
> maintenance/hosting (iii) cost/benefit considerations

Biggest irritation is that "bugs track concepts" but "arches track arches"
so "One bug many arches" -> Anarchy.

A competing tool I'd imagine would possibly automatically designate packages
that are stable /candidates/ and keywording /candidates/ without any manual
interaction.

ie: It would essentially double down on the "Batch stabilization/keywording"
concept and represent that concept portage wide, but only in an informal sense.

Then you could basically filter it by views on a per-arch basis to see what
needs doing on a given arch, and mark "candidates" as "needed to be done"
and tree based recursive integrity checking would be part of the workflow.

So you'd see "X is stable candidate for x86"
You'd click "x86" and it would produce a list of the subgraph that also needs
stabilizing to satisfy, and you'd give it a once over, click "Ok" and that 
package
and its dependencies are now "marked for stabilization on x86". 

Then AT teams could come along and simply use a different view that shows only
stabilization requests for their arch, and do them in bulk, or piecemeal,
at their own discretion.

unkeyworded -> keywording candidate -> keywording request -> keyworded 

keyworded -> stable candidate -> stable request -> stable

But these are just ideas ;)


pgpiqjSuE1dad.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Rich Freeman]

On Mon, Aug 15, 2016 at 4:01 PM, William Hubbs  wrote:
>  This works unless you are talking about packages in @system.
> I do see core packages on these arches also languish in ~ for months
> with open stable requests.
>
> The only way to handle one of those would be to remove the old version
> and let their deptree break until they catch up.
>

In terms of direct impact, I agree.  Though, I think the hope would be
that if enough non-@system packages get pruned they would have more
time for the @system ones.

The concept of a deptree also breaks down with @system since we tend
to not specify these dependencies explicitly.

-- 
Rich

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[William Hubbs]

On Mon, Aug 15, 2016 at 03:27:43PM -0400, Rich Freeman wrote:
> On Mon, Aug 15, 2016 at 3:12 PM, William Hubbs  wrote:
> > On Mon, Aug 15, 2016 at 02:33:52PM -0400, Rich Freeman wrote:
> >> I'd rather see maintainers just yank the last stable package and break
> >> the depgraph and let the arch teams deal with the cleanup than have
> >> them mark stuff stable without any testing at all.  Or build a script
> >> that does the keyword cleanup for them.  De-keywording late stable
> >> requests is a solution that is self-correcting.  As packages are
> >> reduced from the stable set then there are fewer stable requests and
> >> the arch team is better able to focus on the ones they deem important.
> >> Throwing more packages in stable that aren't actually stable just
> >> makes that problem worse, and destroys whatever value the stable
> >> keyword had on the arch.  For small arch teams they really should be
> >> focusing their time on core packages.
> >
> > Rich, This was my original thinking about this issue. It turned out to
> > be more controversial than I originally thought -- folks told me that
> > stable tree users expect stability above all, so breaking the depgraph
> > is unacceptable, so I'm just trying to find something that is more
> > palletable.
> >
> 
> Well, I wasn't suggesting that breaking the depgraph is great.  Just
> that I think it is better than calling things stable which aren't.
> 
> A better approach is a script that does the keyword cleanup.
> 
> So, if you want to reap an ebuild you run "destabilize
> foo-1.2.ebuild".  It searches the tree for all reverse deps and
> removes stable keywords from those.  Then you commit all of that in
> one commit.
 
 This works unless you are talking about packages in @system.
I do see core packages on these arches also languish in ~ for months
with open stable requests.

The only way to handle one of those would be to remove the old version
and let their deptree break until they catch up.

William



signature.asc
Description: Digital signature

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

[Rich Freeman]

On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel  wrote:
> 1) Stabilization is a simpler and much more formalized process compared to
> normal bug resolution.
> * There is one version to be stabilized.
> * One precise package version

Can you clarify what this means?  Do you mean that at any time only
one version of any particular package/slot is marked stable?

That seems like it would be problematic for ranged deps.  Granted,
those are problematic in and of themselves since they can create
conflicts that are hard to resolve.  However, this extends conflicts
between package you might not want to install at the same time to
situations where you don't even need both of the conflicting packages.

-- 
Rich

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Markus Meier]

On Sun, 14 Aug 2016 23:35:58 +0200
Kristian Fiskerstrand  wrote:

> During the latest Council meeting it was determined to set up a new
> Working Group to come up with recommendations for improving the state
> of the stable tree at a later Council meeting.
> 
> Some initial items it was suggested the WG look into is
>  * 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?
> 
>  * Are there ways to reduce the stabilization lag of packages
>  - looking into the effectiveness of ALLARCHES and its use
>  - possibility for maintainer to stabilize packages themselves for
>architectures they have access to (including whether there
> might be a need for changes to gentoo infrastructure to facilitate
>this)
>  - Tinderboxing / Automatic tools build test packages and reverse
>dependencies in order to assist in stabilization
> 
> Other suggestions are up to the WG to come up with and write up a
> final report to the council with the summary of these discussions.
> 
> I've volunteered to chair such as working group. If you want to
> participate in it please respond to this thread. Additionally I've set
> up #gentoo-wg-stable as a place of coordination.
> 

Don't forget to get input from current (active?) arch teams how they
work and do their stuff. IMHO the whole bugzilla workflow etc. is just
a small piece in the whole stabilization business.


Regards,
Markus


pgp0RKWorhUKB.pgp
Description: OpenPGP digital signature

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

[Andreas K. Hüttel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Montag, 15. August 2016, 15:03:08 schrieb Kristian Fiskerstrand:
> On 08/15/2016 02:49 PM, Dirkjan Ochtman wrote:
> > On Mon, Aug 15, 2016 at 6:29 AM, Kent Fredric  wrote:
> >> This sort of stuff makes me feel bugzilla is entirely the wrong platform
> >> for handling stabilizations and keywords :/
> > 
> > I very much agree; some kind of minimal web app/API would probably be
> > better.
> 
> Could you please elaborate a bit? In particular from perspective of (i)
> integration into current workflow, (ii) complexity in application
> maintenance/hosting (iii) cost/benefit considerations

I agree that BZ is not the best platform for stabilizations (and keywording). 
(It's the one we have now, anything else creates maintenance.)

Now, if we want to come up with radical solutions...

1) Stabilization is a simpler and much more formalized process compared to 
normal bug resolution.
* There is one version to be stabilized. 
* Stabilization can be blocked by bugs of that version.
* If there are no blocking bugs, stabilization can go ahead.
Which means 
* No requirement for free-text fields
* One precise package version
Of course this does not handle the more complex cases like perl/gnome stable 
lists.

2) *If* we introduce a "Fixed-in" and maybe an "Introduced-in" field in 
Bugzilla, which gives a precise $CATEGORY/$PVR where a problem is resolved or 
introduced, the extraction of fixed or non-fixed bugs might even be 
automatized. 

- -- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXshg9AAoJEHRrah2soMK+JawQAK7c2oizH6Vu4EgDpr05y1Fi
BWFvJrqxdgyvUCxwaZMk90j88zlXvvXkbZR6xMxZytZPpXh5FVtadVmElqYJIXiD
G71Gqf0dDMuH9sku7rU9Mmm5WIzJtG0WE2b/FIddG8C5BpuaiqhDKUZcnvW5r3BW
CoLqYWfG5W5A0DiKuZbbTI4jIeHLd8BykitB8dGhT3Lvse52IAMY+9X/BCLfX0lh
WjBh4LszaEIK11zD/EEqSpCd8q6t2A52h//Xpe4a8vrY4fyvxbnULYxm088UBMuV
oOZ5cLKUSqx7BqaDoPaY5vYPBXbQkKsPFDkzEx2B115Ep9fPGpom+MrcLN3JCmL7
fk6R+K9eeACZPHqf2WiNICKnN/l6NQVrrPukDgDWZ9vGvSr1XjhnMdiKVuWOaJki
0vmYtaLJF0Aadwzwp93u/Ii1HIiy7nPU9om3LSOLMnrGbq4I9YzCiX0Az98zCPQw
DABWDOPSdNnkqwexhmlhl9xkO0LDpjbMtWlKufZY9y1mOXUatAK38iD6mcErRuxI
dSz/odmpwpmNvIx7yPc1TwRKkn7Hmr/DkHecMMnmEfqqFn2cy1FkQIMvntx5kLTY
NfS8n90UqCPcZ66xgr5MhxQMV0GKfCwQ1uS4pr9spnVUXyT/gGTnPUs8dswcFA2e
ZyTnnA+fS3uFot25Sl76
=OtNn
-END PGP SIGNATURE-

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Rich Freeman]

On Mon, Aug 15, 2016 at 3:12 PM, William Hubbs  wrote:
> On Mon, Aug 15, 2016 at 02:33:52PM -0400, Rich Freeman wrote:
>> I'd rather see maintainers just yank the last stable package and break
>> the depgraph and let the arch teams deal with the cleanup than have
>> them mark stuff stable without any testing at all.  Or build a script
>> that does the keyword cleanup for them.  De-keywording late stable
>> requests is a solution that is self-correcting.  As packages are
>> reduced from the stable set then there are fewer stable requests and
>> the arch team is better able to focus on the ones they deem important.
>> Throwing more packages in stable that aren't actually stable just
>> makes that problem worse, and destroys whatever value the stable
>> keyword had on the arch.  For small arch teams they really should be
>> focusing their time on core packages.
>
> Rich, This was my original thinking about this issue. It turned out to
> be more controversial than I originally thought -- folks told me that
> stable tree users expect stability above all, so breaking the depgraph
> is unacceptable, so I'm just trying to find something that is more
> palletable.
>

Well, I wasn't suggesting that breaking the depgraph is great.  Just
that I think it is better than calling things stable which aren't.

A better approach is a script that does the keyword cleanup.

So, if you want to reap an ebuild you run "destabilize
foo-1.2.ebuild".  It searches the tree for all reverse deps and
removes stable keywords from those.  Then you commit all of that in
one commit.

If you want to be extra nice you stick it in a pull request in github
and point it out to the arch team and ask them if they're sure they
don't want to stabilize your package...  :)

-- 
Rich

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Michael Orlitzky]

On 08/15/2016 03:18 PM, Andreas K. Hüttel wrote:
> Am Sonntag, 14. August 2016, 23:57:31 schrieb Ciaran McCreesh:
>>
>> I'm not sure what a group is. Is it anything like a herd?
> 
> It's a set with a binary operator, with following fulfilled:
> * closed with respect to the operation

THIS IS PART OF THE DEFINITION OF A BINARY OPERATOR!!!

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[William Hubbs]

On Mon, Aug 15, 2016 at 02:33:52PM -0400, Rich Freeman wrote:
> I'm fine with maintainers de-keywording packages on their own
> initiative.  However, if a maintainer hasn't even built a package on
> an arch, they shouldn't be stabilizing it on that arch.  That would
> make the concept of stable meaningless.  If it is just ~arch plus a
> time delay, then we should just get rid of the stable keywords and
> instead have portage just filter packages by the date they were
> committed to ~arch.
 
 ok, this makes sense.

> I'd rather see maintainers just yank the last stable package and break
> the depgraph and let the arch teams deal with the cleanup than have
> them mark stuff stable without any testing at all.  Or build a script
> that does the keyword cleanup for them.  De-keywording late stable
> requests is a solution that is self-correcting.  As packages are
> reduced from the stable set then there are fewer stable requests and
> the arch team is better able to focus on the ones they deem important.
> Throwing more packages in stable that aren't actually stable just
> makes that problem worse, and destroys whatever value the stable
> keyword had on the arch.  For small arch teams they really should be
> focusing their time on core packages.

Rich, This was my original thinking about this issue. It turned out to
be more controversial than I originally thought -- folks told me that
stable tree users expect stability above all, so breaking the depgraph
is unacceptable, so I'm just trying to find something that is more
palletable.

I have a few bugs right now where I haven't done this because I know it
is going to require "repoman commit --force" to work, and set of our ci
alarms etc. Should I not care about that and just let the arch teams
clean it up?

William



signature.asc
Description: Digital signature

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

[Dirkjan Ochtman]

On Mon, Aug 15, 2016 at 3:25 PM, Kristian Fiskerstrand  wrote:
>> very different process from handling bugs and feature requests. It
>> would be great if we had tooling that focuses on these instead of
>> trying to fit into the bug tracker. It would entail a different
>
> I'm not sure I agree on this point, my perspective is the state of the
> stable tree is exactly dependent on it being considered as part of the
> regular workflow of developers, which has at least been implied in the
> past[0] - resulting in e.g InVCS.
>
> Part of the discussion in that case is the number of developers running
> full testing (~arch) and might not care too much about the state of the
> stable tree, and having stabilization as part of the specific workflow
> will help the state of the stable tree by requiring the developer to
> care about it.

Ah, right. My perspective is mostly coming from the impression that
most developers don't seem to care much for the stable arch trees;
whereas I run stable with only a few exceptions, mostly for things
that I maintain myself.

The other angle here is that, for packages written in C/C++ at least,
it seems dangerous to assume that the package will just work on
non-x86 architectures (and I've even encountered packages where
upstream is somewhat hostile to 32-bits x86). If that is the case, and
assuming that maintainers do not have access to hardware for the other
architectures, then I'm not sure how much sense it makes to involve
the maintainer in the process of tracking stability for their package
on these other architectures, except insofar as explicitly requested
by the arch team.

To frame it differently, I think this whole discussion is very
different for amd64/x86 (which most packages are developed for) vs
pretty much every other architecture. The point is, it doesn't seem to
be a good idea to make people responsible for things that they're very
much not intrinsically motivated to care for, and making maintainers
care for keywording/stabilization on non-convential arches is tricky
from that perspective.

Cheers,

Dirkjan

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[William Hubbs]

I want to elaborate a bit more on this.

On Mon, Aug 15, 2016 at 11:12:41AM -0500, William Hubbs wrote:
> On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote:
> > On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote:
> > > On 08/15/2016 04:19 PM, William Hubbs wrote:
> > >> I'm very much for this as well. Themaintainer should be able to
> > >> stabilize on all arches after the timeout. That would solve the primary
> > >> concern I have about the stable tree lagging.
> > > 
> > > It depends on the context, if it is not security related or fixing a
> > > known bug, it can cause regression for stable users without much gain.

The maintainer of the package is going to have the most intimate knowledge about
these types of issues in the package, so I would rather have the maintainer
make these types of decisions instead of restricting him with some global 
policy.

> > 
> > Elaborating on this, if we're talking about maintainer stabilizing it
> > after testing it properly there is no issue, but there shouldn't be a
> > policy to auto-mark stable
> 
> As a maintainer, if there is an old version of a package in stable for
> some arch and I have a stable request open for a newer version and the
> arch team doesn't respond to the stable request within a reasonable
> amount of time, I want to do one of two things:
> 
> - destabilize all versions of the package on this arch. That would allow
>   me to move on and take the worry about stabilizing this package off of
>   the arch team in the future.  or
> - if there are no blockers, stabilize the new version and deal with the
> fallout myself if there is any.
> 
> If there is not an old version of the package marked stable, closing the
> stablereq and moving on is probably what I would do after a certain
> amount of time.
> 
> Maintaining a viable stable tree is a team effort between the
> maintainers and the arch teams. If the arch teams are so overwhelmed
> with stable requests that they can't keep things current, the
> maintainers should be able to stabilize the newer versions and deal with
> the fallout as a last resort, or decide that they don't want their
> packages stable on those arches until the arch teams can keep up.
> 
> William
> 


signature.asc
Description: Digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[William Hubbs]

On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote:
> On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote:
> > On 08/15/2016 04:19 PM, William Hubbs wrote:
> >> I'm very much for this as well. Themaintainer should be able to
> >> stabilize on all arches after the timeout. That would solve the primary
> >> concern I have about the stable tree lagging.
> > 
> > It depends on the context, if it is not security related or fixing a
> > known bug, it can cause regression for stable users without much gain.
> > 
> 
> Elaborating on this, if we're talking about maintainer stabilizing it
> after testing it properly there is no issue, but there shouldn't be a
> policy to auto-mark stable

As a maintainer, if there is an old version of a package in stable for
some arch and I have a stable request open for a newer version and the
arch team doesn't respond to the stable request within a reasonable
amount of time, I want to do one of two things:

- destabilize all versions of the package on this arch. That would allow
  me to move on and take the worry about stabilizing this package off of
  the arch team in the future.  or
- if there are no blockers, stabilize the new version and deal with the
fallout myself if there is any.

If there is not an old version of the package marked stable, closing the
stablereq and moving on is probably what I would do after a certain
amount of time.

Maintaining a viable stable tree is a team effort between the
maintainers and the arch teams. If the arch teams are so overwhelmed
with stable requests that they can't keep things current, the
maintainers should be able to stabilize the newer versions and deal with
the fallout as a last resort, or decide that they don't want their
packages stable on those arches until the arch teams can keep up.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Brian Dolbec]

On Mon, 15 Aug 2016 09:40:39 -0400
Rich Freeman  wrote:

> On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec 
> wrote:
> >
> > I have some trouble with not being able to close bugs as resolved
> > when the fixes have been released.  But I do see that the majority
> > of what is being discussed relates to pkg ebuilds more than it does
> > to coding projects.  In that sense it sounds reasonable.  But for
> > me, most of my work is project coding, so it overlaps with making
> > releases which involves the ebuild.  As a project coder, I want to
> > be able to close a bug when a release has been made that contains
> > the fix.  In some cases that release might not get stabilized, but
> > another one later does. 
> 
> I'd suggest that we agree early-on that the scope of this is around
> ebuild work.  Not "upstream" work where the upstream is Gentoo.
> 
> Of course, there could be overlap.  portage-1.23.ebuild might have a
> bug, and that gets fixed in the portage dev git, and later gets
> released to portage-1.24, and then ends up in stable sometime later.
> Those could be two separate bugs (the gentoo repo ebuild bug vs the
> portage "upstream" bug), but I'm not sure that makes life easier.  If
> they were two separate bugs (as they would be if Gentoo weren't the
> upstream) then the scope of this effort is focused on the Gentoo
> ebuild repo bug.
> 

I suppose we could use the tracker bug a little differently than we
have to handle the release/ebuild stabilization process. We have often
recycled a tracker to the next version, but instead we can generate a
new one each time and allow it to be used this way.  If a release is
being skipped for stabilization, then it could be added to the next
tracker's depend.

The only thing is that we will still end up with duplicate bugs being
filed since the trackers do not have any search data of the original
bugs which have been fixed and released in an unstable version.  Of
which the original bug had been marked resolved.  In this case, could
the search system be modified to keep that search data until all
references to that bug (ie: blocks the tracker bug) have been
stabilized/closed.


hmm, looking a bugzilla...

Gentoo Linux:   The Gentoo Linux Distribution – Ebuilds and
System related issues Always attach the output of emerge --info to your
bug report! 

Before reporting a bug, please make sure the issue you are about to
file is not the result of a misconfiguration on your part. Our other
support venues (for instance the Forums or IRC channels) can help you
find out whether the issue warrants a bug report. 

Examples for bugs in this product:
New package and version bump requests
Compile errors (please follow the instructions contained in the
error message!) Application crashes (be sure to have a backtrace
available) General issues regarding your Gentoo system

Examples for bugs that should NOT be filed here:
Security updates (use Gentoo Security below)
Documentation updates (use Documentation below)
Issues regarding our website and infrastructure (use Gentoo
Infrastructure or Website www.gentoo.org below) Issues about OpenRC,
genkernel, or catalyst (use Hosted projects below)


--

This is still a very broad range...  This can still cover bugs for many
small projects that are not in the hosted projects category. It also
can contain bugs that will never involve stabilization of an ebuild. 

Perhaps we need to add a new category SPECIFICALLY for dealing with the
stabilization process and/or Gentoo tree state.  The current "Gentoo
Linux" would continue to act as the catch-all, but as a bug is fixed and
involves a release/in tree new version,..., it get's re-categorized to a
"Gentoo Stabilization" (or some other aptly named) category.  In that
way, once a fix has been made the re-categorization could reduce the
search results for projects working on bugs that need fixing.  While at
the same time, not completely close a bug.  For tracker bugs, it would
be the tracker that gets re-categorized to the specific "Gentoo
Stabilization" category where it too could get better search
results and/or some semi-automated tools could send reminders for
ebuilds not stabilized after the 30 day time when that version has no
bugs in the catch-all category.  Also if bugs are filed against it, a
tool could auto-tag it's DEPEND with the "Gentoo Linux" bug number.

I think something like this could help improve the process.
-- 
Brian Dolbec 

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kristian Fiskerstrand]

On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote:
> On 08/15/2016 04:19 PM, William Hubbs wrote:
>> I'm very much for this as well. Themaintainer should be able to
>> stabilize on all arches after the timeout. That would solve the primary
>> concern I have about the stable tree lagging.
> 
> It depends on the context, if it is not security related or fixing a
> known bug, it can cause regression for stable users without much gain.
> 

Elaborating on this, if we're talking about maintainer stabilizing it
after testing it properly there is no issue, but there shouldn't be a
policy to auto-mark stable

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kristian Fiskerstrand]

On 08/15/2016 04:19 PM, William Hubbs wrote:
> I'm very much for this as well. Themaintainer should be able to
> stabilize on all arches after the timeout. That would solve the primary
> concern I have about the stable tree lagging.

It depends on the context, if it is not security related or fixing a
known bug, it can cause regression for stable users without much gain.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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 09:25 AM, Kristian Fiskerstrand wrote:

On 08/15/2016 03:15 PM, Dirkjan Ochtman wrote:

On Mon, Aug 15, 2016 at 3:03 PM, Kristian Fiskerstrand  wrote:

Could you please elaborate a bit? In particular from perspective of (i)
integration into current workflow, (ii) complexity in application
maintenance/hosting (iii) cost/benefit considerations


Well, I think stabilization (and, to some extent, keywording) is a


Thank you for elaborating


very different process from handling bugs and feature requests. It
would be great if we had tooling that focuses on these instead of
trying to fit into the bug tracker. It would entail a different


I'm not sure I agree on this point, my perspective is the state of the
stable tree is exactly dependent on it being considered as part of the
regular workflow of developers, which has at least been implied in the
past[0] - resulting in e.g InVCS.

Part of the discussion in that case is the number of developers running
full testing (~arch) and might not care too much about the state of the
stable tree, and having stabilization as part of the specific workflow
will help the state of the stable tree by requiring the developer to
care about it.


Excellent point. In fact Mozilla posted an condensed summary of 
migrating from a tinderbox to a robust CI here [1]; and the three 
keenest takeaways from that posting are::


"1) Need to run multiple jobs-of-the-same-type at a time
 2) Build-on-checkin, not build-continuously.
 3) Display build results arranged by developer checkin not by time."


[1] http://oduinn.com/blog/2014/06/04/farewell-to-tinderbox/

What I would add is the need to think about all of the arches gentoo
supports and that the results of this WG solutions are robust for a 
diverse collection of Arches and embedded platforms.


Secondly, fundamentally include "embedded arm gentoo" into the 
discussion of the WG. Before summarizing conclusions and 
recommendations, we need to realize that Gentoo really is about a "full 
spectrum of solutions".  Spanning from the traditional 
secured-conservative server platform through the nimble 'have it your 
way workstations' to minimal (VM/Container/bare metal) all the way down 
to a gentoo embedded system, which can run on a variety of hardware 
platforms, stripped, highly optimized, resource-constrained special 
purpose devices.



A very valid postulate is:: "What/how are we to organize Arm* into 
gentoo {github; bgo ; handbook ; support}.







workflow, obviously, but I think that's a plus in this case, and we
could make sure we have the command-line tools to make it easy to work
with.



as long as it doesn't become a disconnect to maintainer's
responsibilities. The state of stable tree isn't a separate issue that
belongs with the arch teams; it is an integrated and important part of
maintaining any package to begin with.


Development/maintenance/hosting is an issue, though it's a bit hard to
say something definitive about it before there's more of a plan of how
such a tool could work. It's enough of a pain for me that I could see
myself investing some time in development.

Perhaps some kind of middle ground would be to handle this stuff in a
separate Bugzilla product, and then making sure we have some tooling
around that to better present the data.


See comment in previous chapter



Cheers,

Dirkjan



Notes:
[0] but I don't recall any specific policies / council meeting summaries
on it offhand and don't have time to search but feel free to provide it
if easily available to anyone - the last discussion I see on this was
https://archives.gentoo.org/gentoo-dev/message/df7dee4ad61fe1c9bac866d15e0babfb


So, I guess what I'm proposing, is the lenses used for this WG should 
have one, designed for x86_64 and the other lenses specific for arm*. 
[2] That way, with only a few tweaks, these ideas should encourage 
unifying a few diverse, but very important collection of architectures 
into main line gentoo docs, trees, bugs and general dev/user 
interaction, instead of being aloof and orphaned and having incomplete 
semantics. Extension of arm needs, should make the other arches, whether 
embedded or alternative, much easier to assimilate, coherently. ymmv.


[2] https://wiki.gentoo.org/wiki/Embedded_systems/ARM_hardware_list

Flexibility, as defined by those performing the embedded gentoo work, 
should be a fundamental tenant of this WG, as defined in such a way to 
continue to encourage the fine work performed by many on the various arm 
 and other platforms.



Additionally:

[3] https://wiki.gentoo.org/wiki/Project:ARM

[4] https://wiki.gentoo.org/wiki/Embedded_Handbook

[5] https://wiki.gentoo.org/wiki/Handbook:Main_Page

{arm32 and arm64 needs should be considered, where practical within BGO}
Arm64 is already hitting Datacenters, around the globe; and is a very 
large point of excitement particularly related to Green and low-cost 
efforts.



hth,
James

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Rich Freeman]

On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec  wrote:
>
> I have some trouble with not being able to close bugs as resolved when
> the fixes have been released.  But I do see that the majority of what is
> being discussed relates to pkg ebuilds more than it does to coding
> projects.  In that sense it sounds reasonable.  But for me, most of my
> work is project coding, so it overlaps with making releases which
> involves the ebuild.  As a project coder, I want to be able to close a
> bug when a release has been made that contains the fix.  In some cases
> that release might not get stabilized, but another one later does.
>

I'd suggest that we agree early-on that the scope of this is around
ebuild work.  Not "upstream" work where the upstream is Gentoo.

Of course, there could be overlap.  portage-1.23.ebuild might have a
bug, and that gets fixed in the portage dev git, and later gets
released to portage-1.24, and then ends up in stable sometime later.
Those could be two separate bugs (the gentoo repo ebuild bug vs the
portage "upstream" bug), but I'm not sure that makes life easier.  If
they were two separate bugs (as they would be if Gentoo weren't the
upstream) then the scope of this effort is focused on the Gentoo
ebuild repo bug.

-- 
Rich

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Rich Freeman]

On Mon, Aug 15, 2016 at 8:24 AM, Michael Orlitzky  wrote:
>
> If we have to wait for a fix to hit stable before I can close a bug, who
> should I assign it to? I don't want 200 bugs, that I can do literally
> nothing about, assigned to me for years while I wait for them to get
> stabilized. It's also going to kill my motivation knowing that, no
> matter how hard I work, my bug count is never going to go down.
>

I think that a lot of this discussion centers around changing the bug
states while assuming that developers will continue to use the same
views they already use.

Today developers tend to use views that exclude resolved bugs.
Perhaps tomorrow they'll tend to use views that exclude bugs that are
resolved or waiting for stabilization.  Perhaps these views will
become the defaults.

Or maybe we leave the states alone and add a new field to track
whether the bug is stable on any/all/each arch (not sure which is
best).

One concern which I think is legitimate is the extra bookkeeping.  If
we're going to track a bunch of bugs through a long stabilization
cycle (think desktop environments), we don't want devs to have to
spend hours figuring out which bugs can be closed out.  And we don't
want them skipping that step either.  It might make sense to tag bugs
with a version and then have the states automatically update when the
bugs are released.

-- 
Rich

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

[Kristian Fiskerstrand]

On 08/15/2016 03:15 PM, Dirkjan Ochtman wrote:
> On Mon, Aug 15, 2016 at 3:03 PM, Kristian Fiskerstrand  
> wrote:
>> Could you please elaborate a bit? In particular from perspective of (i)
>> integration into current workflow, (ii) complexity in application
>> maintenance/hosting (iii) cost/benefit considerations
> 
> Well, I think stabilization (and, to some extent, keywording) is a

Thank you for elaborating

> very different process from handling bugs and feature requests. It
> would be great if we had tooling that focuses on these instead of
> trying to fit into the bug tracker. It would entail a different

I'm not sure I agree on this point, my perspective is the state of the
stable tree is exactly dependent on it being considered as part of the
regular workflow of developers, which has at least been implied in the
past[0] - resulting in e.g InVCS.

Part of the discussion in that case is the number of developers running
full testing (~arch) and might not care too much about the state of the
stable tree, and having stabilization as part of the specific workflow
will help the state of the stable tree by requiring the developer to
care about it.

> workflow, obviously, but I think that's a plus in this case, and we
> could make sure we have the command-line tools to make it easy to work
> with.
> 

as long as it doesn't become a disconnect to maintainer's
responsibilities. The state of stable tree isn't a separate issue that
belongs with the arch teams; it is an integrated and important part of
maintaining any package to begin with.

> Development/maintenance/hosting is an issue, though it's a bit hard to
> say something definitive about it before there's more of a plan of how
> such a tool could work. It's enough of a pain for me that I could see
> myself investing some time in development.
> 
> Perhaps some kind of middle ground would be to handle this stuff in a
> separate Bugzilla product, and then making sure we have some tooling
> around that to better present the data.

See comment in previous chapter

> 
> Cheers,
> 
> Dirkjan
> 

Notes:
[0] but I don't recall any specific policies / council meeting summaries
on it offhand and don't have time to search but feel free to provide it
if easily available to anyone - the last discussion I see on this was
https://archives.gentoo.org/gentoo-dev/message/df7dee4ad61fe1c9bac866d15e0babfb


-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Dirkjan Ochtman]

On Mon, Aug 15, 2016 at 3:03 PM, Kristian Fiskerstrand  wrote:
> Could you please elaborate a bit? In particular from perspective of (i)
> integration into current workflow, (ii) complexity in application
> maintenance/hosting (iii) cost/benefit considerations

Well, I think stabilization (and, to some extent, keywording) is a
very different process from handling bugs and feature requests. It
would be great if we had tooling that focuses on these instead of
trying to fit into the bug tracker. It would entail a different
workflow, obviously, but I think that's a plus in this case, and we
could make sure we have the command-line tools to make it easy to work
with.

Development/maintenance/hosting is an issue, though it's a bit hard to
say something definitive about it before there's more of a plan of how
such a tool could work. It's enough of a pain for me that I could see
myself investing some time in development.

Perhaps some kind of middle ground would be to handle this stuff in a
separate Bugzilla product, and then making sure we have some tooling
around that to better present the data.

Cheers,

Dirkjan

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

[Kristian Fiskerstrand]

On 08/15/2016 02:49 PM, Dirkjan Ochtman wrote:
> On Mon, Aug 15, 2016 at 6:29 AM, Kent Fredric  wrote:
>> This sort of stuff makes me feel bugzilla is entirely the wrong platform for
>> handling stabilizations and keywords :/
> 
> I very much agree; some kind of minimal web app/API would probably be better.

Could you please elaborate a bit? In particular from perspective of (i)
integration into current workflow, (ii) complexity in application
maintenance/hosting (iii) cost/benefit considerations

> 
> Cheers,
> 
> Dirkjan
> 


-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Dirkjan Ochtman]

On Mon, Aug 15, 2016 at 6:29 AM, Kent Fredric  wrote:
> This sort of stuff makes me feel bugzilla is entirely the wrong platform for
> handling stabilizations and keywords :/

I very much agree; some kind of minimal web app/API would probably be better.

Cheers,

Dirkjan

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Michael Orlitzky]

On 08/14/2016 05:35 PM, Kristian Fiskerstrand wrote:
> 
> Some initial items it was suggested the WG look into is
>  * 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?
> 

(Please add me to the wg-stable alias)

Bugzilla helps me get things done. It lets me split up the things I have
to do into manageable sub-things and then organize them into a
dependency graph and sort them in terms of the amount of time it will
take and the return on investment. Once that's done -- and when I have
some free time -- I can always pick something from the list assigned to
me that fits the hole in my free time snugly.

If we have to wait for a fix to hit stable before I can close a bug, who
should I assign it to? I don't want 200 bugs, that I can do literally
nothing about, assigned to me for years while I wait for them to get
stabilized. It's also going to kill my motivation knowing that, no
matter how hard I work, my bug count is never going to go down.

Right now, at least I can close a bug after I fix it. The STABLEREQ is a
separate bug, clearly identified, and created at my leisure or a user's
request (I would still prefer they be assigned to someone else since I
can do absolutely nothing to help). If I filter the STABLEREQs out of my
list, I retain the satisfaction of closing a bug when I fix it.

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  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

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kristian Fiskerstrand]

On 08/14/2016 11:35 PM, Kristian Fiskerstrand wrote:
> I've volunteered to chair such as working group. If you want to
> participate in it please respond to this thread. Additionally I've set
> up #gentoo-wg-stable as a place of coordination.

we now have an alias wg-sta...@gentoo.org that can be used for this
purpose. I've added the people I've seen wanting to join on the list so far.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kristian Fiskerstrand]

On 08/15/2016 09:55 AM, Brian Dolbec wrote:

> 
> For me IN_PROGRESS means the problem is being worked on, not that a fix
> has been posted/committed anywhere.  

Indeed

> INVCS is once the fix has been
> committed to the source repo and not anything to do with an ebuild from
> the coders perspective.   The problem is the overlap of bugzilla for
> both ebuild repositories and source repositories.  So if there is any
> changes to be made to the different states possible...  Just remember
> the the different perspectives and try to make it clear what they are
> for.

Yes, we're talking about the gentoo ebuild repository, source projects
etc should likely be an own product in bugzilla, it is not what we're
discussing in this context.

> Also, if a pkg is never stabilized... does that mean it's bugs
> can never be closed?  So far in the discussion, that point has not been

No, you'd simply skip the stabilization step, as if the highest
visibility is testing/~arch to begin with there isn't any stable necessary

> brought up, but is very relevant to the discussion.
> 
> /me mumbles about the extra bookeeping that work-flow will
> make...and subsequently put off and/or forget to do ;)  
> 

Better than developers marking it fixed without it hitting stable as too
many are doing today.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kent Fredric]

On Mon, 15 Aug 2016 00:55:50 -0700
Brian Dolbec  wrote:

> For me IN_PROGRESS means the problem is being worked on, not that a fix
> has been posted/committed anywhere.  INVCS is once the fix has been
> committed to the source repo and not anything to do with an ebuild from
> the coders perspective.   The problem is the overlap of bugzilla for
> both ebuild repositories and source repositories.  So if there is any
> changes to be made to the different states possible...  Just remember
> the the different perspectives and try to make it clear what they are
> for.  Also, if a pkg is never stabilized... does that mean it's bugs
> can never be closed?  So far in the discussion, that point has not been
> brought up, but is very relevant to the discussion.
> 
> /me mumbles about the extra bookeeping that work-flow will
> make...and subsequently put off and/or forget to do ;)  

As an alternative approach, we could use "RESOLVED" to mean "Committed to tree"
and add a secondary stage, maybe called "VERIFIED"[1] to indicate it was 
shipped-to-stable 

;)

Thus:

- RESOLVED FIXED: Fixed, but no subsequent stabilization needed ( ie: fixed 
straight to
  stable or in an ~arch only package )

- RESOLVED NEEDSTABLE: Fixed in ARCH, needs arch->~arch stabilization

- RESOLVED STABLE: Status after NEEDSTABLE


NB: When I said "InVCS" I meant a token stage akin to "needstable" that was 
seperate
from the existing "InVCS" bugzilla keyword, apologies for the confusion.

Because to me, Gentoo's bugzilla about "current ebuilds" should pertain to the 
ebuilds
themselves, not to the status of upstream those ebuilds just so happen to be 
wrappers for


1: Ok, not really, just my joke, but something with a better name.


pgpaV7J65yJau.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Pacho Ramos]

El lun, 15-08-2016 a las 10:00 +0200, Pacho Ramos escribió:
> El dom, 14-08-2016 a las 23:35 +0200, Kristian Fiskerstrand escribió:
> > 
> > During the latest Council meeting it was determined to set up a new
> > Working Group to come up with recommendations for improving the
> > state
> > of
[...]

Oops, I wrongly understood the mail as a "regular one" to reply
directly... if this is about joining the Working Group, please include
me if possible :)

Thanks a lot

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Pacho Ramos]

El dom, 14-08-2016 a las 23:35 +0200, Kristian Fiskerstrand escribió:
> During the latest Council meeting it was determined to set up a new
> Working Group to come up with recommendations for improving the state
> of
> the stable tree at a later Council meeting.
> 
> Some initial items it was suggested the WG look into is
>  * 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?
> 

Yes. For example, currently, most gnome bugs are not major enough to
need a fast stabilization and, then, we wait for the next round of
stabilizations instead of filling one new bug per package. We, of
course, do exceptions when the bug is major enough.

Then, the old workflow of allowing to close the bugs even when only
fixed in testing was working fine for us, and also allows us to have a
more "tidy" bug list (as our bug list is huge sometimes) and focus on
the really remaining bug reports.

There are also many cases of long standing bugs that we want, on
purpose, to be fixed in testing and wait for the full period (for
example, I remember a last change in glib that we wanted it to wait for
a full "major version bump" period, then, keeping the bug opened until
that new version is stabilized with all the other related packages is
not useful at all).

Also, another drawback is that I would need to manually check, again,
all the opened bug reports assigned to us and *related to many
different packages* once the stabilization finishes (sometimes many
months later)... and that is adding ever more work without any clear
advantage to me.

Another issues that comes to my mind is that, if I don't misremember,
there were in the past some scripts that allowed us to fill automatic
stabilization for reports to help maintainers to remember to stabilize
things. That scripts were filling the bugs only when no bug report was
opened for the relevant packages... then, they will break, and since
they were the only thing "near automatic" for trying to remember to
stabilize things... paradoxically this change will cause the
stabilizations to be even more "manual" and, hence, probably even
slower, as they will depend on the maintainer being active enough.

I am not sure if, maybe, it would be feasible to add a button to
bugzilla to create a stabilization bug from another one. I am thinking
in something similar of our "Clone bug" feature. Maybe that would be
adapted to create a new bug report based on existing one for taking the
package name for the summary, appending the STABLEREQ keyword and... 

That way, we could still close the bug report when fixed (even in
testing) while having the stable bug report around to allow us to
remember that is still pending.


>  * Are there ways to reduce the stabilization lag of packages
>  - looking into the effectiveness of ALLARCHES and its use
>  - possibility for maintainer to stabilize packages themselves
> for
>    architectures they have access to (including whether there
> might
>    be a need for changes to gentoo infrastructure to facilitate
>    this)

Thinking about the way I think most stabilization teams are handling
the bunch stabilizations, I think the best think to do is that the
maintainer itself goes ahead stabilizing on remaining arches as soon as
the first one does the job. 


>  - Tinderboxing / Automatic tools build test packages and reverse
>    dependencies in order to assist in stabilization

Well, Toralf is really doing a nice job helping us with tinderbox, but
I am unsure if that process is automatic enough to allow like one
tinderbox per stabilization bug and if he has the resources to make it
fast enough :/ 

> 
> Other suggestions are up to the WG to come up with and write up a
> final
> report to the council with the summary of these discussions.
> 
> I've volunteered to chair such as working group. If you want to
> participate in it please respond to this thread. Additionally I've
> set
> up #gentoo-wg-stable as a place of coordination.
> 

I am not sure if one suggestion I did a few days ago was included (as
the thread was already really long when I was able to reply sorry), if
that is not the case, it was:
My suggestion, for now would be to modify a bit the current policy: if
I don't misremember, we can drop stable keywords for arches that are
not stabilizing the package in 90 days. The problem is that it
currently cannot be done in most of the times because it's not feasible
for the maintainer to drop the keyword and *also* all the stable
keywords of reverse deps.

Hence, I would suggest to, apart of allowing the maintainers to drop
the keywords, to also allow them to stabilize that packages on that
arches 

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Brian Dolbec]

On Mon, 15 Aug 2016 12:05:43 +0800
Jason Zaman  wrote:

> On Mon, Aug 15, 2016 at 03:53:26PM +1200, Kent Fredric wrote:
> > On Mon, 15 Aug 2016 11:45:22 +0800
> > Jason Zaman  wrote:
> >   
> > > IN_PROGRESS == we've put the fix in the git repo
> > > RESO/TESTREQ == new release and in ~arch  
> > 
> > TESTREQ was incidentally my first thought. Only needs me to study
> > how much that's already used and whether or not existing bugs with
> > that flag meet that description or not.
> > 
> > 
> > However, a distinction between IN_PROGRESS and RESO/TESTREQ is not
> > possible here, because "in git" means "You'll get it if you sync
> > >1h from now"  
> 
> Oh, I meant this is for our policy stuff. which is in
> hardened-refpolicy.git and then every few weeks we make a release and
> bump all the packages in sec-policy/selinux-*. For things that do not
> need an actual release we just skip INPROG and go straight to TESTREQ
> when we fix the ebuild in the tree.
> 
> The important part to me is that RESO/FIXED should only mean fixed
> when the problem is fixed in the stable tree too. There has to be
> another state before FIXED that is for ~arch. If the package is not
> stable on any arch then of course it is FIXED as soon as ~arch is
> fixed.
> 
> > IN_PROGRESS can thus only mean something about it being worked on
> > but not yet pushed to the main git repo. (ie: overlays, private
> > repos)
> > 
> > But I would rather it part of the primary resolution path, not a
> > mere property of the resolution type.
> > 
> > Because its easier to say:
> > 
> > UNCONFIRMED -> CONFIRMED -> INPROGRESS -> INVCS -> STABLE
> > 
> > Than
> > 
> > UNCONFIRMED -> CONFIRMED -> INPROGRESS -> (RESOLVED/TESTREQ) ->
> > (RESOLVED/FIXED)  
> 
> They are roughly equivalent, yeah. But I prefer TESTREQ because its
> easier to see in the bug list page. You can of course choose which
> items are shown in the list in bugzilla but resolution is already
> there so no need to add an extra column.
> 
> -- Jason
> 
> 

I have some trouble with not being able to close bugs as resolved when
the fixes have been released.  But I do see that the majority of what is
being discussed relates to pkg ebuilds more than it does to coding
projects.  In that sense it sounds reasonable.  But for me, most of my
work is project coding, so it overlaps with making releases which
involves the ebuild.  As a project coder, I want to be able to close a
bug when a release has been made that contains the fix.  In some cases
that release might not get stabilized, but another one later does.

For me IN_PROGRESS means the problem is being worked on, not that a fix
has been posted/committed anywhere.  INVCS is once the fix has been
committed to the source repo and not anything to do with an ebuild from
the coders perspective.   The problem is the overlap of bugzilla for
both ebuild repositories and source repositories.  So if there is any
changes to be made to the different states possible...  Just remember
the the different perspectives and try to make it clear what they are
for.  Also, if a pkg is never stabilized... does that mean it's bugs
can never be closed?  So far in the discussion, that point has not been
brought up, but is very relevant to the discussion.

/me mumbles about the extra bookeeping that work-flow will
make...and subsequently put off and/or forget to do ;)  

-- 
Brian Dolbec 

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

[Kent Fredric]

On Mon, 15 Aug 2016 16:29:43 +1200
Kent Fredric  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.


pgpCeF7kdMHJT.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Sun, 14 Aug 2016 23:35:58 +0200
Kristian Fiskerstrand  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?

Here you're essentially marking "RESOLVED" to be "Fixed In Stable"

There's a problem I have here with this: If we have a keyword that in effect is
intended to say "This bug is fixed in stable", the problem there is there's no
way, at least, not in the context of the bug, or the bug metadata, to draw
anything meaningful from that.

Because "Stable" is in my estimation typically not a single state.

We like to presume it is, but the reality is a significant number of packages
have "mixed" stability states.

And the stability process itself is also arch specific, and so they don't
all stabilize together, some, languishing by months.

So: "NeedsStable"(sic) means what exactly?

And if "Resolved" is "Stable is done", what does that mean?

Does "NeedsStable" mean "All arches that are deemed stable need to be stabilized
for this bug"?

What about packages that don't have any stable version, and are not anywhere
on a prioritization for stabilization?

What about packages that are stable only on a few arches?

The lack of bugs having an "affected platforms" field as such makes reverse
searching for such things when you're touching a bug needlessly complicated.

You can at best approximate it by searching for cc@ properties, but that only
matters for packages that are *currently* pending keywording.

And I doubt people are going to be CCing arches for every bug that "NeedsStable"

You can I guess create some form of referential integrity, where you have to
assign every bug that gets fixed to a stable request in order to ensure its 
completion.

But that's getting into problems of causality, needing to assign a stability
request to a bug before stabilization is needed just to determine "which arches"

This sort of stuff makes me feel bugzilla is entirely the wrong platform for
handling stabilizations and keywords :/



pgp3j2uNQ5aDJ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Jason Zaman]

On Mon, Aug 15, 2016 at 03:53:26PM +1200, Kent Fredric wrote:
> On Mon, 15 Aug 2016 11:45:22 +0800
> Jason Zaman  wrote:
> 
> > IN_PROGRESS == we've put the fix in the git repo
> > RESO/TESTREQ == new release and in ~arch
> 
> TESTREQ was incidentally my first thought. Only needs me to study how much 
> that's already used
> and whether or not existing bugs with that flag meet that description or not.
> 
> 
> However, a distinction between IN_PROGRESS and RESO/TESTREQ is not possible 
> here,
> because "in git" means "You'll get it if you sync >1h from now"

Oh, I meant this is for our policy stuff. which is in
hardened-refpolicy.git and then every few weeks we make a release and
bump all the packages in sec-policy/selinux-*. For things that do not
need an actual release we just skip INPROG and go straight to TESTREQ
when we fix the ebuild in the tree.

The important part to me is that RESO/FIXED should only mean fixed when
the problem is fixed in the stable tree too. There has to be another
state before FIXED that is for ~arch. If the package is not stable on
any arch then of course it is FIXED as soon as ~arch is fixed.

> IN_PROGRESS can thus only mean something about it being worked on but not yet 
> pushed
> to the main git repo. (ie: overlays, private repos)
> 
> But I would rather it part of the primary resolution path, not a mere 
> property of the resolution type.
> 
> Because its easier to say:
> 
> UNCONFIRMED -> CONFIRMED -> INPROGRESS -> INVCS -> STABLE
> 
> Than
> 
> UNCONFIRMED -> CONFIRMED -> INPROGRESS -> (RESOLVED/TESTREQ) -> 
> (RESOLVED/FIXED)

They are roughly equivalent, yeah. But I prefer TESTREQ because its
easier to see in the bug list page. You can of course choose which items
are shown in the list in bugzilla but resolution is already there so no
need to add an extra column.

-- Jason

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Jason Zaman]

On Sun, Aug 14, 2016 at 11:35:58PM +0200, Kristian Fiskerstrand wrote:
> During the latest Council meeting it was determined to set up a new
> Working Group to come up with recommendations for improving the state of
> the stable tree at a later Council meeting.

Sign me up!
> 
> Some initial items it was suggested the WG look into is
>  * 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?

In selinux we do:
UNCONFIRMED/CONFIRMED == not fixed yet
IN_PROGRESS == we've put the fix in the git repo
RESO/TESTREQ == new release and in ~arch
RESO/FIXED == the fix is stable now

Both Swift and I use stable so having things stabilized is important and
we dont close bugs till they are actually stable lest we forget later.
Our saved search for selinux bugs lists all bugs that are not RESO/FIXED
or VERIFIED, so RESO/TESTREQ still shows up.

-- Jason

>  * Are there ways to reduce the stabilization lag of packages
>  - looking into the effectiveness of ALLARCHES and its use
>  - possibility for maintainer to stabilize packages themselves for
>architectures they have access to (including whether there might
>be a need for changes to gentoo infrastructure to facilitate
>this)
>  - Tinderboxing / Automatic tools build test packages and reverse
>dependencies in order to assist in stabilization
Toralf runs one. Zorry is working on an auto tinderbox too.

-- Jason

> Other suggestions are up to the WG to come up with and write up a final
> report to the council with the summary of these discussions.
> 
> I've volunteered to chair such as working group. If you want to
> participate in it please respond to this thread. Additionally I've set
> up #gentoo-wg-stable as a place of coordination.
> 
> -- 
> Kristian Fiskerstrand
> OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Chris Reffett]

On August 14, 2016 5:49:48 PM EDT, Kent Fredric  wrote:
>On Sun, 14 Aug 2016 22:45:07 +0100
>Ciaran McCreesh  wrote:
>
>> What's a Working Group, and how is it related to a Project? Shouldn't
>> there be a GLEP to define what a Working Group is first?
>
>So if a group of people wanted to write such a GLEP ... would they have
>to be part of a defined Project first, or would they form a Working
>Group, and then be stuck in a recursive loop needing themselves
>defined before they can define themselves?

Friendly reminder that anyone may submit a GLEP, it doesn't need to be on 
behalf of an official group. If memory serves, there isn't even a requirement 
that the submitter/"champion" even be a Gentoo dev. So although there is a 
theoretical recursion issue, in practice it's a silly question.

creffett
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kent Fredric]

On Sun, 14 Aug 2016 22:57:31 +0100
Ciaran McCreesh  wrote:

> I'm not sure what a group is. Is it anything like a herd?

Its a thing you get when more than one person does a thing.


pgpMXkRM4x5eF.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Anthony G. Basile]

On 8/14/16 5:45 PM, Ciaran McCreesh wrote:
> On Sun, 14 Aug 2016 23:35:58 +0200
> Kristian Fiskerstrand  wrote:
>> During the latest Council meeting it was determined to set up a new
>> Working Group to come up with recommendations for improving the state
>> of the stable tree at a later Council meeting.
> 
> What's a Working Group, and how is it related to a Project? Shouldn't
> there be a GLEP to define what a Working Group is first?
> 

Seriously?!  You mean a group of devs can't just get together to
brainstorm a problem across projects?

Anyhow, Kristian, I'm in.  Put me on the cc list.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kristian Fiskerstrand]

On 08/14/2016 11:45 PM, Ciaran McCreesh wrote:
> On Sun, 14 Aug 2016 23:35:58 +0200
> Kristian Fiskerstrand  wrote:
>> During the latest Council meeting it was determined to set up a new
>> Working Group to come up with recommendations for improving the state
>> of the stable tree at a later Council meeting.
> 
> What's a Working Group, and how is it related to a Project? Shouldn't
> there be a GLEP to define what a Working Group is first?
> 

For this purpose it is an ad-hoc collaboration amongst developers to
come up with recommendations to an already existing project on a limited
set of questions. What would a GLEP contribute?

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Ciaran McCreesh]

On Sun, 14 Aug 2016 23:35:58 +0200
Kristian Fiskerstrand  wrote:
> During the latest Council meeting it was determined to set up a new
> Working Group to come up with recommendations for improving the state
> of the stable tree at a later Council meeting.

What's a Working Group, and how is it related to a Project? Shouldn't
there be a GLEP to define what a Working Group is first?

-- 
Ciaran McCreesh

[gentoo-dev] New Working Group established to evaluate the stable tree

[Kristian Fiskerstrand]

During the latest Council meeting it was determined to set up a new
Working Group to come up with recommendations for improving the state of
the stable tree at a later Council meeting.

Some initial items it was suggested the WG look into is
 * 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?

 * Are there ways to reduce the stabilization lag of packages
 - looking into the effectiveness of ALLARCHES and its use
 - possibility for maintainer to stabilize packages themselves for
   architectures they have access to (including whether there might
   be a need for changes to gentoo infrastructure to facilitate
   this)
 - Tinderboxing / Automatic tools build test packages and reverse
   dependencies in order to assist in stabilization

Other suggestions are up to the WG to come up with and write up a final
report to the council with the summary of these discussions.

I've volunteered to chair such as working group. If you want to
participate in it please respond to this thread. Additionally I've set
up #gentoo-wg-stable as a place of coordination.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature