[gentoo-project] Call for agenda items - Council meeting 2014-02-25

[gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 943 bytes --]

Due to FOSDEM-induced travel chaos, we decided to postpone the monthly council 
meeting by two weeks. As a consequence, ...

In two weeks, the council will have its (well, this time only nearly regular) 
monthly meeting. Now is the time to raise and prepare items that the council 
should put on the agenda to discuss or vote on.

Please respond to this message with agenda items. Do not hesitate to repeat 
your agenda item here with a pointer if you previously suggested one (since 
the last meeting).

We will send out the agenda one week before the meeting date, i.e. 2014-02-18.

Your responses should go to the gentoo-project list.

Best, 
Andreas

-- 
Dr. Andreas K. Huettel
Institute for Experimental and Applied Physics
University of Regensburg
D-93040 Regensburg
Germany

tel. +49 151 241 67748 (mobile)
e-mail andreas.huettel@ur.de
http://www.akhuettel.de/
http://www.physik.uni-r.de/forschung/huettel/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Ulrich Mueller]

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

>>>>> On Mon, 10 Feb 2014, Andreas K Huettel wrote:

> In two weeks, the council will have its (well, this time only nearly
> regular) monthly meeting. Now is the time to raise and prepare items
> that the council should put on the agenda to discuss or vote on.

> Please respond to this message with agenda items. Do not hesitate to
> repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).

Can we discuss/vote about EAPI deprecation please? Looking at the
summary of our 2013-04-09 meeting, we could take the following three
votes:

- "EAPI 3 is no longer required for the upgrade path of users' systems."
- "EAPI 3 is discouraged. Repoman should warn about this."
- "EAPI 0 is discouraged. Repoman should warn about this."

Portage 2.1.9.42 (supporting EAPI 4) went stable on the last
architecture on 2011-03-17 which was almost three years ago.

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 805 bytes --]

Am Montag, 10. Februar 2014, 16:39:17 schrieb Ulrich Mueller:
> 
> Can we discuss/vote about EAPI deprecation please? Looking at the
> summary of our 2013-04-09 meeting, we could take the following three
> votes:
> 
> - "EAPI 3 is no longer required for the upgrade path of users' systems."
> - "EAPI 3 is discouraged. Repoman should warn about this."
> - "EAPI 0 is discouraged. Repoman should warn about this."
> 

Let's add two more votes, following inspiration by Patrick:

- "EAPI 1 is long deprecated and now banned. Repoman should refuse committing 
an EAPI 1 ebuild."
- "EAPI 2 is long deprecated and now banned. Repoman should refuse committing 
an EAPI 2 ebuild."

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Ruud Koolen]

On Monday 10 February 2014 17:00:11 Andreas K. Huettel wrote:
> Let's add two more votes, following inspiration by Patrick:
>
> - "EAPI 1 is long deprecated and now banned. Repoman should refuse
> committing an EAPI 1 ebuild."
> - "EAPI 2 is long deprecated and now banned. Repoman should refuse
> committing an EAPI 2 ebuild."

For clarification, does this cover only new ebuilds, or bugfix commits to 
existing EAPI [12] builds as well? I can see banning the latter to be 
problematic.

-- Ruud

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Tom Wijsman]

On Mon, 10 Feb 2014 17:22:05 +0100
Ruud Koolen <redlizard@gentoo.org> wrote:

> On Monday 10 February 2014 17:00:11 Andreas K. Huettel wrote:
> > Let's add two more votes, following inspiration by Patrick:
> >
> > - "EAPI 1 is long deprecated and now banned. Repoman should refuse
> > committing an EAPI 1 ebuild."
> > - "EAPI 2 is long deprecated and now banned. Repoman should refuse
> > committing an EAPI 2 ebuild."
> 
> For clarification, does this cover only new ebuilds, or bugfix
> commits to existing EAPI [12] builds as well? I can see banning the
> latter to be problematic.

Indeed, as pointed out in the other thread on -dev; there are multiple
possibilities here:

    1. an edit to an existing ebuild;

    2. a revision bump;

    3. a version bump.

Definitely would want to ban (3), I think banning (2) might be possible
too if we expect developers to bump EAPI as they revision bump (and
perhaps give the exception for critical security fixes to not have to
bump the EAPI), banning (1) gets a bit more tricky.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Ciaran McCreesh]

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

On Mon, 10 Feb 2014 19:03:21 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:
> Indeed, as pointed out in the other thread on -dev; there are multiple
> possibilities here:
> 
>     1. an edit to an existing ebuild;
> 
>     2. a revision bump;
> 
>     3. a version bump.
> 
> Definitely would want to ban (3), I think banning (2) might be
> possible too if we expect developers to bump EAPI as they revision
> bump (and perhaps give the exception for critical security fixes to
> not have to bump the EAPI), banning (1) gets a bit more tricky.

Bumping to EAPI 5 should always involve a revbump, to avoid a messy
situation with use dependency defaults.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Ulrich Mueller]

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

>>>>> On Mon, 10 Feb 2014, Tom Wijsman wrote:

> Indeed, as pointed out in the other thread on -dev; there are
> multiple possibilities here:

>     1. an edit to an existing ebuild;

>     2. a revision bump;

>     3. a version bump.

> Definitely would want to ban (3), I think banning (2) might be
> possible too if we expect developers to bump EAPI as they revision
> bump (and perhaps give the exception for critical security fixes to
> not have to bump the EAPI), banning (1) gets a bit more tricky.

Banning (1) is not a good idea, because it would get in the way of
simple tasks like updating KEYWORDS, LICENSE, or *DEPEND.

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As discussed on gentoo-dev ML and recently with the QA team, we have
no clear rule/policy about 'gtk' USE flags. Currently there are all
kinds of them: gtk, gtk2, gtk3. That looks inconsistent to me.

The council should decide whether to allow:
* gtk only
* gtk2, gtk3, ..., but without 'gtk'

mixing these two concepts is confusing from a usability POV.
I have no strong opinion on what to do. But we should not do both.

links:
http://www.gossamer-threads.com/lists/gentoo/dev/255125
http://us.generation-nt.com/answer/gentoo-dev-gtk2-gtk3-use-flags-help-212168702.html
https://bugs.gentoo.org/show_bug.cgi?id=420493
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS+SNjAAoJEFpvPKfnPDWzSWIIAKMV/9olwc4EKkag+QyByT/4
SHx08y4Ul/3DeZtxNykvFQ2ZgItlnxRZJaTkrbM0ZMs2/8u20ZtW3rV1S3B0Nte1
HDZicsmE33X+iRHObErBp+MJvbqBRJvQynEtPSzAWb5lWdN5fjp4v6DZKUPplXYn
id8VSqDxK5y0v33uY0R+GWsOyUyIulp7FWDI2aKKOIaa24fOGIqQf7Npob7D8Q9w
FDwabtmbiUHL4rF2Qvy3KlvHUhv8ChDVZHBEYov+4mnJl0y+E6gwGvQICz3woYgk
hJRgzRO3FdIQqWkgRYrA67F95iaEKjaEeIrPh8IWgNq26kjBpJ1GK6BaR7F89S0=
=Vlmi
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/10/2014 02:07 PM, hasufell wrote:
> As discussed on gentoo-dev ML and recently with the QA team, we have
> no clear rule/policy about 'gtk' USE flags. Currently there are all
> kinds of them: gtk, gtk2, gtk3. That looks inconsistent to me.
> 
> The council should decide whether to allow:
> * gtk only
> * gtk2, gtk3, ..., but without 'gtk'
> 
> mixing these two concepts is confusing from a usability POV.
> I have no strong opinion on what to do. But we should not do both.

QA is opening a discussion with the gnome team on this matter.  I
believe we can work together for the common good and come up with a
policy without concerning the council.  When I'm wrong, we can ask the
council for guidance.

Thanks,
Zero
> 
> links:
> http://www.gossamer-threads.com/lists/gentoo/dev/255125
> http://us.generation-nt.com/answer/gentoo-dev-gtk2-gtk3-use-flags-help-212168702.html
> https://bugs.gentoo.org/show_bug.cgi?id=420493
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS+Y1zAAoJEKXdFCfdEflKwyAP/iVkpaaV7IXRMtaWF8XDtw4S
1+RCiK6I3pl4XTVT2ndWqQBWQkrMYdflXDvkV20gfr0/vnZFSvvk/AGzg0LWxeTs
L8TkNmu964p0Du4o2UI58qG5LJao4EeIiHIHd8MYMkYYTdm42BZmiXj3yLgT3Fw7
ulldqOd71ShWq6jLKHRJ1X/+b2OHYMqF9mk+cfzqUupOptPWd5LgnJVUp+Ez1IKp
Dg7i/mCHFh5YeXhmHFwoEI/Xlp3cJVnG6U2LRssiPOCGn/a2vj027FzLTM8N3FHm
1HYOF696fMgsQeCsy651KYhzfLUxWyMBS9nH104yRNr7THLdNX5ay9w8r8DRFcX/
mxTBgrAk3FFyoWPkumlxZMZtMdh6O38HWC3lR6z6rVGCta9D0FtWcBYjWW/vn1m9
V80wHskJRnQZYgJJSMJNzu3kbrtCAR0yKTGkruqslOlBwStjJvKzOxc4/wS6DM6V
rjS8FYiPJ4XWoF3vqwgEOJ9G14gMnQnL+ecJVb4MwBjTidx7lw94031SZccwVgjr
UvyAI1nAecmslZIeHP+fg2LtQa6Bc0QAYP93Mg+p9POSbJ3Z+Sv2LNtTFXKdd6bc
AjWg929a7Syud+QazcUhtiLsUxc3aDOqDjrQUAdPG2Xii2Nkn5wCiScHOI+47ipE
jRn70PeBgDw+D0voG/qA
=4/ZC
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1369 bytes --]


Stable keywords on "~arch only" architectures in ebuilds.

Possible options include 
* drop 'em all
* require a "dropping by tree aging"
* allow for arch-team purposes limited stable marking, but package maintainers 
neednt care

In any case the policy should be documented more in detail (devmanual?), since 
the current state is not just a bit messy.

See also 
https://bugs.gentoo.org/show_bug.cgi?id=498332
http://thread.gmane.org/gmane.linux.gentoo.devel/89844

Am Montag, 10. Februar 2014, 15:45:35 schrieb Andreas K. Huettel:
> Due to FOSDEM-induced travel chaos, we decided to postpone the monthly
> council meeting by two weeks. As a consequence, ...
> 
> In two weeks, the council will have its (well, this time only nearly
> regular) monthly meeting. Now is the time to raise and prepare items that
> the council should put on the agenda to discuss or vote on.
> 
> Please respond to this message with agenda items. Do not hesitate to repeat
> your agenda item here with a pointer if you previously suggested one (since
> the last meeting).
> 
> We will send out the agenda one week before the meeting date, i.e.
> 2014-02-18.
> 
> Your responses should go to the gentoo-project list.
> 
> Best,
> Andreas


-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/11/2014 03:39 AM, Rick "Zero_Chaos" Farina wrote:
> On 02/10/2014 02:07 PM, hasufell wrote:
>> As discussed on gentoo-dev ML and recently with the QA team, we
>> have no clear rule/policy about 'gtk' USE flags. Currently there
>> are all kinds of them: gtk, gtk2, gtk3. That looks inconsistent
>> to me.
> 
>> The council should decide whether to allow: * gtk only * gtk2,
>> gtk3, ..., but without 'gtk'
> 
>> mixing these two concepts is confusing from a usability POV. I
>> have no strong opinion on what to do. But we should not do both.
> 
> QA is opening a discussion with the gnome team on this matter.  I 
> believe we can work together for the common good and come up with
> a policy without concerning the council.  When I'm wrong, we can
> ask the council for guidance.
> 
> Thanks, Zero
> 
>> links: http://www.gossamer-threads.com/lists/gentoo/dev/255125 
>> http://us.generation-nt.com/answer/gentoo-dev-gtk2-gtk3-use-flags-help-212168702.html
>>
>> 
https://bugs.gentoo.org/show_bug.cgi?id=420493
> 
> 
> 
> 

Afais the QA team has not set a QA policy anywhere about this. I want
the inconsistency to be banned (in any way) or ultimately allowed, so
I expect this to be on the agenda.

A "recommendation" is not enough IMO, so this is a matter for the
council to decide on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS+rAoAAoJEFpvPKfnPDWzJFcH/0FQePgcdzgFbGSi48QQgrQD
b9RjBV8bjQXeaiA6bg5FqlB8TXyHNXaAj59kVKIlBtUwpZ3pSNjFWoo/PJtv/5Mq
cZWTkt0VB+7WY/dG2YyCzmaNTu71OE97IJsaVRuCjNrbmyn+7esvN43yke2m/biY
GgaxowcQajLToXbGQ+NI1fTLaghQaMOmgtL7nbtb0BNybBaoLjMui49kmMnuD/qI
ofBaoNcKbcxaYOoptkUAapHxaBJbh+og5/LEMsoOUmbumhrip/i+6Rig8HPP0dHw
TNMadR8++ovTeejOss8tFoSzaajASEK5mAnoYnb1n0hkCdEfabGHDv9xsG0rFgA=
=DwOn
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[William Hubbs]

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

On Tue, Feb 11, 2014 at 08:46:33PM +0100, Andreas K. Huettel wrote:
> 
> Stable keywords on "~arch only" architectures in ebuilds.
> 
> Possible options include 
> * drop 'em all
> * require a "dropping by tree aging"
> * allow for arch-team purposes limited stable marking, but package maintainers 
> neednt care

How about moving the status of ~arch only profiles to exp in
profiles.desc as vapier suggested, or is that covered in your last
option?

William


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

Re: Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Andreas K. Huettel]

> On Tue, Feb 11, 2014 at 08:46:33PM +0100, Andreas K. Huettel wrote:
> > Stable keywords on "~arch only" architectures in ebuilds.
> > 
> > Possible options include
> > * drop 'em all
> > * require a "dropping by tree aging"
> > * allow for arch-team purposes limited stable marking, but package
> > maintainers neednt care
> 
> How about moving the status of ~arch only profiles to exp in
> profiles.desc as vapier suggested, or is that covered in your last
> option?

Can do that, sure... I didnt really intend to exhaustively describe everything 
when writing this mail, that's why I linked to bug and ml thread.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Ulrich Mueller]

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

>>>>> On Mon, 10 Feb 2014, hasufell  wrote:

> As discussed on gentoo-dev ML and recently with the QA team, we have
> no clear rule/policy about 'gtk' USE flags. Currently there are all
> kinds of them: gtk, gtk2, gtk3. That looks inconsistent to me.

> The council should decide whether to allow:
> * gtk only
> * gtk2, gtk3, ..., but without 'gtk'

> mixing these two concepts is confusing from a usability POV. I have
> no strong opinion on what to do. But we should not do both.

I support adding this point to the agenda. The discussion in
gentoo-dev following yesterdays QA decision shows that the issue is
controversial, and guidance from the Council is needed.

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[hasufell]

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

Ulrich Mueller:
>>>>>> On Mon, 10 Feb 2014, hasufell  wrote:
> 
>> As discussed on gentoo-dev ML and recently with the QA team, we
>> have no clear rule/policy about 'gtk' USE flags. Currently there
>> are all kinds of them: gtk, gtk2, gtk3. That looks inconsistent
>> to me.
> 
>> The council should decide whether to allow: * gtk only * gtk2,
>> gtk3, ..., but without 'gtk'
> 
>> mixing these two concepts is confusing from a usability POV. I
>> have no strong opinion on what to do. But we should not do both.
> 
> I support adding this point to the agenda. The discussion in 
> gentoo-dev following yesterdays QA decision shows that the issue
> is controversial, and guidance from the Council is needed.
> 
> Ulrich
> 

My list of possible decisions is not complete (e.g. is missing the one
QA is advising), but I guess the situation is more or less clear
enough to reach one.
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJTBiM9AAoJEFpvPKfnPDWzTcoH/0I1dxEGZD4hqZH1s5/b8QSX
AvBzPWk4toq3BmhmHgutmQ6caJKsj7BzkOfpWGYG4zfNdhc8GfFUnnMj+9zHzbij
I5EtR8r2zy+siR80QX/Ph/eu6xREAeYhOS/ebzZTNuWjY1McIgKMcyEb9CW0uDk3
L9OBdmE7glSLUt+P6vwkuN5/KO/aWwizIs1Jq4yHz5VFFgGswzK4NOJTjGDYtHDz
9ZKZzcbI4J0YSkD4qwRtYRtD7yHmzuFeC1XrbLO8jNFZ2DSiIJ7XiBqlZhGIS/z/
tuBkaY/06+73yt0RICotJcf4QtLbciwNRnX9nkzoTYLCtqa9PXxQQpkYtZvqGN0=
=q6xv
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Chí-Thanh Christopher Nguyễn]

Andreas K. Huettel schrieb:

> Please respond to this message with agenda items. Do not hesitate to
> repeat your agenda item here with a pointer if you previously suggested
> one (since the last meeting).
> 
> We will send out the agenda one week before the meeting date, i.e.
> 2014-02-18.

If that is still possible, I would like to add one more item related to the
gtk/gtk2/gtk3 USE flags to the agenda. Namely, whether Council gives QA the
powers to enact such a rule.

In my opinion, it is not necessary for QA to have such powers (and
therefore better if they don't have it). QA can already act per GLEP 48 if
there is an immediate serious problem for users. And when there is not an
immediate serious problem, any such rule can be proposed by QA to council
for decision, especially if the topic is as controversial as the gtk USE
flag issue.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Donnie Berkholz]

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

On 12:41 Thu 13 Feb     , Andreas K. Huettel wrote:
> > On Tue, Feb 11, 2014 at 08:46:33PM +0100, Andreas K. Huettel wrote:
> > > Stable keywords on "~arch only" architectures in ebuilds.
> > > 
> > > Possible options include
> > > * drop 'em all
> > > * require a "dropping by tree aging"
> > > * allow for arch-team purposes limited stable marking, but package
> > > maintainers neednt care
> > 
> > How about moving the status of ~arch only profiles to exp in
> > profiles.desc as vapier suggested, or is that covered in your last
> > option?
> 
> Can do that, sure... I didnt really intend to exhaustively describe everything 
> when writing this mail, that's why I linked to bug and ml thread.

Yeah, this idea of dropping keywords wholesale totally screws with new 
or revived ports. I much prefer repoman ignoring stable on a given arch 
by marking it exp (during active porting) or dev (when the port is 
thought to basically work) as Mike described in 
<https://bugs.gentoo.org/show_bug.cgi?id=498332#c5> / 
<https://bugs.gentoo.org/show_bug.cgi?id=498332#c11>.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Donnie Berkholz]

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

On 01:14 Fri 21 Feb     , Chí-Thanh Christopher Nguyễn wrote:
> Andreas K. Huettel schrieb:
> 
> > Please respond to this message with agenda items. Do not hesitate to
> > repeat your agenda item here with a pointer if you previously suggested
> > one (since the last meeting).
> > 
> > We will send out the agenda one week before the meeting date, i.e.
> > 2014-02-18.
> 
> If that is still possible, I would like to add one more item related to the
> gtk/gtk2/gtk3 USE flags to the agenda. Namely, whether Council gives QA the
> powers to enact such a rule.
> 
> In my opinion, it is not necessary for QA to have such powers (and
> therefore better if they don't have it). QA can already act per GLEP 48 if
> there is an immediate serious problem for users. And when there is not an
> immediate serious problem, any such rule can be proposed by QA to council
> for decision, especially if the topic is as controversial as the gtk USE
> flag issue.

Funny how every time a controversial decision gets made, somebody 
inevitably tries to undermine the authority of the group making the 
decision.

In my understanding, the issue you want to address is whether the QA 
team has authority over tree policy.

Will add to the agenda.

I happen to disagree. GLEP 48's point about maintaining "QA Standards" 
applies to this.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Rich Freeman]

On Thu, Feb 20, 2014 at 10:47 PM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> Funny how every time a controversial decision gets made, somebody
> inevitably tries to undermine the authority of the group making the
> decision.
>

As long as we're still adding agenda items, can we get one to depose
the meeting chair?  :)

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Donnie Berkholz]

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

On 23:03 Thu 20 Feb     , Rich Freeman wrote:
> On Thu, Feb 20, 2014 at 10:47 PM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > Funny how every time a controversial decision gets made, somebody
> > inevitably tries to undermine the authority of the group making the
> > decision.
> >
> 
> As long as we're still adding agenda items, can we get one to depose
> the meeting chair?  :)

Should work out well, as there's a new one next month. =)

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Michał Górny]

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

Dnia 2014-02-20, o godz. 21:47:46
Donnie Berkholz <dberkholz@gentoo.org> napisał(a):

> On 01:14 Fri 21 Feb     , Chí-Thanh Christopher Nguyễn wrote:
> > Andreas K. Huettel schrieb:
> > 
> > > Please respond to this message with agenda items. Do not hesitate to
> > > repeat your agenda item here with a pointer if you previously suggested
> > > one (since the last meeting).
> > > 
> > > We will send out the agenda one week before the meeting date, i.e.
> > > 2014-02-18.
> > 
> > If that is still possible, I would like to add one more item related to the
> > gtk/gtk2/gtk3 USE flags to the agenda. Namely, whether Council gives QA the
> > powers to enact such a rule.
> > 
> > In my opinion, it is not necessary for QA to have such powers (and
> > therefore better if they don't have it). QA can already act per GLEP 48 if
> > there is an immediate serious problem for users. And when there is not an
> > immediate serious problem, any such rule can be proposed by QA to council
> > for decision, especially if the topic is as controversial as the gtk USE
> > flag issue.
> 
> Funny how every time a controversial decision gets made, somebody 
> inevitably tries to undermine the authority of the group making the 
> decision.

Well, I think one issue here is that QA undermined the authority of
GTK+ maintainer here, and applied another policy behind their backs. So
we have two conflicting policies now, one from people who maintain GTK+
and a lot of packages using it, and the other from a team of people who
just had a meeting and decided otherwise.

> In my understanding, the issue you want to address is whether the QA 
> team has authority over tree policy.

Even more general, whether QA is supposed to ignore people and just
tell them what to do instead of trying to reach an agreement over
having a single policy.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Tom Wijsman]

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

On Fri, 21 Feb 2014 09:38:41 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2014-02-20, o godz. 21:47:46
> Donnie Berkholz <dberkholz@gentoo.org> napisał(a):
> 
> > On 01:14 Fri 21 Feb     , Chí-Thanh Christopher Nguyễn wrote:
> > > Andreas K. Huettel schrieb:
> > > 
> > > > Please respond to this message with agenda items. Do not
> > > > hesitate to repeat your agenda item here with a pointer if you
> > > > previously suggested one (since the last meeting).
> > > > 
> > > > We will send out the agenda one week before the meeting date,
> > > > i.e. 2014-02-18.
> > > 
> > > If that is still possible, I would like to add one more item
> > > related to the gtk/gtk2/gtk3 USE flags to the agenda. Namely,
> > > whether Council gives QA the powers to enact such a rule.
> > > 
> > > In my opinion, it is not necessary for QA to have such powers (and
> > > therefore better if they don't have it). QA can already act per
> > > GLEP 48 if there is an immediate serious problem for users. And
> > > when there is not an immediate serious problem, any such rule can
> > > be proposed by QA to council for decision, especially if the
> > > topic is as controversial as the gtk USE flag issue.
> > 
> > Funny how every time a controversial decision gets made, somebody 
> > inevitably tries to undermine the authority of the group making the 
> > decision.
> 
> Well, I think one issue here is that QA undermined the authority of
> GTK+ maintainer here,

The USE flag is meant for tree wide usage, it is thus more of a question
of responsibility. If other maintainers as well as users have an
inconsistent and therefore confusing usage of the USE flag, then the
GTK+ maintainer can under that authority be expected to address that; as
to stop several reincarnations, a tracking bug they're not CC-ed on,
the QA team as well as Council getting pinged about this, ...

Note that I do not mean to blame them in specific, as there appears no
document stating who owns USE flags, and that owner can very well be
Gentoo itself; the above paragraph just assumes the authority over the
USE flag as you have put it forward, but it could just as well be seen
as that such authority by the GTK+ maintainers is non-existing.

If the meaning of the USE flags affects other maintainers more, as well
as our users; I'd think the authority should be with Gentoo as a whole.

Otherwise it is questionable as to why the community is discussing these
GTK+ USE flags in the first place. Does the community have an influence?

> and applied another policy behind their backs.

QA meetings are public and can be attended by those interested;
the policy idea was brought to this gentoo-dev ML by wired, thus
everyone has the opportunity to give feedback on the policy forming.

> So we have two conflicting policies now, one from people who maintain
> GTK+ and a lot of packages using it, and the other from a team of
> people who just had a meeting and decided otherwise.

GLEP 48 resolves this conflict.

> > In my understanding, the issue you want to address is whether the
> > QA team has authority over tree policy.
> 
> Even more general, whether QA is supposed to ignore people

We've read a lot about it.

> and just tell them what to do instead of trying to reach an agreement
> over having a single policy.

After several years, an agreement with all parties involved has shown
to be unreachable. The time has come to decide as a distribution in
the upcoming council meeting; with the users, consistent usage,
acceptable maintenance, migration history and future goals in mind.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Anthony G. Basile]

On 02/20/2014 11:04 PM, Donnie Berkholz wrote:
> On 23:03 Thu 20 Feb     , Rich Freeman wrote:
>> On Thu, Feb 20, 2014 at 10:47 PM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
>>> Funny how every time a controversial decision gets made, somebody
>>> inevitably tries to undermine the authority of the group making the
>>> decision.
>>>
>> As long as we're still adding agenda items, can we get one to depose
>> the meeting chair?  :)
> Should work out well, as there's a new one next month. =)
>
Yes and as soon as this meeting is over, I'm going to call for agenda 
items to try to get us back on track.

-- 
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] Call for agenda items - Council meeting 2014-02-25

[Chí-Thanh Christopher Nguyễn]

Donnie Berkholz schrieb:
> Funny how every time a controversial decision gets made, somebody
> inevitably tries to undermine the authority of the group making the
>  decision.
>
> In my understanding, the issue you want to address is whether the
> QA team has authority over tree policy.
>
> Will add to the agenda.

Thanks, I would like to phrase the question a little more precisely:

I would like to ask council to state whether the QA team has the
authority to mandate a policy when there is neither general agreement
that this policy is a good thing, nor the policy would avert any kind
of immediate serious problem for users.

> I happen to disagree. GLEP 48's point about maintaining "QA
> Standards" applies to this.

"QA Standards" are not really defined in GLEP 48 either. Maybe council
could also clarify whether "QA Standard" is just another name for
"tree policy".


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Tom Wijsman]

On Mon, 24 Feb 2014 17:46:22 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Donnie Berkholz schrieb:
> > Funny how every time a controversial decision gets made, somebody
> > inevitably tries to undermine the authority of the group making the
> >  decision.
> >
> > In my understanding, the issue you want to address is whether the
> > QA team has authority over tree policy.
> >
> > Will add to the agenda.
> 
> Thanks, I would like to phrase the question a little more precisely:
> 
> I would like to ask council to state whether the QA team has the
> authority to mandate a policy when there is neither general agreement
> that this policy is a good thing, nor the policy would avert any kind
> of immediate serious problem for users.

That can be reduced to the question whether QA is considered serious.

(There is a majority that agrees as well as a serious problem to users
in the GTK+ USE flag situation; the former can be deduced from the
mailing list, the latter can be realized when controlling the USE flag
among a lot of GTK+ packages. It is something that can be done later; on
the other hand, if we categorize everything that way it halts progress)

> > I happen to disagree. GLEP 48's point about maintaining "QA
> > Standards" applies to this.
> 
> "QA Standards" are not really defined in GLEP 48 either. Maybe council
> could also clarify whether "QA Standard" is just another name for
> "tree policy".

The GLEP states that we can

 1) maintain a list of current "QA Standards";

 2) ensure all developer tools are in line with the current QA
 standards;

 3) and apply it as per "In the event that a developer still insists
 that a package does not break QA standards, an appeal can be made at
 the next council meeting. The package should be dealt with per QA's
 request until such a time that a decision is made by the council."

which effectively makes the "QA Standards" act as policy.

As "QA Standards" under this interpretation are needed to raise
quality; the council should clarify whether we are able to raise the
quality level, or rather are restricted to what exists and expect the
council to raise the quality instead (by having the council do that).

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Chí-Thanh Christopher Nguyễn]

Tom Wijsman schrieb:
>> Thanks, I would like to phrase the question a little more precisely:
>>
>> I would like to ask council to state whether the QA team has the
>> authority to mandate a policy when there is neither general agreement
>> that this policy is a good thing, nor the policy would avert any kind
>> of immediate serious problem for users.
> That can be reduced to the question whether QA is considered serious.

I don't think so. If the council answers this question in the negative,
QA still has its emergency powers and can enforce the policy set by the
council.
QA can also propose any new policy they consider useful to the council,
which can then hear the opposing sides and make a decision based on that.

> (There is a majority that agrees as well as a serious problem to users
> in the GTK+ USE flag situation; the former can be deduced from the
> mailing list, the latter can be realized when controlling the USE flag
> among a lot of GTK+ packages. It is something that can be done later; on
> the other hand, if we categorize everything that way it halts progress)

The gtk flag naming problem is not serious in the sense that it will
break user systems. Additionally, it has been known and discussed for a
long time. Establishing a gtk USE flag policy did not become suddenly so
urgent that next council meeting was too far in the future.

> The GLEP states that we can
>
>  1) maintain a list of current "QA Standards";
>
>  2) ensure all developer tools are in line with the current QA
>  standards;
>
>  3) and apply it as per "In the event that a developer still insists
>  that a package does not break QA standards, an appeal can be made at
>  the next council meeting. The package should be dealt with per QA's
>  request until such a time that a decision is made by the council."
>
> which effectively makes the "QA Standards" act as policy.

I don't think that it is necessarily the case. "QA standard" could also
mean telling developers to either use gtk USE flags in the QA team
recommended way, or ensuring through other means that users to not
encounter unexpected breakage. Another possible interpretation is that
QA standards codify established good practices which are largely
non-controversial (it was attempted with saying that live ebuilds should
be unkeyworded or p.mask'ed IIRC)..

> As "QA Standards" under this interpretation are needed to raise
> quality; the council should clarify whether we are able to raise the
> quality level, or rather are restricted to what exists and expect the
> council to raise the quality instead (by having the council do that).

"raise the quality" is very subjective. This would not restrict QA
powers at all, because almost any policy can claim that as its aim.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Patrick Lauer]

On 02/25/2014 12:46 AM, Chí-Thanh Christopher Nguyễn wrote:
> Donnie Berkholz schrieb:
>> Funny how every time a controversial decision gets made, somebody
>> inevitably tries to undermine the authority of the group making the
>>  decision.
>>
>> In my understanding, the issue you want to address is whether the
>> QA team has authority over tree policy.
>>
>> Will add to the agenda.
> 
> Thanks, I would like to phrase the question a little more precisely:
> 
> I would like to ask council to state whether the QA team has the
> authority to mandate a policy when there is neither general agreement
> that this policy is a good thing, nor the policy would avert any kind
> of immediate serious problem for users.

Since there will always be disagreement and subjective interpretation
this can also be rephrased as:

"I'd like to ask the council to reconsider having a QA team"

How do you expect improvement to happen when the only "legal" action is,
err, writing a strongly-worded letter?
> 
>> I happen to disagree. GLEP 48's point about maintaining "QA
>> Standards" applies to this.
> 
> "QA Standards" are not really defined in GLEP 48 either. Maybe council
> could also clarify whether "QA Standard" is just another name for
> "tree policy".
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 
> 
> 

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Patrick Lauer]

> Please respond to this message with agenda items. Do not hesitate to repeat 
> your agenda item here with a pointer if you previously suggested one (since 
> the last meeting).

Here's one thing that's low priority and still controversial:

(Since no one wants the QA team to actually *do* anything ... sigh)


Make all cosmetic repoman warnings fatal

Rationale: Either we care about things like whitespace and quoting, or
we don't.

If we care then we shouldn't allow anyone to commit a bad ebuild

If we don't care then repoman shouldn't annoy us with useless whining
that doesn't matter anyway


The affected repoman checks should be at least (but possibly not limited
to):

* unused local useflag descriptions in metadata.xml
* Whitespace, both at the beginning and the end of the line
	(this will need an improved repoman check to make sense
	as it currently has a few false positive matches)
* variable quoting (may have false positives too)


Thanks,

Patrick

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Tom Wijsman]

On Mon, 24 Feb 2014 22:43:41 +0100
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Tom Wijsman schrieb:
> >> Thanks, I would like to phrase the question a little more
> >> precisely:
> >>
> >> I would like to ask council to state whether the QA team has the
> >> authority to mandate a policy when there is neither general
> >> agreement that this policy is a good thing, nor the policy would
> >> avert any kind of immediate serious problem for users.
> > That can be reduced to the question whether QA is considered
> > serious.
> 
> I don't think so. If the council answers this question in the
> negative, QA still has its emergency powers and can enforce the
> policy set by the council.
> QA can also propose any new policy they consider useful to the
> council, which can then hear the opposing sides and make a decision
> based on that.

You describe a Gentoo Developer, apart from the small difference that
they have this emergency power; when it comes to it, that power is
quite similar to having a Gentoo Developer revert according to policy
and that deemed as OK (under the assumption of there being no QA team).

> > (There is a majority that agrees as well as a serious problem to
> > users in the GTK+ USE flag situation; the former can be deduced
> > from the mailing list, the latter can be realized when controlling
> > the USE flag among a lot of GTK+ packages. It is something that can
> > be done later; on the other hand, if we categorize everything that
> > way it halts progress)
> 
> The gtk flag naming problem is not serious in the sense that it will
> break user systems.

It depends on how you define the words; but I find it a serious issue
if you have an USE flag that works one way in a set of packages and
works the other way in another set of packages, it is broken in the
sense that the user now has to use package.use if he has a lot of
packages that have a gtk flag and needs that flag to behave.

> Additionally, it has been known and discussed for a long time.

If it comes up again and again on ML, upsets people in bugs, have people
bring it up independently to both QA and Council; it is of much more
concern than for example a thread about small bug wrangling details.

> Establishing a gtk USE flag policy did not become suddenly so urgent
> that next council meeting was too far in the future.

The discussions, pings and mails act as a nagging reminder.

> > The GLEP states that we can
> >
> >  1) maintain a list of current "QA Standards";
> >
> >  2) ensure all developer tools are in line with the current QA
> >  standards;
> >
> >  3) and apply it as per "In the event that a developer still insists
> >  that a package does not break QA standards, an appeal can be made
> > at the next council meeting. The package should be dealt with per
> > QA's request until such a time that a decision is made by the
> > council."
> >
> > which effectively makes the "QA Standards" act as policy.
> 
> I don't think that it is necessarily the case. "QA standard" could
> also mean telling developers to either use gtk USE flags in the QA
> team recommended way, or ensuring through other means that users to
> not encounter unexpected breakage.

The GNOME team's internal policy was a recommendation; as can be seen
from the current state, that doesn't ensure anything. What other means
would ensure that users do not have to micro manage with package.use?

> Another possible interpretation is that QA standards codify
> established good practices which are largely non-controversial (it
> was attempted with saying that live ebuilds should be unkeyworded or
> p.mask'ed IIRC)..

It also depends on who discovers the new problems, who forms the
explanations, who decides how to fix the problem; ...

For that, you can look at mentions like "This is done primarily by
finding and pointing out issues to maintainers and, where necessary,
taking direct action.". But then you once again need to know whether
"issues" are meant as "policy violation", or as "breakage", I think we
can go on for a while here...

We need to remind ourselves that a GLEP is a "Gentoo Linux Enhancement
Proposals" and that it is nowhere a picture perfect policy; so, yes, I
hope the seriousness (and associated consequences) is clarified.

GLEP 48 addresses controversy with "In the event that a developer still
insists that a package does not break QA standards, an appeal can be
made at the next council meeting. The package should be dealt with per
QA's request until such a time that a decision is made by the council.".

> > As "QA Standards" under this interpretation are needed to raise
> > quality; the council should clarify whether we are able to raise the
> > quality level, or rather are restricted to what exists and expect
> > the council to raise the quality instead (by having the council do
> > that).
> 
> "raise the quality" is very subjective. This would not restrict QA
> powers at all, because almost any policy can claim that as its aim.

Policy formulation is a power that has a near direct effect on quality.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Rich Freeman]

On Mon, Feb 24, 2014 at 4:43 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> The gtk flag naming problem is not serious in the sense that it will
> break user systems. Additionally, it has been known and discussed for a
> long time. Establishing a gtk USE flag policy did not become suddenly so
> urgent that next council meeting was too far in the future.

Just tossing this out there, but a compromise might be to encourage QA
to make non-urgent policy changes effective after a period of time
(~30 days).  That would allow them time to make revisions if they feel
it necessary in light of comments (but would not obligate them to do
so), and it would give the council time to take action if necessary
(but QA policies would not require explicit council confirmation).
Whether any particular policy change warrants the delay vs taking
effect immediately could be at their discretion.

Rich