[gentoo-project] Council meeting 2015-04-14: call for agenda items

[gentoo-project] Council meeting 2015-04-14: call for agenda items

[Tim Harder]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

The next council meeting will be on April 14th, 19:00 UTC in
#gentoo-council on Freenode.

Please respond to this message on the gentoo-project list with any
agenda items you want to propose or discuss.

Thanks,
Tim

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-project] Council meeting 2015-04-14: call for agenda items

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

>>>>> On Thu, 2 Apr 2015, Tim Harder wrote:

> The next council meeting will be on April 14th, 19:00 UTC in
> #gentoo-council on Freenode.

> Please respond to this message on the gentoo-project list with any
> agenda items you want to propose or discuss.

Please let us vote on a feature freeze for EAPI 6, with features
as listed in [1].

I'll then try to get the specification [2] ready for review. It is
almost complete; only the spec for the eapply function is still
missing.

Ulrich


[1] https://wiki.gentoo.org/index.php?title=Future_EAPI/EAPI_6_tentative_features&oldid=267018
[2] https://gitweb.gentoo.org/proj/pms.git/log/?h=eapi-6

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michael Palimaka]

On 03/04/15 01:14, Tim Harder wrote:
> The next council meeting will be on April 14th, 19:00 UTC in
> #gentoo-council on Freenode.
> 
> Please respond to this message on the gentoo-project list with any
> agenda items you want to propose or discuss.
> 
> Thanks,
> Tim
> 

Could we please revisit lagging arch teams again? Specifically, I'd like
to see the package-by-package proposal extended to other minor archs
including ppc and ppc64.

In the worst cases wait time approaches and sometimes even exceeds one
year and I'd really like to be able to remove old versions.

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Fri, Apr 3, 2015 at 3:33 PM, Michael Palimaka <kensington@gentoo.org> wrote:
> On 03/04/15 01:14, Tim Harder wrote:
>> The next council meeting will be on April 14th, 19:00 UTC in
>> #gentoo-council on Freenode.
>>
>> Please respond to this message on the gentoo-project list with any
>> agenda items you want to propose or discuss.
>>
>> Thanks,
>> Tim
>>
>
> Could we please revisit lagging arch teams again? Specifically, I'd like
> to see the package-by-package proposal extended to other minor archs
> including ppc and ppc64.
>

If we're going to bring this up, is sparc a concern for anybody?  I
mention it only because it was brought up last time, not because I
have any specific reason to have concerns with them.  If we're going
to discuss this again, we might as well be holistic.

For that matter, part of me wonders if this should really be a "minor
arch" policy vs just being general policy, and perhaps we should even
consider doing the same thing with x86/amd64.  If for some reason
upstream doesn't support one of those archs or there are no major
issues with moving to the new version, why shouldn't we require arch
teams to stabilize within 90 days even for the big ones?

For reference, the policy we came up with last time for ia64 and alpha only was:

  "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
  pending STABLEREQ, for 90 days with archs CCed and otherwise ready
  to be stabilized, the maintainer can remove older stable versions of
  the package at their discretion. A package is considered ready to be
  stabilized if it has been in the tree for 30 days, and has no known
  major flaws on arches that upstream considers supported."

The "arches that upstream considers supported" bit seems to make this
fairly suitable for anybody.  The intent is to follow upstream, and if
we want to do more then that is on the arch team to make happen unless
the maintainer is willing to do it.

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Andreas K. Huettel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:

> For reference, the policy we came up with last time for ia64 and alpha only was:
> 
>   "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
>   pending STABLEREQ, for 90 days with archs CCed and otherwise ready
>   to be stabilized, the maintainer can remove older stable versions of
>   the package at their discretion. A package is considered ready to be
>   stabilized if it has been in the tree for 30 days, and has no known
>   major flaws on arches that upstream considers supported."

If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVHvSJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5OaEQAKBVYSY9tSFlaeAQdr2o/4UI
n14i5tcbUv3Kz/l3CTYsix8vgx9437ohAjWz6Xo1g04WSAS/hACOA9vQpNWZE9z1
9hvjKzi5X6qzOX+s7nu+nFnXGpQ5hRxVIJ/YtQc+rtaZrKpQnsLLctUuCHi59Vnm
eVDUnQ/ILVa/PXWsMCNbSQbV/5JbXcBvFckP6HTUURfZ4CrmZtd8lkhFAC7Le1mk
5QYtcKmPaXDajhcG/N1i+l2BE/hoR6q0qA9xEscT//Yxu9FTjCDzOLZAGW39/b75
ydURtUeMy97pQyu50oUodybPM0uWKml8LecWLfsGkvFQ02Jw2B9pdSSDpVhL0y4E
JuCMsWFVwxNtVL/fVX3NHgu5e2MARQJvc7ouDsppku8lZfgs3tALxL9vVgllasoe
+d1ehEsHOG+Sx8AACgojjxgr27CRMhVm1YYhb88dBscABMyjv8t8anVsevEYq16c
OnT1Jo+iuHkUYiaiG13Sf3uVop/WtZ5xITQC/B9I9TidOSw7KanqszSK63cTZPm2
PMp5sg+/eJN48bpowFnX7M1FHU/eT5YteHJpUoreteVa+TNRCqwIhrjpqO4ZLm+M
ncYWlvk85voGbYojPvtfk9c/k74QK9Lih0JkX42Y5M583iwrIfPZs7Rlx1OXByfR
1Rdhk4KHFKZbTgStHwqR
=GWmw
-----END PGP SIGNATURE-----

[gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michael Palimaka]

On 04/04/15 07:13, Andreas K. Huettel wrote:
> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:
> 
>> For reference, the policy we came up with last time for ia64 and alpha only was:
> 
>>   "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
>>   pending STABLEREQ, for 90 days with archs CCed and otherwise ready
>>   to be stabilized, the maintainer can remove older stable versions of
>>   the package at their discretion. A package is considered ready to be
>>   stabilized if it has been in the tree for 30 days, and has no known
>>   major flaws on arches that upstream considers supported."
> 
> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.

I am against breaking the deptree for any arch that has a stable
profile. It's reasonable to expect devs to dekeyword revdeps to ensure
the deptree is consistent.
If the state of the arch really is that bad, its profiles should be
switched to dev or exp to reflect reality.

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> On 04/04/15 07:13, Andreas K. Huettel wrote:
>> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:
>>
>>> For reference, the policy we came up with last time for ia64 and alpha only was:
>>
>>>   "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
>>>   pending STABLEREQ, for 90 days with archs CCed and otherwise ready
>>>   to be stabilized, the maintainer can remove older stable versions of
>>>   the package at their discretion. A package is considered ready to be
>>>   stabilized if it has been in the tree for 30 days, and has no known
>>>   major flaws on arches that upstream considers supported."
>>
>> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.
>
> I am against breaking the deptree for any arch that has a stable
> profile. It's reasonable to expect devs to dekeyword revdeps to ensure
> the deptree is consistent.
> If the state of the arch really is that bad, its profiles should be
> switched to dev or exp to reflect reality.
>

Tend to agree, but be careful what you ask for.  Which would the arch
team REALLY prefer after ignoring a bug for 90 days?  The stable
depgraph is broken and they have to hurry and stabilize one package to
fix it, OR the stable depgraph is fine, but suddenly 300 packages no
longer have stable keywords at all.  Fixing the latter would be a
royal PITA without git.  Getting rid of stable on those 300 packages
is also a lot of work for the package maintainer without some kind of
tool to automate this.

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

Dnia 2015-04-04, o godz. 11:13:54
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> > On 04/04/15 07:13, Andreas K. Huettel wrote:
> >> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:
> >>
> >>> For reference, the policy we came up with last time for ia64 and alpha only was:
> >>
> >>>   "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
> >>>   pending STABLEREQ, for 90 days with archs CCed and otherwise ready
> >>>   to be stabilized, the maintainer can remove older stable versions of
> >>>   the package at their discretion. A package is considered ready to be
> >>>   stabilized if it has been in the tree for 30 days, and has no known
> >>>   major flaws on arches that upstream considers supported."
> >>
> >> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.
> >
> > I am against breaking the deptree for any arch that has a stable
> > profile. It's reasonable to expect devs to dekeyword revdeps to ensure
> > the deptree is consistent.
> > If the state of the arch really is that bad, its profiles should be
> > switched to dev or exp to reflect reality.
> >
> 
> Tend to agree, but be careful what you ask for.  Which would the arch
> team REALLY prefer after ignoring a bug for 90 days?  The stable
> depgraph is broken and they have to hurry and stabilize one package to
> fix it, OR the stable depgraph is fine, but suddenly 300 packages no
> longer have stable keywords at all.  Fixing the latter would be a
> royal PITA without git.  Getting rid of stable on those 300 packages
> is also a lot of work for the package maintainer without some kind of
> tool to automate this.

What Gentoo developers would really prefer is being able to commit to
packages without using --force just because someone screwed up
the dependency tree. If you don't care about stable working on some
arch, don't mark the arch profiles stable.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

Dnia 2015-04-04, o godz. 11:13:54
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> > On 04/04/15 07:13, Andreas K. Huettel wrote:
> >> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:
> >>
> >>> For reference, the policy we came up with last time for ia64 and alpha only was:
> >>
> >>>   "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
> >>>   pending STABLEREQ, for 90 days with archs CCed and otherwise ready
> >>>   to be stabilized, the maintainer can remove older stable versions of
> >>>   the package at their discretion. A package is considered ready to be
> >>>   stabilized if it has been in the tree for 30 days, and has no known
> >>>   major flaws on arches that upstream considers supported."
> >>
> >> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.
> >
> > I am against breaking the deptree for any arch that has a stable
> > profile. It's reasonable to expect devs to dekeyword revdeps to ensure
> > the deptree is consistent.
> > If the state of the arch really is that bad, its profiles should be
> > switched to dev or exp to reflect reality.
> >
> 
> Tend to agree, but be careful what you ask for.  Which would the arch
> team REALLY prefer after ignoring a bug for 90 days?  The stable
> depgraph is broken and they have to hurry and stabilize one package to
> fix it, OR the stable depgraph is fine, but suddenly 300 packages no
> longer have stable keywords at all.  Fixing the latter would be a
> royal PITA without git.  Getting rid of stable on those 300 packages
> is also a lot of work for the package maintainer without some kind of
> tool to automate this.

What Gentoo developers would really prefer is being able to commit to
packages without using --force just because someone screwed up
the dependency tree. If you don't care about stable working on some
arch, don't mark the arch profiles stable.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]

On Sat, Apr 04, 2015 at 11:13:54AM -0400, Rich Freeman wrote:
> On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> > On 04/04/15 07:13, Andreas K. Huettel wrote:
> >> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:
> >>
> >>> For reference, the policy we came up with last time for ia64 and alpha only was:
> >>
> >>>   "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
> >>>   pending STABLEREQ, for 90 days with archs CCed and otherwise ready
> >>>   to be stabilized, the maintainer can remove older stable versions of
> >>>   the package at their discretion. A package is considered ready to be
> >>>   stabilized if it has been in the tree for 30 days, and has no known
> >>>   major flaws on arches that upstream considers supported."
> >>
> >> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.
> >
> > I am against breaking the deptree for any arch that has a stable
> > profile. It's reasonable to expect devs to dekeyword revdeps to ensure
> > the deptree is consistent.
> > If the state of the arch really is that bad, its profiles should be
> > switched to dev or exp to reflect reality.
> >
> 
> Tend to agree, but be careful what you ask for.  Which would the arch
> team REALLY prefer after ignoring a bug for 90 days?  The stable
> depgraph is broken and they have to hurry and stabilize one package to
> fix it, OR the stable depgraph is fine, but suddenly 300 packages no
> longer have stable keywords at all.  Fixing the latter would be a
> royal PITA without git.  Getting rid of stable on those 300 packages
> is also a lot of work for the package maintainer without some kind of
> tool to automate this.

I agree. I think the temporary stable depgraph breakage is the lesser of
the two evils in this case. Also, I would add that, once an arch team
starts getting hit with enough deptree breakage they should be able to
make the decision to revert their profiles to dev or exp without council
intervention.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Pacho Ramos]

El sáb, 04-04-2015 a las 17:02 -0500, William Hubbs escribió:
> On Sat, Apr 04, 2015 at 11:13:54AM -0400, Rich Freeman wrote:
> > On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> > > On 04/04/15 07:13, Andreas K. Huettel wrote:
> > >> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:
> > >>
> > >>> For reference, the policy we came up with last time for ia64 and alpha only was:
> > >>
> > >>>   "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
> > >>>   pending STABLEREQ, for 90 days with archs CCed and otherwise ready
> > >>>   to be stabilized, the maintainer can remove older stable versions of
> > >>>   the package at their discretion. A package is considered ready to be
> > >>>   stabilized if it has been in the tree for 30 days, and has no known
> > >>>   major flaws on arches that upstream considers supported."
> > >>
> > >> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.
> > >
> > > I am against breaking the deptree for any arch that has a stable
> > > profile. It's reasonable to expect devs to dekeyword revdeps to ensure
> > > the deptree is consistent.
> > > If the state of the arch really is that bad, its profiles should be
> > > switched to dev or exp to reflect reality.
> > >
> > 
> > Tend to agree, but be careful what you ask for.  Which would the arch
> > team REALLY prefer after ignoring a bug for 90 days?  The stable
> > depgraph is broken and they have to hurry and stabilize one package to
> > fix it, OR the stable depgraph is fine, but suddenly 300 packages no
> > longer have stable keywords at all.  Fixing the latter would be a
> > royal PITA without git.  Getting rid of stable on those 300 packages
> > is also a lot of work for the package maintainer without some kind of
> > tool to automate this.
> 
> I agree. I think the temporary stable depgraph breakage is the lesser of
> the two evils in this case. Also, I would add that, once an arch team
> starts getting hit with enough deptree breakage they should be able to
> make the decision to revert their profiles to dev or exp without council
> intervention.
> 
> William
> 

I wonder if maybe we should suggest to finally move ia64/alpha/sparc to
testing (as was done for mips, sh...) :/

If we are willing to break their stable tree, probably would be better
to finally move them to testing (or to only have a really small stable
tree for base-system/toolchain) 

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Ben de Groot]

On 5 April 2015 at 20:32, Pacho Ramos <pacho@gentoo.org> wrote:
> El sáb, 04-04-2015 a las 17:02 -0500, William Hubbs escribió:
>> On Sat, Apr 04, 2015 at 11:13:54AM -0400, Rich Freeman wrote:
>> > On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka <kensington@gentoo.org> wrote:
>> > > On 04/04/15 07:13, Andreas K. Huettel wrote:
>> > >> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:
>> > >>
>> > >>> For reference, the policy we came up with last time for ia64 and alpha only was:
>> > >>
>> > >>>   "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
>> > >>>   pending STABLEREQ, for 90 days with archs CCed and otherwise ready
>> > >>>   to be stabilized, the maintainer can remove older stable versions of
>> > >>>   the package at their discretion. A package is considered ready to be
>> > >>>   stabilized if it has been in the tree for 30 days, and has no known
>> > >>>   major flaws on arches that upstream considers supported."
>> > >>
>> > >> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.
>> > >
>> > > I am against breaking the deptree for any arch that has a stable
>> > > profile. It's reasonable to expect devs to dekeyword revdeps to ensure
>> > > the deptree is consistent.
>> > > If the state of the arch really is that bad, its profiles should be
>> > > switched to dev or exp to reflect reality.
>> > >
>> >
>> > Tend to agree, but be careful what you ask for.  Which would the arch
>> > team REALLY prefer after ignoring a bug for 90 days?  The stable
>> > depgraph is broken and they have to hurry and stabilize one package to
>> > fix it, OR the stable depgraph is fine, but suddenly 300 packages no
>> > longer have stable keywords at all.  Fixing the latter would be a
>> > royal PITA without git.  Getting rid of stable on those 300 packages
>> > is also a lot of work for the package maintainer without some kind of
>> > tool to automate this.
>>
>> I agree. I think the temporary stable depgraph breakage is the lesser of
>> the two evils in this case. Also, I would add that, once an arch team
>> starts getting hit with enough deptree breakage they should be able to
>> make the decision to revert their profiles to dev or exp without council
>> intervention.
>>
>> William
>>
>
> I wonder if maybe we should suggest to finally move ia64/alpha/sparc to
> testing (as was done for mips, sh...) :/
>
> If we are willing to break their stable tree, probably would be better
> to finally move them to testing (or to only have a really small stable
> tree for base-system/toolchain)

In support of this I offer bug #529196.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]

On Sun, Apr 05, 2015 at 02:32:27PM +0200, Pacho Ramos wrote:
> El sáb, 04-04-2015 a las 17:02 -0500, William Hubbs escribió:
> > On Sat, Apr 04, 2015 at 11:13:54AM -0400, Rich Freeman wrote:
> > > On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> > > > On 04/04/15 07:13, Andreas K. Huettel wrote:
> > > >> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman:
> > > >>
> > > >>> For reference, the policy we came up with last time for ia64 and alpha only was:
> > > >>
> > > >>>   "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
> > > >>>   pending STABLEREQ, for 90 days with archs CCed and otherwise ready
> > > >>>   to be stabilized, the maintainer can remove older stable versions of
> > > >>>   the package at their discretion. A package is considered ready to be
> > > >>>   stabilized if it has been in the tree for 30 days, and has no known
> > > >>>   major flaws on arches that upstream considers supported."
> > > >>
> > > >> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though.
> > > >
> > > > I am against breaking the deptree for any arch that has a stable
> > > > profile. It's reasonable to expect devs to dekeyword revdeps to ensure
> > > > the deptree is consistent.
> > > > If the state of the arch really is that bad, its profiles should be
> > > > switched to dev or exp to reflect reality.
> > > >
> > > 
> > > Tend to agree, but be careful what you ask for.  Which would the arch
> > > team REALLY prefer after ignoring a bug for 90 days?  The stable
> > > depgraph is broken and they have to hurry and stabilize one package to
> > > fix it, OR the stable depgraph is fine, but suddenly 300 packages no
> > > longer have stable keywords at all.  Fixing the latter would be a
> > > royal PITA without git.  Getting rid of stable on those 300 packages
> > > is also a lot of work for the package maintainer without some kind of
> > > tool to automate this.
> > 
> > I agree. I think the temporary stable depgraph breakage is the lesser of
> > the two evils in this case. Also, I would add that, once an arch team
> > starts getting hit with enough deptree breakage they should be able to
> > make the decision to revert their profiles to dev or exp without council
> > intervention.
> > 
> > William
> > 
> 
> I wonder if maybe we should suggest to finally move ia64/alpha/sparc to
> testing (as was done for mips, sh...) :/
 
Also let's add ppc and ppc64 to this list; they were brought up in the
message starting this discussion. I personally would vote for moving all
of these arch's to exp status.

That becomes a separate action and does not answer the underlying
question that keeps coming up.

That question is, if a maintainer opens a stable request and assigns an
arch team to it, and that arch team has no activity on the stable
request for 90 days, what should the maintainer do?

I would say that the maintainer can at their discression remove the
old stable version. Yes, that would temporarily break the stable
depgraph, but it could be argued that the old version is by definition
broken since the newer version the maintainer wants stabilized could
have fixes for bugs in the old version.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Sun, 5 Apr 2015 14:50:44 -0500
William Hubbs <williamh@gentoo.org> wrote:

> > I wonder if maybe we should suggest to finally move
> > ia64/alpha/sparc to testing (as was done for mips, sh...) :/  
>  
> Also let's add ppc and ppc64 to this list; they were brought up in the
> message starting this discussion. I personally would vote for moving
> all of these arch's to exp status.

Recent discussions about which Java JDKs to continue supporting have
made me wonder just how many people are using these archs and how many
people are using Java on them. I am trying to nudge all non amd64/x86
archs towards icedtea so should we bother continuing to support IBM's
JDK given that it is proprietary, primarily there to cater for ppc(64),
and you have to register before you can even download it? Just how many
users are we going out of our way to support here? It makes me wish we
had something like Debian's popularity-contest.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

On Sun, 5 Apr 2015 14:50:44 -0500 William Hubbs wrote:
[...]
> > I wonder if maybe we should suggest to finally move ia64/alpha/sparc to
> > testing (as was done for mips, sh...) :/
>  
> Also let's add ppc and ppc64 to this list; they were brought up in the
> message starting this discussion. I personally would vote for moving all
> of these arch's to exp status.
> 
> That becomes a separate action and does not answer the underlying
> question that keeps coming up.
> 
> That question is, if a maintainer opens a stable request and assigns an
> arch team to it, and that arch team has no activity on the stable
> request for 90 days, what should the maintainer do?
>
> I would say that the maintainer can at their discression remove the
> old stable version. Yes, that would temporarily break the stable
> depgraph, but it could be argued that the old version is by definition
> broken since the newer version the maintainer wants stabilized could
> have fixes for bugs in the old version.

Why to apply for actions such extreme as moving arch to dev/exp
state or breaking its stable tree? There are more elegant solutions
available.

0. Set "deadline" to 90 days for ordinary stable requests and 30
days for security-related stable requests. Numbers are may be
discussed and changed, but the idea is that time constraints for
response on security issues (especially critical security issues)
should be tighter than for ordinary bugs.

Then if time limits above are expired:

1. If developers have an access to a setup for an affected arch
(e.g. can test packages on that arch), allow developers to stabilize
packages themselves.

2. Otherwise allow developers to drop stable keywords from affected
package and _all_ its reverse dependencies. This way a part of
stable tree will be removed, but only a part. With this approach
arch teams will be freed of an extra burden, while they will be
still able to maintain a smaller stable tree.

This is a win-win solution: a stable tree will be still kept in a
maintainable size and developers will not have a long-term blockers
on their stabilization requests.

3. And last but not the least: apply the rules above to all arches,
not just minor teams (though probability that amd64/x86 will be
slow is lower, of course).

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Sun, Apr 5, 2015 at 5:27 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> 2. Otherwise allow developers to drop stable keywords from affected
> package and _all_ its reverse dependencies. This way a part of
> stable tree will be removed, but only a part. With this approach
> arch teams will be freed of an extra burden, while they will be
> still able to maintain a smaller stable tree.
>
> This is a win-win solution: a stable tree will be still kept in a
> maintainable size and developers will not have a long-term blockers
> on their stabilization requests.
>
> 3. And last but not the least: apply the rules above to all arches,
> not just minor teams (though probability that amd64/x86 will be
> slow is lower, of course).
>

This was some of what I was getting at.  My question still stands that
I'm not sure arch teams REALLY want 300 packages to have their stable
keywords removed instead of just having one package break the
depgraph.  When we move to git then this won't be as big a deal, as
they could easily undo all the keywords in the same commit that fixes
the original STABLEREQ.

I would prefer to get at a more generic policy that can be applied
everywhere, and not just arch by arch.  Being able to keep up or not
isn't really a black/white thing.  Or rather, if it is I think it is
more a case that nobody can keep up.  I think that it would be better
to have one policy that makes sense on any arch, and as you point out
it probably won't tend to get applied much to amd64/x86 simply because
they are better supported.

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Patrick Lauer]

On 04/06/15 06:54, Rich Freeman wrote:
> On Sun, Apr 5, 2015 at 5:27 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>>
>> 2. Otherwise allow developers to drop stable keywords from affected
>> package and _all_ its reverse dependencies. This way a part of
>> stable tree will be removed, but only a part. With this approach
>> arch teams will be freed of an extra burden, while they will be
>> still able to maintain a smaller stable tree.
>>
>> This is a win-win solution: a stable tree will be still kept in a
>> maintainable size and developers will not have a long-term blockers
>> on their stabilization requests.
>>
>> 3. And last but not the least: apply the rules above to all arches,
>> not just minor teams (though probability that amd64/x86 will be
>> slow is lower, of course).
>>
> 
> This was some of what I was getting at.  My question still stands that
> I'm not sure arch teams REALLY want 300 packages to have their stable
> keywords removed instead of just having one package break the
> depgraph.  When we move to git then this won't be as big a deal, as
> they could easily undo all the keywords in the same commit that fixes
> the original STABLEREQ.

I strongly prefer removing stable keywords of all reverse dependencies
over random 'transient' breakage that won't be fixed in a reasonable
timeframe (we're starting from the assumption that the relevant arch
team didn't respond in *months* ...)

How git is relevant I don't really see, you'd still have to re-test all
involved packages, so the effort is mostly in testing and not in running
ekeyword in a loop.

Have fun,

Patrick

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Sun, Apr 5, 2015 at 7:05 PM, Patrick Lauer <patrick@gentoo.org> wrote:
>
> How git is relevant I don't really see, you'd still have to re-test all
> involved packages, so the effort is mostly in testing and not in running
> ekeyword in a loop.
>

If you removed stable keywords from 300 packages, they would be in a
single git commit.  That means you can restore those keywords in a
single command once you've checked that the new library can be made
stable.  The benefit of git is that tree-wide operations are atomic.

Generally speaking arch teams do not test EVERY reverse dependency of
a library with the stable branch before stabilizing it.  Certainly
arch teams that can't even keep up with stable requests will not do
so.

I'm not saying I'm in favor of breaking the stable depgraph.  I just
think that we need to think through the effects of removing hundreds
of keywords on users (as bircoph points out in his reply).  Neither
option is terribly great.

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

Dnia 2015-04-05, o godz. 20:47:51
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Sun, Apr 5, 2015 at 7:05 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> >
> > How git is relevant I don't really see, you'd still have to re-test all
> > involved packages, so the effort is mostly in testing and not in running
> > ekeyword in a loop.
> >
> 
> If you removed stable keywords from 300 packages, they would be in a
> single git commit.  That means you can restore those keywords in a
> single command once you've checked that the new library can be made
> stable.  The benefit of git is that tree-wide operations are atomic.

Which is a moot point since once user gets hit by 300 packages
suddenly going ~arch, he has no point in using stable anymore.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Pacho Ramos]

El dom, 05-04-2015 a las 20:47 -0400, Rich Freeman escribió:
> On Sun, Apr 5, 2015 at 7:05 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> >
> > How git is relevant I don't really see, you'd still have to re-test all
> > involved packages, so the effort is mostly in testing and not in running
> > ekeyword in a loop.
> >
> 
> If you removed stable keywords from 300 packages, they would be in a
> single git commit.  That means you can restore those keywords in a
> single command once you've checked that the new library can be made
> stable.  The benefit of git is that tree-wide operations are atomic.
> 
> Generally speaking arch teams do not test EVERY reverse dependency of
> a library with the stable branch before stabilizing it.  Certainly
> arch teams that can't even keep up with stable requests will not do
> so.
> 
> I'm not saying I'm in favor of breaking the stable depgraph.  I just
> think that we need to think through the effects of removing hundreds
> of keywords on users (as bircoph points out in his reply).  Neither
> option is terribly great.
> 

From my point of view, I think we should *for now* focus on the affected
arches instead of trying to find a completely general policy to fit all
arches. 

For instance, in this topic I haven't seen any comment from
alpha/ia64/sparc arch teams... I think those would be the fist
candidates for moving to testing only. On the other hand, Blueness has
multiple times replied for trying to handle ppc* (I also joined those
teams to try to help... I try but I don't have enough time for handling
all, in summary, when I have time, I am able then to do amd64, x86, ppc
and ppc64 at the same time, but not much more sadly :(. Maybe for ppc*
would be much more feasible to try to shrink their stable tree but still
keep a stable tree.

Also, for HPPA and ARM I have no complaints for now, then, I am unsure
if a general policy for all arches is really needed (or needs to block
the move to testing of, for example, ia64 and alpha)

That is the reason why I suggest at this stage to start suggesting to
move alpha/ia64/sparc to testing. Once the current arch team members are
then able to focus on remaining arches (as some of them won't need to
spend time on alpha/ia64/sparc anymore and, then, they should then have
more time for the others), we can re-evaluate then the situation of
remaining arches and try to handle them in the near future if needed.

But that is only my opinion of course :)

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Matt Turner]

On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> For instance, in this topic I haven't seen any comment from
> alpha/ia64/sparc arch teams...

I haven't commented because I don't honestly believe people care.

I'm really disappointed that the discussion is entirely about creating
keyword-dropping policies and no one is asking whether there are
things we can do to make keyword/stable requests a more streamlined
process. But, that kind of thing seems to be par for the course on
this list.

Keywording and stabilizing is a really boring process. It's really
hard for me to get excited about doing it, and when I do I'm quickly
demotivated by having the latency between starting and actually
testing the package.

I've wanted for a long time a system that can help reduce the time I
have to sit in front of a computer waiting for things to finish
compiling before I can test them. Trawl bugzilla, grab package lists,
go build binpkgs. Just let me grab binpkgs and actually test the
software...

As it is today, it's far too much of a manual process with a lot of
tedious (and automatable) steps. I'm really surprised Gentoo has been
as successful as it has without some kind of system like this.

[gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michael Palimaka]

On 07/04/15 08:22, Matt Turner wrote:
> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@gentoo.org> wrote:
>> For instance, in this topic I haven't seen any comment from
>> alpha/ia64/sparc arch teams...
> 
> I haven't commented because I don't honestly believe people care.
> 
> I'm really disappointed that the discussion is entirely about creating
> keyword-dropping policies and no one is asking whether there are
> things we can do to make keyword/stable requests a more streamlined
> process. But, that kind of thing seems to be par for the course on
> this list.

We've heard very little from arch teams at all, let alone proposals for
improving the stabilisation process. That's the main reason this sort of
topic keeps coming up.

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Anthony G. Basile]

On 04/07/15 11:38, Michael Palimaka wrote:
> On 07/04/15 08:22, Matt Turner wrote:
>> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@gentoo.org> wrote:
>>> For instance, in this topic I haven't seen any comment from
>>> alpha/ia64/sparc arch teams...
>> I haven't commented because I don't honestly believe people care.
>>
>> I'm really disappointed that the discussion is entirely about creating
>> keyword-dropping policies and no one is asking whether there are
>> things we can do to make keyword/stable requests a more streamlined
>> process. But, that kind of thing seems to be par for the course on
>> this list.
> We've heard very little from arch teams at all, let alone proposals for
> improving the stabilisation process. That's the main reason this sort of
> topic keeps coming up.
>
>

I don't want my silence to be misinterpreted regarding ppc and ppc64.  
For those arches, I'm willing to trim back on stabilization, but I 
really don't want to drop to ~ as we did for mips.  In fact, I'm 
thinking of turning mips itself back into a stable arches with just the 
@system packages being candidates for stabilization.  The reason I like 
this approach is when I build stage3's I can control what I know will 
build (stable packages) vs the latest packages added to the tree 
(~arch).  Nothing is more painful than have to manually intervene in a 
bunch of catalyst builds.  Being able to control what will be built via 
stable keywords saves time and effort.

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

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Tue, Apr 7, 2015 at 7:25 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> On 04/07/15 11:38, Michael Palimaka wrote:
>>
>> On 07/04/15 08:22, Matt Turner wrote:
>>>
>>> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@gentoo.org> wrote:
>>>>
>>>> For instance, in this topic I haven't seen any comment from
>>>> alpha/ia64/sparc arch teams...
>>>
>>> I haven't commented because I don't honestly believe people care.
>>>
>>> I'm really disappointed that the discussion is entirely about creating
>>> keyword-dropping policies and no one is asking whether there are
>>> things we can do to make keyword/stable requests a more streamlined
>>> process. But, that kind of thing seems to be par for the course on
>>> this list.
>>
>> We've heard very little from arch teams at all, let alone proposals for
>> improving the stabilisation process. That's the main reason this sort of
>> topic keeps coming up.
>
> I don't want my silence to be misinterpreted regarding ppc and ppc64.  For
> those arches, I'm willing to trim back on stabilization, but I really don't
> want to drop to ~ as we did for mips.  In fact, I'm thinking of turning mips
> itself back into a stable arches with just the @system packages being
> candidates for stabilization.  The reason I like this approach is when I
> build stage3's I can control what I know will build (stable packages) vs the
> latest packages added to the tree (~arch).  Nothing is more painful than
> have to manually intervene in a bunch of catalyst builds.  Being able to
> control what will be built via stable keywords saves time and effort.
>

Would you be willing to monitor stablereqs and for ones that you can't
keep up with, go ahead and remove stable keywords proactively on your
own?  The main concern is that this is a lot of hassle for
maintainers.  If the arch team can keep up with maintainers either by
stabilizing packages or unstabilizing them, I think that will satisfy
everybody.

Alternatively, we can just change the status of the arch in repoman.
Then you can keep your stable keywords if you wish, but package
maintainers can also break your stable depgraph.

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Anthony G. Basile]

On 04/07/15 19:29, Rich Freeman wrote:
> On Tue, Apr 7, 2015 at 7:25 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> On 04/07/15 11:38, Michael Palimaka wrote:
>>> On 07/04/15 08:22, Matt Turner wrote:
>>>> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@gentoo.org> wrote:
>>>>> For instance, in this topic I haven't seen any comment from
>>>>> alpha/ia64/sparc arch teams...
>>>> I haven't commented because I don't honestly believe people care.
>>>>
>>>> I'm really disappointed that the discussion is entirely about creating
>>>> keyword-dropping policies and no one is asking whether there are
>>>> things we can do to make keyword/stable requests a more streamlined
>>>> process. But, that kind of thing seems to be par for the course on
>>>> this list.
>>> We've heard very little from arch teams at all, let alone proposals for
>>> improving the stabilisation process. That's the main reason this sort of
>>> topic keeps coming up.
>> I don't want my silence to be misinterpreted regarding ppc and ppc64.  For
>> those arches, I'm willing to trim back on stabilization, but I really don't
>> want to drop to ~ as we did for mips.  In fact, I'm thinking of turning mips
>> itself back into a stable arches with just the @system packages being
>> candidates for stabilization.  The reason I like this approach is when I
>> build stage3's I can control what I know will build (stable packages) vs the
>> latest packages added to the tree (~arch).  Nothing is more painful than
>> have to manually intervene in a bunch of catalyst builds.  Being able to
>> control what will be built via stable keywords saves time and effort.
>>
> Would you be willing to monitor stablereqs and for ones that you can't
> keep up with, go ahead and remove stable keywords proactively on your
> own?  The main concern is that this is a lot of hassle for
> maintainers.  If the arch team can keep up with maintainers either by
> stabilizing packages or unstabilizing them, I think that will satisfy
> everybody.
>
> Alternatively, we can just change the status of the arch in repoman.
> Then you can keep your stable keywords if you wish, but package
> maintainers can also break your stable depgraph.
>

We had a couple of ideas in this direction.  One is a "weak" 
stabilization criterion for ppc/ppc64.  If the package builds for amd64, 
go ahead and mark ppc/ppc64 stable as well.  This is bound to hit 
problems but we'll catch them after the fact.  Another idea was to 
generate a list of packages we want to target as stable on ppc/ppc64 and 
drop stable keywords on all but those packages, then continue as we do 
now.  Your idea Rich is actually a variation on this in that we can just 
unstabilize as we go along rather than generating the list and doing it 
all at once.  That might be workable.

What's holding me back right now is that when the ppc/ppc64 team met 
last year we said we were going to keep going as we have been.  I'm 
hoping ppc/ppc64 can meet again soon and readdress this issue.

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

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]

On Tue, Apr 07, 2015 at 07:29:31PM -0400, Rich Freeman wrote:
> On Tue, Apr 7, 2015 at 7:25 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> > On 04/07/15 11:38, Michael Palimaka wrote:
> >>
> >> On 07/04/15 08:22, Matt Turner wrote:
> >>>
> >>> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> >>>>
> >>>> For instance, in this topic I haven't seen any comment from
> >>>> alpha/ia64/sparc arch teams...
> >>>
> >>> I haven't commented because I don't honestly believe people care.
> >>>
> >>> I'm really disappointed that the discussion is entirely about creating
> >>> keyword-dropping policies and no one is asking whether there are
> >>> things we can do to make keyword/stable requests a more streamlined
> >>> process. But, that kind of thing seems to be par for the course on
> >>> this list.
> >>
> >> We've heard very little from arch teams at all, let alone proposals for
> >> improving the stabilisation process. That's the main reason this sort of
> >> topic keeps coming up.
> >
> > I don't want my silence to be misinterpreted regarding ppc and ppc64.  For
> > those arches, I'm willing to trim back on stabilization, but I really don't
> > want to drop to ~ as we did for mips.  In fact, I'm thinking of turning mips
> > itself back into a stable arches with just the @system packages being
> > candidates for stabilization.  The reason I like this approach is when I
> > build stage3's I can control what I know will build (stable packages) vs the
> > latest packages added to the tree (~arch).  Nothing is more painful than
> > have to manually intervene in a bunch of catalyst builds.  Being able to
> > control what will be built via stable keywords saves time and effort.
> >
> 
> Would you be willing to monitor stablereqs and for ones that you can't
> keep up with, go ahead and remove stable keywords proactively on your
> own?  The main concern is that this is a lot of hassle for
> maintainers.  If the arch team can keep up with maintainers either by
> stabilizing packages or unstabilizing them, I think that will satisfy
> everybody.
> 
> Alternatively, we can just change the status of the arch in repoman.
> Then you can keep your stable keywords if you wish, but package
> maintainers can also break your stable depgraph.

Changing the status of the arches in repoman is all I thought we were
discussing. I wasn't saying we should revert or remove stable keywords
for them. I think that's what vapier is doing with s390, sh, etc.

Marking the arches dev or exp in the profiles means that repoman, by
default, doesn't complain about broken depgraphs for them.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Wed, Apr 8, 2015 at 7:51 AM, William Hubbs <williamh@gentoo.org> wrote:
>
> Changing the status of the arches in repoman is all I thought we were
> discussing. I wasn't saying we should revert or remove stable keywords
> for them. I think that's what vapier is doing with s390, sh, etc.
>
> Marking the arches dev or exp in the profiles means that repoman, by
> default, doesn't complain about broken depgraphs for them.

Well, we really have a few options as far as imposing changes from
outside the arch team goes (the arch team can clean up its own
depgraph, of course, but presumably we'd be taking action only if they
didn't).

1.  We could make the arches dev/exp as you point out, and then allow
maintainers to just drop stable versions and break their depgraph.

2.  We could keep the arches as stable, but then allow maintainers to
do massive keyword changes when they drop otherwise-stable versions.
That wouldn't break the depgraph, but it would mean that at random
times huge numbers of packages could have their keywords change.

Neither option is really ideal.  I think that #1 is the lesser evil,
but that does mean that we need to make a distro-wide decision.  The
advantage of #2 is that it basically is a NOP unless the arch team
actually reaches 90 days old.  I think it is better to just have the
Council make a decision rather than kicking the can, but that said if
an arch team is willing to state clearly that they intend to
proactively clean up their depgraph and that they want to keep stable
keywords, I'm fine with checking back in a month rather than
de-stabilizing them next week.

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

On Wed, Apr 08, 2015 at 09:33:39AM -0400, Rich Freeman wrote:
> Well, we really have a few options as far as imposing changes from
> outside the arch team goes (the arch team can clean up its own
> depgraph, of course, but presumably we'd be taking action only if they
> didn't).
> 
> 1.  We could make the arches dev/exp as you point out, and then allow
> maintainers to just drop stable versions and break their depgraph.
> 
> 2.  We could keep the arches as stable, but then allow maintainers to
> do massive keyword changes when they drop otherwise-stable versions.
> That wouldn't break the depgraph, but it would mean that at random
> times huge numbers of packages could have their keywords change.
 
 It seems like the only difference between these two options would be
 who is responsible for fixing the depgraph. Let me say why I'm thinking
 this.

Suppose that foo-1 is stable everywhere and I'm looking at a stable
request for foo-2. I'm passed 90 days since I assigned the arch teams to
this stable request. Also, foo is unslotted.

Removing foo-1, or moving it back to ~arch, is going to have the same affect
for all arches where it was stable and foo-2 is not, so I'm thinking I
may as well remove foo-1.

The difference, for stable vs non-stable arches, is that I will get
complaints from repoman when I remove foo-1 for stable arches and I
should also fix those.

 Is this right?

> Neither option is really ideal.  I think that #1 is the lesser evil,
> but that does mean that we need to make a distro-wide decision.  The
> advantage of #2 is that it basically is a NOP unless the arch team
> actually reaches 90 days old.  I think it is better to just have the
> Council make a decision rather than kicking the can, but that said if
> an arch team is willing to state clearly that they intend to
> proactively clean up their depgraph and that they want to keep stable
> keywords, I'm fine with checking back in a month rather than
> de-stabilizing them next week.

Option #2 really isn't a NOP. It would say that maintainers have
permission to remove old stable versions of a package when arch teams
take more than 90 days to respond to a stable request for a newer
version of the package.

Also, do we have to make a distro-wide decision about whether an arch is
stable? I realize we have been the ones making those decisions, but I
don't think there is a policy that requires us to.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Wed, Apr 8, 2015 at 1:39 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Wed, Apr 08, 2015 at 09:33:39AM -0400, Rich Freeman wrote:
>> Well, we really have a few options as far as imposing changes from
>> outside the arch team goes (the arch team can clean up its own
>> depgraph, of course, but presumably we'd be taking action only if they
>> didn't).
>>
>> 1.  We could make the arches dev/exp as you point out, and then allow
>> maintainers to just drop stable versions and break their depgraph.
>>
>> 2.  We could keep the arches as stable, but then allow maintainers to
>> do massive keyword changes when they drop otherwise-stable versions.
>> That wouldn't break the depgraph, but it would mean that at random
>> times huge numbers of packages could have their keywords change.
>
>  It seems like the only difference between these two options would be
>  who is responsible for fixing the depgraph. Let me say why I'm thinking
>  this.
>
> Suppose that foo-1 is stable everywhere and I'm looking at a stable
> request for foo-2. I'm passed 90 days since I assigned the arch teams to
> this stable request. Also, foo is unslotted.
>
> Removing foo-1, or moving it back to ~arch, is going to have the same affect
> for all arches where it was stable and foo-2 is not, so I'm thinking I
> may as well remove foo-1.
>
> The difference, for stable vs non-stable arches, is that I will get
> complaints from repoman when I remove foo-1 for stable arches and I
> should also fix those.
>
>  Is this right?

No.  In neither option would you move foo-1 to ~arch.  In neither
option would you get repoman complaints.

In option 1 you would delete foo-1.  Users of the arch will start
getting errors when they try to do updates, since foo-2 is keyword
masked.  Users could just accept ~arch for foo-2 to fix this most
likely, though it may not work in some cases.  The arch team can clean
up the depgraph at some point as well.  You don't ever get repoman
complaints because the arch is set to dev/exp, and is ignored by
repoman.

In option 2 you would STILL delete foo-1, and you would also change
all of its reverse dependencies to ~arch as well.  Users of the arch
would get errors when they try to do updates, since many packages they
have installed are now keyword masked, and foo-2 is also keyword
masked.  Users would have to accept ~arch for all those packages to
restore normal operation.  Later the arch maintainers could restore
the depgraph to what it was before while stabilizing foo-2, which
involves fixing many packages potentially, and even if it all ends up
as stable again users have tons of cruft in their config files.  You
don't ever get repoman complaints because the depgraph was always
consistent.


>
>> Neither option is really ideal.  I think that #1 is the lesser evil,
>> but that does mean that we need to make a distro-wide decision.  The
>> advantage of #2 is that it basically is a NOP unless the arch team
>> actually reaches 90 days old.  I think it is better to just have the
>> Council make a decision rather than kicking the can, but that said if
>> an arch team is willing to state clearly that they intend to
>> proactively clean up their depgraph and that they want to keep stable
>> keywords, I'm fine with checking back in a month rather than
>> de-stabilizing them next week.
>
> Option #2 really isn't a NOP. It would say that maintainers have
> permission to remove old stable versions of a package when arch teams
> take more than 90 days to respond to a stable request for a newer
> version of the package.
>

Option #2 is a NOP in the sense that the Council doesn't have to do
anything that has an immediate effect.  Basically we'd just be
deputizing every maintainer out there to purge keywords on any arch in
the list we approve anytime it gets out of hand.  So, if an arch has
no STABLEREQs older than 90 days today, nothing happens today, but if
in six months a glibc STABLEREQ is ignored for 91 days the maintainers
can go ahead and remove every single stable keyword on the arch (to
pick an extreme example).

> Also, do we have to make a distro-wide decision about whether an arch is
> stable? I realize we have been the ones making those decisions, but I
> don't think there is a policy that requires us to.

The only thing we're required to do as a matter of policy is to show
up for a meeting and bang the gavel twice.

I don't really like just kicking the can down the street though.  If
an arch really thinks an extra 30 days will let them become proactive
about trimming their keywords I don't mind giving an extension, but I
really don't want to end this Council term with maintainers
complaining about aging STABLEREQ bugs that they are powerless to do
anything about, and I don't think having random maintainers basically
treecleaning arches is a great solution either even if it lets us
point fingers.

I don't see this as picking favorites - x86 is more important than
sparc or whatever.  All we're doing is just assessing whether an arch
team is able to proactively manage their stable keywords or not.  If
an arch has only a single package marked stable, and they keep up with
just that one package, then they can stay stable in repoman.  If an
arch isn't doing that, then users deserve to know this and understand
the implications.  It means that at any time stuff that is marked as
stable could stop being stable, or could be really out of date.  It
means that they need to be more careful about the weight they give to
a stable keyword.  I just see this as being about truth in
advertising.

Stable keywords are a bit like a contract between package maintainers
and arch maintainers.  The package maintainers agree to maintain
things in a way that keeps the stable experience stable.  The arch
maintainers agree that in exchange they will keep up with stable
requests so that package maintainers aren't dealing with cruft.  When
the package maintainer violates their end of the deal, QA descends on
them.  When the arch maintainers violate their end of the deal, the
Council marks their arch non-stable.  This is a reversible decision.
Arch maintainers can control the size of their commitment by not
keywording things as stable in the first place, and removing stable
keywords when they can't keep up.

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]

On Wed, Apr 08, 2015 at 02:15:26PM -0400, Rich Freeman wrote:

*snip*

> No.  In neither option would you move foo-1 to ~arch.  In neither
> option would you get repoman complaints.
> 
> In option 1 you would delete foo-1.  Users of the arch will start
> getting errors when they try to do updates, since foo-2 is keyword
> masked.  Users could just accept ~arch for foo-2 to fix this most
> likely, though it may not work in some cases.  The arch team can clean
> up the depgraph at some point as well.  You don't ever get repoman
> complaints because the arch is set to dev/exp, and is ignored by
> repoman.
> 
> In option 2 you would STILL delete foo-1, and you would also change
> all of its reverse dependencies to ~arch as well.  Users of the arch
> would get errors when they try to do updates, since many packages they
> have installed are now keyword masked, and foo-2 is also keyword
> masked.  Users would have to accept ~arch for all those packages to
> restore normal operation.  Later the arch maintainers could restore
> the depgraph to what it was before while stabilizing foo-2, which
> involves fixing many packages potentially, and even if it all ends up
> as stable again users have tons of cruft in their config files.  You
> don't ever get repoman complaints because the depgraph was always
> consistent.

Option 2 could get complicated really fast.
Consider a reverse dependency that has multiple forward dependencies:

For example, foo-2 adds some functionality that depends on libbar. bas
and bat also depend on libbar. libbar, bas and bat go stable before the
deadline for foo-2. Given your description, it sounds like I would rm
foo-1 and move libbar, bas and bat back to ~. Is that correct?

If that's the case, option 1 is the best option.

If we are willing to consider it, there may be another option. I haven't
tested this yet, I'm just thinking off the top of my head.

3. Option 1, but don't set the profile status to dev or exp. The
repoman messages that you would get on a stable arch if you do this
might guide you to the remaining packages you need to move back to ~.

Thoughts?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Wed, Apr 8, 2015 at 6:41 PM, William Hubbs <williamh@gentoo.org> wrote:
>
> 3. Option 1, but don't set the profile status to dev or exp. The
> repoman messages that you would get on a stable arch if you do this
> might guide you to the remaining packages you need to move back to ~.
>

As mgorny pointed out, that generates tons of repoman errors and
basically blocks anybody from getting anything else done, unless
everybody starts ignoring repoman, which isn't what we want.

If we're going to let people break the stable depgraph I don't think
the profile should be stable.  What does a stable profile even mean if
we start doing that?


-- 
Rich

[gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michael Palimaka]

On 08/04/15 09:29, Rich Freeman wrote:
> Would you be willing to monitor stablereqs and for ones that you can't
> keep up with, go ahead and remove stable keywords proactively on your
> own?

Raúl used to do this, and it worked really well I think.

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Mon, Apr 6, 2015 at 6:22 PM, Matt Turner <mattst88@gentoo.org> wrote:
> I've wanted for a long time a system that can help reduce the time I
> have to sit in front of a computer waiting for things to finish
> compiling before I can test them. Trawl bugzilla, grab package lists,
> go build binpkgs. Just let me grab binpkgs and actually test the
> software...

I approve, and I'm sure the rest of the Council will too.  When will
you have it ready?

Nobody likes any of the options on the table right now.  But, they're
the only options available to us RIGHT NOW.  It would be wonderful if
at some point in the future a better option existed.  You'll have no
trouble convincing the Council to adopt it when it is ready, because
about the only thing I can promise for next week is that whatever
option we approve will suck - just hopefully less than the
alternatives.  If we had a great option available, you probably
wouldn't need to call for a Council vote on it.  It doesn't make for
great popularity, but we're all smart folks, so the only reason we
need a Council is for those cases where there isn't an obvious
solution we can all just line up behind.

In any case, the whole reason we call for list discussion before
voting is so that people have an opportunity to offer better
suggestions, and point out issues with the ones that have been
proposed.  If we didn't care, we'd just shoot from the hip and
everybody could spend their time discussing how out of touch we are
instead.  :)

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Francesco Riosa]

Il 08/04/2015 01:38, Rich Freeman ha scritto:
> On Mon, Apr 6, 2015 at 6:22 PM, Matt Turner <mattst88@gentoo.org> wrote:
>> I've wanted for a long time a system that can help reduce the time I
>> have to sit in front of a computer waiting for things to finish
>> compiling before I can test them. Trawl bugzilla, grab package lists,
>> go build binpkgs. Just let me grab binpkgs and actually test the
>> software...
> I approve, and I'm sure the rest of the Council will too.  When will
> you have it ready?

Actually more than one could object that testing pre-compiled packages
makes no sense for Gentoo.


>
> Nobody likes any of the options on the table right now.  But, they're
> the only options available to us RIGHT NOW.  It would be wonderful if
> at some point in the future a better option existed.  You'll have no
> trouble convincing the Council to adopt it when it is ready, because
> about the only thing I can promise for next week is that whatever
> option we approve will suck - just hopefully less than the
> alternatives.  If we had a great option available, you probably
> wouldn't need to call for a Council vote on it.  It doesn't make for
> great popularity, but we're all smart folks, so the only reason we
> need a Council is for those cases where there isn't an obvious
> solution we can all just line up behind.
>
> In any case, the whole reason we call for list discussion before
> voting is so that people have an opportunity to offer better
> suggestions, and point out issues with the ones that have been
> proposed.  If we didn't care, we'd just shoot from the hip and
> everybody could spend their time discussing how out of touch we are
> instead.  :)
>

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Matt Turner]

On Tue, Apr 7, 2015 at 4:38 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Apr 6, 2015 at 6:22 PM, Matt Turner <mattst88@gentoo.org> wrote:
>> I've wanted for a long time a system that can help reduce the time I
>> have to sit in front of a computer waiting for things to finish
>> compiling before I can test them. Trawl bugzilla, grab package lists,
>> go build binpkgs. Just let me grab binpkgs and actually test the
>> software...
>
> I approve, and I'm sure the rest of the Council will too.  When will
> you have it ready?

I don't think it's some pie-in-the-sky fantasy that you can quip "when
will you have it ready?" about.

Isn't, in fact, this something like what Zorry is working on? He
mentioned in 10 days ago in "[gentoo-dev] Cluster tinderbox poc"

I'm lamenting the fact that ~30 emails in no one has even appeared to
wonder out loud if there's actually a technical solution to the
problem. Instead we're debating the merits of unkeywording whole
subtrees.

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Tue, Apr 7, 2015 at 8:01 PM, Matt Turner <mattst88@gentoo.org> wrote:
> On Tue, Apr 7, 2015 at 4:38 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Mon, Apr 6, 2015 at 6:22 PM, Matt Turner <mattst88@gentoo.org> wrote:
>>> I've wanted for a long time a system that can help reduce the time I
>>> have to sit in front of a computer waiting for things to finish
>>> compiling before I can test them. Trawl bugzilla, grab package lists,
>>> go build binpkgs. Just let me grab binpkgs and actually test the
>>> software...
>>
>> I approve, and I'm sure the rest of the Council will too.  When will
>> you have it ready?
>
> I don't think it's some pie-in-the-sky fantasy that you can quip "when
> will you have it ready?" about.

It doesn't have to be a fantasy to ask when it will be ready.  In
fact, the question is more meaningful if it can actually be done.

Maintainers are suffering with a problem now.  Unless we really think
a solution is about to emerge, it doesn't make sense to delay.  If you
have reason to think a solution is about to emerge, speak up.

>
> Isn't, in fact, this something like what Zorry is working on? He
> mentioned in 10 days ago in "[gentoo-dev] Cluster tinderbox poc"

This might be promising, but right now all it does is build packages.
Presumably you'll want it to build using the right libraries so that
the binpkg will run on stable, and make the binpkg downloadable, some
wrappers, and so on.  If it is using VMs and not emulated machines,
then you need to have multiple instances of this thing for each target
arch.  You'll want some kind of bugzilla tie-in if you want the thing
to have already built the stablereq package when you first go to look
at it, otherwise you're going to have to queue up a build, and if
you're going to do that, why not just build it on your own box?

Don't get me wrong - I think it is a good idea, and tinderboxing is
great for a lot of things.  I just don't know that it is really a
solution to the problem of "I don't want to build stablereq packages
myself" and even if it were it seems like this months away from being
a solution for something like sparc (anybody have a 64-core sparc
sitting around?).

>
> I'm lamenting the fact that ~30 emails in no one has even appeared to
> wonder out loud if there's actually a technical solution to the
> problem. Instead we're debating the merits of unkeywording whole
> subtrees.
>

Tinderboxes are useful for build tests, or for running automated
tests.  When I'm arch testing the build time is usually the least of
my concerns.  I can just open screen and launch emerge -1 pkg in each
of a bunch of windows, then in a bit go and test each one.  It is the
testing that really takes the time.  If you're just going to compile
test then the tinderbox is fine, but then you might as well bypass the
arch team entirely.  The one place where I wouldn't mind having binary
packages handy would be for stuff like chromium or libreoffice, or
maybe for testing a whole gnome release or something.

And if we're going to be building binary packages, we might as well
mirror them and let the users make use of them if they're sticking to
the targeted profile.

It just isn't a trivial problem.  I think it is great that you're
bringing it up, but you don't need to criticize others for not having
proposed it first.

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3108 bytes --]

On Sun, 5 Apr 2015 18:54:10 -0400 Rich Freeman wrote:
> On Sun, Apr 5, 2015 at 5:27 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> >
> > 2. Otherwise allow developers to drop stable keywords from affected
> > package and _all_ its reverse dependencies. This way a part of
> > stable tree will be removed, but only a part. With this approach
> > arch teams will be freed of an extra burden, while they will be
> > still able to maintain a smaller stable tree.
> >
> > This is a win-win solution: a stable tree will be still kept in a
> > maintainable size and developers will not have a long-term blockers
> > on their stabilization requests.
> >
> > 3. And last but not the least: apply the rules above to all arches,
> > not just minor teams (though probability that amd64/x86 will be
> > slow is lower, of course).
> >
> 
> This was some of what I was getting at.  My question still stands that
> I'm not sure arch teams REALLY want 300 packages to have their stable
> keywords removed instead of just having one package break the
> depgraph.

Hmm, that's a hard question. I tried to consider this issues from a
point of view of a user of such arch. If package is not used or
user may delete it and its deps without much harm, it doesn't affect
user at all. If it is used and needed, then in case of:

- one package with removed stable keyword a user have to add to
package.keywords only a single package, though it might be
difficult to locate such package, because portage deptree failure
events may be really obscure sometimes;

- all subtree of stable keywords is removed; then user have to
add all these packages to package.keywords, portage messages should
be clear here (but one never knows), though manual keywording of
hundred of packages will be irritating at best (even using "cat/*"
masks). So if number of affected installed packages is large, users
will likely move to ~arch all their setup.

So from user's perspective stable deptree broken in single point is
a better solution, but(!) if portage will cleanly suggest this
point.

Another issue to consider: what if we have one such package that
broke stable deptree, then after awhile another one and so on. In
the result stable tree will got corrupted beyond repair.

Maybe some grace period will help here? E.g. remove stable keyword
from a single package, wait for 30 days (or so) for reaction from a
team, and then dekeyword all reverse dependencies.

> I would prefer to get at a more generic policy that can be applied
> everywhere, and not just arch by arch.  Being able to keep up or not
> isn't really a black/white thing.  Or rather, if it is I think it is
> more a case that nobody can keep up.  I think that it would be better
> to have one policy that makes sense on any arch, and as you point out
> it probably won't tend to get applied much to amd64/x86 simply because
> they are better supported.

Agreed, the policy should be generic and for everyone (maybe with
reasonable exceptions as toolchan or other core packages).

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3232 bytes --]

Dnia 2015-04-06, o godz. 02:38:41
Andrew Savchenko <bircoph@gentoo.org> napisał(a):

> On Sun, 5 Apr 2015 18:54:10 -0400 Rich Freeman wrote:
> > On Sun, Apr 5, 2015 at 5:27 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> > >
> > > 2. Otherwise allow developers to drop stable keywords from affected
> > > package and _all_ its reverse dependencies. This way a part of
> > > stable tree will be removed, but only a part. With this approach
> > > arch teams will be freed of an extra burden, while they will be
> > > still able to maintain a smaller stable tree.
> > >
> > > This is a win-win solution: a stable tree will be still kept in a
> > > maintainable size and developers will not have a long-term blockers
> > > on their stabilization requests.
> > >
> > > 3. And last but not the least: apply the rules above to all arches,
> > > not just minor teams (though probability that amd64/x86 will be
> > > slow is lower, of course).
> > >
> > 
> > This was some of what I was getting at.  My question still stands that
> > I'm not sure arch teams REALLY want 300 packages to have their stable
> > keywords removed instead of just having one package break the
> > depgraph.
> 
> Hmm, that's a hard question. I tried to consider this issues from a
> point of view of a user of such arch. If package is not used or
> user may delete it and its deps without much harm, it doesn't affect
> user at all. If it is used and needed, then in case of:
> 
> - one package with removed stable keyword a user have to add to
> package.keywords only a single package, though it might be
> difficult to locate such package, because portage deptree failure
> events may be really obscure sometimes;
> 
> - all subtree of stable keywords is removed; then user have to
> add all these packages to package.keywords, portage messages should
> be clear here (but one never knows), though manual keywording of
> hundred of packages will be irritating at best (even using "cat/*"
> masks). So if number of affected installed packages is large, users
> will likely move to ~arch all their setup.
> 
> So from user's perspective stable deptree broken in single point is
> a better solution, but(!) if portage will cleanly suggest this
> point.
> 
> Another issue to consider: what if we have one such package that
> broke stable deptree, then after awhile another one and so on. In
> the result stable tree will got corrupted beyond repair.
> 
> Maybe some grace period will help here? E.g. remove stable keyword
> from a single package, wait for 30 days (or so) for reaction from a
> team, and then dekeyword all reverse dependencies.

Which means developers can't commit properly for 30 days. Really
awesome solution, thank you. Please ping QA instantly once you do it,
you'll save us time figuring who to ban for the breakage.

Let me remind you: once you break dependency tree on *ANY* stable
architecture, repoman won't let you commit. Travis turns red. All pull
requests are marked as broken. Long story short, we end up with a lot
of extra work.

And so far, nobody but me and Patrick basically cared about dependency
graph not being broken.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Mon, Apr 6, 2015 at 3:59 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> And so far, nobody but me and Patrick basically cared about dependency
> graph not being broken.
>

Don't assume discussion of alternatives is equivalent to not caring.
The reasons for not breaking the depgraph were fairly well articulated
- it doesn't really add much to repeat them.

Personally I'm leaning more towards making the entire arches
non-stable, but I'd still prefer to have a policy that can be applied
across all archs, and it doesn't make sense to make all archs
non-stable.

-- 
Rich

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

Dnia 2015-04-06, o godz. 06:29:55
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Mon, Apr 6, 2015 at 3:59 AM, Michał Górny <mgorny@gentoo.org> wrote:
> >
> > And so far, nobody but me and Patrick basically cared about dependency
> > graph not being broken.
> >
> 
> Don't assume discussion of alternatives is equivalent to not caring.
> The reasons for not breaking the depgraph were fairly well articulated
> - it doesn't really add much to repeat them.
> 
> Personally I'm leaning more towards making the entire arches
> non-stable, but I'd still prefer to have a policy that can be applied
> across all archs, and it doesn't make sense to make all archs
> non-stable.

Developing a policy that intentionally makes it impossible to work
on Gentoo...

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

On Mon, 6 Apr 2015 09:59:22 +0200 Michał Górny wrote:
[...]
> > Hmm, that's a hard question. I tried to consider this issues from a
> > point of view of a user of such arch. If package is not used or
> > user may delete it and its deps without much harm, it doesn't affect
> > user at all. If it is used and needed, then in case of:
> > 
> > - one package with removed stable keyword a user have to add to
> > package.keywords only a single package, though it might be
> > difficult to locate such package, because portage deptree failure
> > events may be really obscure sometimes;
> > 
> > - all subtree of stable keywords is removed; then user have to
> > add all these packages to package.keywords, portage messages should
> > be clear here (but one never knows), though manual keywording of
> > hundred of packages will be irritating at best (even using "cat/*"
> > masks). So if number of affected installed packages is large, users
> > will likely move to ~arch all their setup.
> > 
> > So from user's perspective stable deptree broken in single point is
> > a better solution, but(!) if portage will cleanly suggest this
> > point.
> > 
> > Another issue to consider: what if we have one such package that
> > broke stable deptree, then after awhile another one and so on. In
> > the result stable tree will got corrupted beyond repair.
> > 
> > Maybe some grace period will help here? E.g. remove stable keyword
> > from a single package, wait for 30 days (or so) for reaction from a
> > team, and then dekeyword all reverse dependencies.
> 
> Which means developers can't commit properly for 30 days. Really
> awesome solution, thank you. Please ping QA instantly once you do it,
> you'll save us time figuring who to ban for the breakage.

I sad nowhere I'm going to do it. We are discussing opportunities
to fix current sore situation. Threatening people with bans just
for their thoughts reminds me of George Orwell's Thought Police...

> Let me remind you: once you break dependency tree on *ANY* stable
> architecture, repoman won't let you commit. Travis turns red. All pull
> requests are marked as broken.

Repoman, travis and other QA tools can be fixed if policy changes.
That's not a problem. Right now we have an all-green travis, but
outdated, broken and likely insecure packages it tree marked as
stable. That is the problem we're trying to discuss here.

And as I see this problem has no good solution, so one less painful
for users should be chosen. If this will require a QA policy
update, then it should be done.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3442 bytes --]

Dnia 2015-04-07, o godz. 00:37:04
Andrew Savchenko <bircoph@gentoo.org> napisał(a):

> On Mon, 6 Apr 2015 09:59:22 +0200 Michał Górny wrote:
> [...]
> > > Hmm, that's a hard question. I tried to consider this issues from a
> > > point of view of a user of such arch. If package is not used or
> > > user may delete it and its deps without much harm, it doesn't affect
> > > user at all. If it is used and needed, then in case of:
> > > 
> > > - one package with removed stable keyword a user have to add to
> > > package.keywords only a single package, though it might be
> > > difficult to locate such package, because portage deptree failure
> > > events may be really obscure sometimes;
> > > 
> > > - all subtree of stable keywords is removed; then user have to
> > > add all these packages to package.keywords, portage messages should
> > > be clear here (but one never knows), though manual keywording of
> > > hundred of packages will be irritating at best (even using "cat/*"
> > > masks). So if number of affected installed packages is large, users
> > > will likely move to ~arch all their setup.
> > > 
> > > So from user's perspective stable deptree broken in single point is
> > > a better solution, but(!) if portage will cleanly suggest this
> > > point.
> > > 
> > > Another issue to consider: what if we have one such package that
> > > broke stable deptree, then after awhile another one and so on. In
> > > the result stable tree will got corrupted beyond repair.
> > > 
> > > Maybe some grace period will help here? E.g. remove stable keyword
> > > from a single package, wait for 30 days (or so) for reaction from a
> > > team, and then dekeyword all reverse dependencies.
> > 
> > Which means developers can't commit properly for 30 days. Really
> > awesome solution, thank you. Please ping QA instantly once you do it,
> > you'll save us time figuring who to ban for the breakage.
> 
> I sad nowhere I'm going to do it. We are discussing opportunities
> to fix current sore situation. Threatening people with bans just
> for their thoughts reminds me of George Orwell's Thought Police...

You are discussing something that has already been proven impossible
like you're trying to make it possible via introducing more noise.

> > Let me remind you: once you break dependency tree on *ANY* stable
> > architecture, repoman won't let you commit. Travis turns red. All pull
> > requests are marked as broken.
> 
> Repoman, travis and other QA tools can be fixed if policy changes.
> That's not a problem. Right now we have an all-green travis, but
> outdated, broken and likely insecure packages it tree marked as
> stable. That is the problem we're trying to discuss here.

How can they be fixed? By making them ignore dependency breakages? What
is the use of QA tools if you disable the most important QA check just
to push your some really stupid idea through.

> And as I see this problem has no good solution, so one less painful
> for users should be chosen. If this will require a QA policy
> update, then it should be done.

And thanks to this 'less painful' solution people lately had a real
hard time due to app-eselect/ move. Sure, it looks good on a first
glance but then you get into the fine details and everything falls
apart. Of course, some people simply don't care about the fine details
at all.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

Hi,

On Tue, 7 Apr 2015 00:05:50 +0200 Michał Górny wrote:
[...]
> > I sad nowhere I'm going to do it. We are discussing opportunities
> > to fix current sore situation. Threatening people with bans just
> > for their thoughts reminds me of George Orwell's Thought Police...
> 
> You are discussing something that has already been proven impossible
> like you're trying to make it possible via introducing more noise.
> 
> > > Let me remind you: once you break dependency tree on *ANY* stable
> > > architecture, repoman won't let you commit. Travis turns red. All pull
> > > requests are marked as broken.
> > 
> > Repoman, travis and other QA tools can be fixed if policy changes.
> > That's not a problem. Right now we have an all-green travis, but
> > outdated, broken and likely insecure packages it tree marked as
> > stable. That is the problem we're trying to discuss here.
> 
> How can they be fixed? By making them ignore dependency breakages? What
> is the use of QA tools if you disable the most important QA check just
> to push your some really stupid idea through.
> 
> > And as I see this problem has no good solution, so one less painful
> > for users should be chosen. If this will require a QA policy
> > update, then it should be done.
> 
> And thanks to this 'less painful' solution people lately had a real
> hard time due to app-eselect/ move. Sure, it looks good on a first
> glance but then you get into the fine details and everything falls
> apart. Of course, some people simply don't care about the fine details
> at all.

I'm not claiming that my proposal is perfect or even good enough;
please propose something better, but consider all side-effects
carefully: you'll see that broken stable deptree is not a worse
possible scenario. My main point is that things should not be left
as they are right now.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]

On Tue, Apr 07, 2015 at 12:37:04AM +0300, Andrew Savchenko wrote:
> On Mon, 6 Apr 2015 09:59:22 +0200 Michał Górny wrote:
> [...]
> > > Hmm, that's a hard question. I tried to consider this issues from a
> > > point of view of a user of such arch. If package is not used or
> > > user may delete it and its deps without much harm, it doesn't affect
> > > user at all. If it is used and needed, then in case of:
> > > 
> > > - one package with removed stable keyword a user have to add to
> > > package.keywords only a single package, though it might be
> > > difficult to locate such package, because portage deptree failure
> > > events may be really obscure sometimes;
> > > 
> > > - all subtree of stable keywords is removed; then user have to
> > > add all these packages to package.keywords, portage messages should
> > > be clear here (but one never knows), though manual keywording of
> > > hundred of packages will be irritating at best (even using "cat/*"
> > > masks). So if number of affected installed packages is large, users
> > > will likely move to ~arch all their setup.
> > > 
> > > So from user's perspective stable deptree broken in single point is
> > > a better solution, but(!) if portage will cleanly suggest this
> > > point.

I believe it does. If you try to emerge something that is ~ or has ~ on
one of its deps portage will tell you what you need to unmask to make
the emerge possible.

> > > 
> > > Another issue to consider: what if we have one such package that
> > > broke stable deptree, then after awhile another one and so on. In
> > > the result stable tree will got corrupted beyond repair.

At that point, I would say it is time to consider dropping the affected
arch to dev or exp.

> > > Maybe some grace period will help here? E.g. remove stable keyword
> > > from a single package, wait for 30 days (or so) for reaction from a
> > > team, and then dekeyword all reverse dependencies.

Dekeywording all reverse dependencies makes me nervous. There could be
other packages that share those reverse dependencies, so I don't think
you want to do that unless you know that no stable package on the arches
in question shares the reverse dependencies. I would rather remove the
older version of the package once the stable req has had arch teams
assigned for 90 days and there has been no update to it or stabilization
of the newer version.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Mon, Apr 6, 2015 at 5:37 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> I sad nowhere I'm going to do it. We are discussing opportunities
> to fix current sore situation. Threatening people with bans just
> for their thoughts reminds me of George Orwell's Thought Police...
>

++

Seriously - we have a lot of lousy alternatives right now and if you
want to find better ones, you can't punish people for offering
suggestions, whether they turn out to be the best options or not.

Besides, which would you rather have?  People talking about their
ideas on a list, or people feeling afraid to bring them up so they
just quietly do them in the tree instead?

-- 
Rich

Re: [gentoo-project] Council meeting 2015-04-14: call for agenda items

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

Dnia 2015-04-02, o godz. 10:14:28
Tim Harder <radhermit@gentoo.org> napisał(a):

> The next council meeting will be on April 14th, 19:00 UTC in
> #gentoo-council on Freenode.
> 
> Please respond to this message on the gentoo-project list with any
> agenda items you want to propose or discuss.

I would like to ask the Council to confirm or reject the switch of
libav/ffmpeg default to ffmpeg. I don't want to take a stand there but
I'm concerned that our users will end up suffering a ping-pong of
developers fighting and changing the defaults from time to time.

[1]:https://archives.gentoo.org/gentoo-dev/message/50c181372e098719b2573e7b16c74482

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Council meeting 2015-04-14: call for agenda items

[Ben de Groot]

On 6 April 2015 at 17:28, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2015-04-02, o godz. 10:14:28
> Tim Harder <radhermit@gentoo.org> napisał(a):
>
>> The next council meeting will be on April 14th, 19:00 UTC in
>> #gentoo-council on Freenode.
>>
>> Please respond to this message on the gentoo-project list with any
>> agenda items you want to propose or discuss.
>
> I would like to ask the Council to confirm or reject the switch of
> libav/ffmpeg default to ffmpeg. I don't want to take a stand there but
> I'm concerned that our users will end up suffering a ping-pong of
> developers fighting and changing the defaults from time to time.
>
> [1]:https://archives.gentoo.org/gentoo-dev/message/50c181372e098719b2573e7b16c74482

My reasons for the switch are summarized here:
https://archives.gentoo.org/gentoo-dev/message/215e894205c6ca4a6e4e76291872ce95

If anything more is wanted, please let me know, and I'd be happy to expand.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-project] Council meeting 2015-04-14: call for agenda items

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

>>>>> On Sat, 11 Apr 2015, Ben de Groot wrote:

> On 6 April 2015 at 17:28, Michał Górny <mgorny@gentoo.org> wrote:
>> Dnia 2015-04-02, o godz. 10:14:28
>> I would like to ask the Council to confirm or reject the switch of
>> libav/ffmpeg default to ffmpeg. I don't want to take a stand there
>> but I'm concerned that our users will end up suffering a ping-pong
>> of developers fighting and changing the defaults from time to time.
>> 
>> [1]:https://archives.gentoo.org/gentoo-dev/message/50c181372e098719b2573e7b16c74482

> My reasons for the switch are summarized here:
> https://archives.gentoo.org/gentoo-dev/message/215e894205c6ca4a6e4e76291872ce95

> If anything more is wanted, please let me know, and I'd be happy to
> expand.

This is nothing more than a change of a flag's default. Users can
trivially override it with their own setting.

IMHO the council shouldn't get involved in such micromanagement.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Council meeting 2015-04-14: call for agenda items

[Rich Freeman]

On Sat, Apr 11, 2015 at 5:04 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Sat, 11 Apr 2015, Ben de Groot wrote:
>
>> On 6 April 2015 at 17:28, Michał Górny <mgorny@gentoo.org> wrote:
>>> Dnia 2015-04-02, o godz. 10:14:28
>>> I would like to ask the Council to confirm or reject the switch of
>>> libav/ffmpeg default to ffmpeg. I don't want to take a stand there
>>> but I'm concerned that our users will end up suffering a ping-pong
>>> of developers fighting and changing the defaults from time to time.
>>>
>>> [1]:https://archives.gentoo.org/gentoo-dev/message/50c181372e098719b2573e7b16c74482
>
>> My reasons for the switch are summarized here:
>> https://archives.gentoo.org/gentoo-dev/message/215e894205c6ca4a6e4e76291872ce95
>
>> If anything more is wanted, please let me know, and I'd be happy to
>> expand.
>
> This is nothing more than a change of a flag's default. Users can
> trivially override it with their own setting.
>
> IMHO the council shouldn't get involved in such micromanagement.

Well, ping-pong of any kind in the tree isn't a great thing.  However,
I don't anticipate that here.  It is fine to change a default in the
tree - I think we really only need the Council if we have two sets of
devs/projects/whatevers that are actively pushing for one vs another
and commit wars are a possibility.

If all the maintainers are fine with ffmpeg, just do it.  If ping-pong
becomes an actual issue I'm fine with it going to the Council.

But, in general anybody can ask the Council anything.  We can still
bring up the topic, though I suspect most of us will say "we're fine
with it, but don't feel like you have to ask us."  We'll see.

-- 
Rich