[gentoo-project] Call for agenda items - Council meeting 2012-04-03

[gentoo-project] Call for agenda items - Council meeting 2012-04-03

[Ulrich Mueller]

In two weeks from now, the council will meet again. This 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 email with agenda items. Please do not
hestitate to repeat your agenda item here with a pointer if you
previously suggested one (since the last meeting).

The agenda for the next meeting will be sent out on Tuesday 27th
of March 2012.

Please respond to the gentoo-project list, if possible.

Ulrich

[gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Ulrich Mueller]

> In two weeks from now, the council will meet again. This is the time
> to raise and prepare items that the council should put on the agenda
> to discuss or vote on.

To reply to my own message:

Vote on EAPI specification in/for ebuilds.
<http://archives.gentoo.org/gentoo-dev/msg_288fa260bf4c9242a33380fd4bfce0f8.xml>

Ulrich

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Markos Chandras]

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

On 03/20/2012 06:55 AM, Ulrich Mueller wrote:
>> In two weeks from now, the council will meet again. This is the
>> time to raise and prepare items that the council should put on
>> the agenda to discuss or vote on.
> 
> To reply to my own message:
> 
> Vote on EAPI specification in/for ebuilds. 
> <http://archives.gentoo.org/gentoo-dev/msg_288fa260bf4c9242a33380fd4bfce0f8.xml>
>
>  Ulrich
> 

I am sorry but this thread is huge. What is the exact question you
want the Council to vote on?

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIbBAEBCgAGBQJPaOjBAAoJEPqDWhW0r/LCbPIP90J2IZE6oWXowY5y9qwIoCE0
SDUpWa594xsMD14vZm4HgQubuFy8VY8i0ttyV0yg9BGCcTaYryklOcPO1b+oCGmy
UyzjhdHC7HkIuV4sFTE6+S6Gmq75ZudzLoqS5h7pl3SyK3NtPvKBKmh5GRniK7hJ
lBj1eo3jc1+r5Cj7w1tVuNHtr5jxCVFCo5lieab0PHkWHfVzI0gP2/KD0jm7MY8s
fPJhC5bsGM5a19H/uYrrkCOT5VtD6LKYooq2DdRWelwTiQyslOyWnOVjKn2hEZSV
qqNCFfN3etZYKrHb6DgF8pXzPkr5eDvtnyBtFE+TIzEhvBdezXbQ/3HynbjgrRJW
nsg4MJRu72MSlXkWrrra8vSccaDYCmZu7h7y8kzdaRWnepg5U2RdStUAcTs971hV
hmhSNVF495LHNJZzulpj5aq4I+2AFuq3qYi1arOpzmaZItjYXBUXky0+j5vseyFI
ooOLtpSdFbP2mvLVblbioVQk/ipr7S81uh/c/VTa1MYINb0zUYE+mED5+NvQdMeZ
DzgjNKUZlZ+F9M6iJnEd0rtNopfVMVpHKbEKoqJKRbsoJygPw3dBObqzKVhZMdyf
uFvz+Xzy0QlNRw7xGzHTcjyzjrCL9iRLlwLguiFkL6V31GQ307iGiX2d4U2rI/f0
5rR/gOpPbNmpSKa95vM=
=muDa
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Ciaran McCreesh]

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

On Tue, 20 Mar 2012 20:29:53 +0000
Markos Chandras <hwoarang@gentoo.org> wrote:
> I am sorry but this thread is huge. What is the exact question you
> want the Council to vote on?

Please read the entire thread, along with all the background material,
before voting. Last time this went to the Council, we wasted three
months where Council members kept asking questions that had already
been answered elsewhere.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9o6o4ACgkQ96zL6DUtXhF3qwCguX5EZBcKgKUPeHDJkHunBtb2
wVAAnRxnWjyS68Doxj4rfxhEiDwJF8xk
=Rrof
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Markos Chandras]

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

On 03/20/2012 08:37 PM, Ciaran McCreesh wrote:
> On Tue, 20 Mar 2012 20:29:53 +0000 Markos Chandras
> <hwoarang@gentoo.org> wrote:
>> I am sorry but this thread is huge. What is the exact question
>> you want the Council to vote on?
> 
> Please read the entire thread, along with all the background
> material, before voting. Last time this went to the Council, we
> wasted three months where Council members kept asking questions
> that had already been answered elsewhere.
> 
This is why I asked because that thread is a bit messy and it is not
clear what should be discussed/voted by the Council.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJPaPTFAAoJEPqDWhW0r/LCZ0oP/RAcYqYGHB7313g+lu0Wc0WE
09/SvuxBoPm8r34jGeU6bubSslWP2rlZ4BWKhYCMOD2cgvJwIyNg691+eLFOipAm
eVqFlq39raQAUdug97B0oqkkrs9PzNfEQ55N7AHlEp071Z0idyBkXIo4WEU4Nf7c
le9Lfy9cUSTSbjEuw/LrXK8aGUZmHvkpho7D5eM5nU7809M+O95C4TLEwXzZj8xM
hLrYgtajMyZ3y7pZ6s+wkS1yUb6hlsvEiGzrKM9Ik8ThxCaM7Gg52OIw0AEhGQny
hzQf0A/ghXwpvDUsXhD9pkDn6i9CfuNTxWfG91SXVzlAVOYMR4guCTXxgppLOsyN
fqwyEgUPW1NjgjEivRZtssDou14ocxZzpp2eG+tjL1Fi0XILA8h7KX9owov2rhG9
coebWbK3LsU+bDbzQ5wr/STf/gfJ+TPW04kJmaQREj7eDV1EHZci/g1TBCosh23z
dixugFuIsrFLe5xENhbFZbJpOfYwOmPuPOPtRAA5k0Hts6y6Uqn4dTerXjPhNsPe
TKrfHqFDhiL2QRsbRbuXPnm25VUB1aMSK99GWDyEf469AxX60T9z4SMYzQn5FVOS
DRClhNLX704F4c8WoFat33/fbGVX0mvbE9kCGBBGDOd+QZ1tTyXDqqWYAHTAI2Ns
l9N8Tou7Rk4Tn4QdHa2w
=9jda
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Ulrich Mueller]

>>>>> On Tue, 20 Mar 2012, Markos Chandras wrote:

>> Vote on EAPI specification in/for ebuilds. 
>> <http://archives.gentoo.org/gentoo-dev/msg_288fa260bf4c9242a33380fd4bfce0f8.xml>

> I am sorry but this thread is huge. What is the exact question you
> want the Council to vote on?

My idea would be that we first vote if we want to address the issue.
If this is accepted, then we would have to decide between the
different solutions that have been proposed.

We have attempted to collect all ideas here:
<http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms>

Ulrich

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Pacho Ramos]

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

El mar, 20-03-2012 a las 22:00 +0100, Ulrich Mueller escribió:
> >>>>> On Tue, 20 Mar 2012, Markos Chandras wrote:
> 
> >> Vote on EAPI specification in/for ebuilds. 
> >> <http://archives.gentoo.org/gentoo-dev/msg_288fa260bf4c9242a33380fd4bfce0f8.xml>
> 
> > I am sorry but this thread is huge. What is the exact question you
> > want the Council to vote on?
> 
> My idea would be that we first vote if we want to address the issue.
> If this is accepted, then we would have to decide between the
> different solutions that have been proposed.
> 
> We have attempted to collect all ideas here:
> <http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms>
> 
> Ulrich
> 
> 

From my point of view, both decisions could be made at the same meeting:
1º Should we discuss it? -> Yes -> go to 2º // No -> end
2º Discuss alternatives

That would safe time in case you decide to address that issue and
wouldn't hurt in case you don't :)

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Fabian Groffen]

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

On 20-03-2012 22:34:14 +0100, Pacho Ramos wrote:
> > My idea would be that we first vote if we want to address the issue.
> > If this is accepted, then we would have to decide between the
> > different solutions that have been proposed.
> > 
> > We have attempted to collect all ideas here:
> > <http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms>
> > 
> From my point of view, both decisions could be made at the same meeting:
> 1º Should we discuss it? -> Yes -> go to 2º // No -> end
> 2º Discuss alternatives
> 
> That would safe time in case you decide to address that issue and
> wouldn't hurt in case you don't :)

IMO we don't have to waste a (part of a) meeting on deciding if we want
to address the issue at all.  We (council) should just reach that
conclusion here on-list, so we can prepare for the actual votes in
actual council meeting.



-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Ulrich Mueller]

>>>>> On Wed, 21 Mar 2012, Fabian Groffen wrote:

> On 20-03-2012 22:34:14 +0100, Pacho Ramos wrote:
>> From my point of view, both decisions could be made at the same meeting:
>> 1º Should we discuss it? -> Yes -> go to 2º // No -> end
>> 2º Discuss alternatives

Actually, my plan was not only to discuss 2º, but to vote on it in the
same meeting.

> IMO we don't have to waste a (part of a) meeting on deciding if we
> want to address the issue at all. We (council) should just reach
> that conclusion here on-list, so we can prepare for the actual votes
> in actual council meeting.

Or the option of keeping the status quo could be one of the
alternatives of the vote. It would be six alternatives then. 

I can prepare a Condorcet (Schulze method) vote, just for the case
that we don't get an absolute majority for one of them.

Ulrich

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Brian Harring]

On Wed, Mar 21, 2012 at 09:09:10AM +0100, Ulrich Mueller wrote:
> >>>>> On Wed, 21 Mar 2012, Fabian Groffen wrote:
> 
> > On 20-03-2012 22:34:14 +0100, Pacho Ramos wrote:
> >> From my point of view, both decisions could be made at the same meeting:
> >> 1? Should we discuss it? -> Yes -> go to 2? // No -> end
> >> 2? Discuss alternatives
> 
> Actually, my plan was not only to discuss 2?, but to vote on it in the
> same meeting.

No point in jumping the gun.  Frankly considering the issues of the 
various proposals haven't really been fully fleshed out up until that 
wiki page (prior, they were at best in PM authors heads), and 
that's not counting the level of misunderstandings people had 
about it (and likely still do).  I'd rather see people properly 
consider it rather than try to fit it into a single council meeting.


> > IMO we don't have to waste a (part of a) meeting on deciding if we
> > want to address the issue at all. We (council) should just reach
> > that conclusion here on-list, so we can prepare for the actual votes
> > in actual council meeting.
> 
> Or the option of keeping the status quo could be one of the
> alternatives of the vote. It would be six alternatives then. 
> 
> I can prepare a Condorcet (Schulze method) vote, just for the case
> that we don't get an absolute majority for one of them.

Condorcet should be dev wide imo, rather than council.  I'm certainly 
not of the belief we should do group wide votes on every decision, but 
this sort of thing is likely to generally piss people off and not have 
any clear majority on its own- thus would go that route.

More importantly, while PM authors have a definite say from a 
technical standpoint (that metadata.xml proposal for example has nasty 
implications for performance/cache), it's devs who are going to feel 
the impact of it the most in their workflow.  They're views matter 
fairly heavily (as long as it's not a technical nightmare of course).

~brian

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Rich Freeman]

On Wed, Mar 21, 2012 at 7:52 AM, Brian Harring <ferringb@gmail.com> wrote:
> Condorcet should be dev wide imo, rather than council.  I'm certainly
> not of the belief we should do group wide votes on every decision, but
> this sort of thing is likely to generally piss people off and not have
> any clear majority on its own- thus would go that route.

Frankly, this really strikes me as one of those situations where
resolving it by some kind of majority vote among many options is
probably the worst possible way to resolve it.

If we narrow it down to one or two items and there is a consensus
among the Council that either is fine and it comes down to religious
preference, then a limited dev-wide vote might at least settle the
debate.  However, I wouldn't just throw the 47 options in the email
chains into some huge list and have everybody rank them.

It probably wouldn't hurt to have the Council members hash this out to
some extent before going into a meeting.  If the only time you discuss
this is 20 minutes per month you'll never make a decision.  By all
means hash it out on -project or on an email alias if noise is too
great.  Perhaps post updates to -project if the latter is used, and
let everybody influence the debate indirectly through the Council.

I think just about every line of argument has already been hashed out
over the last few years.  The council members just need to go over the
debate and form a consensus.  Using a vote to solicit feedback is
fine, but I wouldn't use it as a substitute for discussion and forming
consensus.

Rich

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Ulrich Mueller]

>>>>> On Wed, 21 Mar 2012, Brian Harring wrote:

> On Wed, Mar 21, 2012 at 09:09:10AM +0100, Ulrich Mueller wrote:
>> Actually, my plan was not only to discuss 2?, but to vote on it in
>> the same meeting.

> No point in jumping the gun.  Frankly considering the issues of the
> various proposals haven't really been fully fleshed out up until
> that wiki page (prior, they were at best in PM authors heads),

Right, but at least I won't "fully flesh out" all five of them (not
counting variants), if it's clear that four of these five are for the
dustbin. Refining each of them to the level that's appropriate for a
GLEP or for inclusion in PMS means quite some work.

I'd rather see the vote at the next meeting as a recommendation that
such or such proposal should be worked out in detail. Meaning one of
the proposals if there's a clear majority, or maybe two if the
decision is split. The council would need to vote on it again for its
final acceptance.

> and that's not counting the level of misunderstandings people had
> about it (and likely still do).  I'd rather see people properly
> consider it rather than try to fit it into a single council meeting.

We should of course assume that council members will be prepared and
consider it before the meeting. ;-) Certainly it wouldn't be very
efficient use of the time if all details of the different proposals
would have to be explained during the meeting.

Ulrich

Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03

[Pacho Ramos]

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

El mar, 20-03-2012 a las 07:48 +0100, Ulrich Mueller escribió:
> In two weeks from now, the council will meet again. This 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 email with agenda items. Please do not
> hestitate to repeat your agenda item here with a pointer if you
> previously suggested one (since the last meeting).
> 
> The agenda for the next meeting will be sent out on Tuesday 27th
> of March 2012.
> 
> Please respond to the gentoo-project list, if possible.
> 
> Ulrich
> 
> 

I would like to see this suggestion discussed if possible:
About making herds.xml addition mandatory for devs when adding to mail
alias

Currently, looks like there are developers that add them to mail aliases
for "zombie" herds (herds that are empty and unmaintained usually) but
don't want to add them to herds.xml because they prefer to not be
considered as officially being part of that hers. This causes that herds
to be not maintained very actively as we rely on that "hidden"
maintainer having enough time to take care of *all* packages included in
that herd. The situation is, then, like a "pseudo-unmaintained" herd as
bugs are still assigned to that alias and get out of radar of
maintainer-needed alias (that includes people wanting to help with that
unmaintained packages, trying to find maintainers or proxy-maintainers
for them or removing them is needed) and we depend on that dev added to
mail alias to take care of them, this is also problematic when dev
decides to drop him from alias getting herd totally unmaintained without
any notice to gentoo-dev ML.

Since there is no need to stay in the herd some prefixed time, I see no
reason to allow developers to be in mail aliases without adding them to
herds.xml, and this allows others to "easily" review herds.xml looking
for empty herds.

Thanks a lot


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

Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03

[Chí-Thanh Christopher Nguyễn]

Pacho Ramos schrieb:
> I would like to see this suggestion discussed if possible:
> About making herds.xml addition mandatory for devs when adding to mail
> alias
>
> Currently, looks like there are developers that add them to mail aliases
> for "zombie" herds (herds that are empty and unmaintained usually) but
> don't want to add them to herds.xml because they prefer to not be
> considered as officially being part of that hers.

If you mandate that, then those developers will simply resort to
following the mail alias on bugzilla. Not much gained IMHO.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03

[Pacho Ramos]

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

El mar, 20-03-2012 a las 13:34 +0100, Chí-Thanh Christopher Nguyễn
escribió:
> Pacho Ramos schrieb:
> > I would like to see this suggestion discussed if possible:
> > About making herds.xml addition mandatory for devs when adding to mail
> > alias
> >
> > Currently, looks like there are developers that add them to mail aliases
> > for "zombie" herds (herds that are empty and unmaintained usually) but
> > don't want to add them to herds.xml because they prefer to not be
> > considered as officially being part of that hers.
> 
> If you mandate that, then those developers will simply resort to
> following the mail alias on bugzilla. Not much gained IMHO.
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn

The problem is that, when they are in mail alias, other could tend to
assume that packages are maintained by him, while it could not be the
case and it can cause confusion :-/

For example, media-optical was a lot of time with a dev listed in alias
and, then, some of us assumed he was maintaining them (even if the herd
was still shown as empty in herds.xml). Later, if I remember correctly,
he dumped himself from mail alias and the herd became orphan without any
notice. Another problem is that it's difficult to know the "degree" of
herd maintenance when a dev is listed only in mail alias. Is he there to
be aware of a few packages inside that herd or is he caring for most of
them?


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

Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03

[Mike Gilbert]

On Tue, Mar 20, 2012 at 5:41 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> Since there is no need to stay in the herd some prefixed time, I see no
> reason to allow developers to be in mail aliases without adding them to
> herds.xml, and this allows others to "easily" review herds.xml looking
> for empty herds.
>

From what you've said, the mail alias should just be ignored when
reviewing herds.

It is possible that the people on the alias are simply curious and
have no intention of maintaining anything. I don't have a problem with
that.

Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03

[Pacho Ramos]

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

El mar, 20-03-2012 a las 11:32 -0400, Mike Gilbert escribió:
> On Tue, Mar 20, 2012 at 5:41 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> > Since there is no need to stay in the herd some prefixed time, I see no
> > reason to allow developers to be in mail aliases without adding them to
> > herds.xml, and this allows others to "easily" review herds.xml looking
> > for empty herds.
> >
> 
> >From what you've said, the mail alias should just be ignored when
> reviewing herds.
> 
> It is possible that the people on the alias are simply curious and
> have no intention of maintaining anything. I don't have a problem with
> that.
> 
> 

But we need to clearly state that, when a herd is empty in herds.xml we
should consider their packages as orphan even if some devs are listed in
the alias.

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

[gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Ryan Hill]

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

On Tue, 20 Mar 2012 19:37:30 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> El mar, 20-03-2012 a las 11:32 -0400, Mike Gilbert escribió:
> > On Tue, Mar 20, 2012 at 5:41 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> > > Since there is no need to stay in the herd some prefixed time, I see no
> > > reason to allow developers to be in mail aliases without adding them to
> > > herds.xml, and this allows others to "easily" review herds.xml looking
> > > for empty herds.
> > 
> > From what you've said, the mail alias should just be ignored when
> > reviewing herds.
> > 
> > It is possible that the people on the alias are simply curious and
> > have no intention of maintaining anything. I don't have a problem with
> > that.
> 
> But we need to clearly state that, when a herd is empty in herds.xml we
> should consider their packages as orphan even if some devs are listed in
> the alias.

I thought that was the case already.  Why would devs on the alias be
considered maintainers in the first place?


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Pacho Ramos]

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

El vie, 23-03-2012 a las 23:23 -0600, Ryan Hill escribió:
> On Tue, 20 Mar 2012 19:37:30 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > El mar, 20-03-2012 a las 11:32 -0400, Mike Gilbert escribió:
> > > On Tue, Mar 20, 2012 at 5:41 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> > > > Since there is no need to stay in the herd some prefixed time, I see no
> > > > reason to allow developers to be in mail aliases without adding them to
> > > > herds.xml, and this allows others to "easily" review herds.xml looking
> > > > for empty herds.
> > > 
> > > From what you've said, the mail alias should just be ignored when
> > > reviewing herds.
> > > 
> > > It is possible that the people on the alias are simply curious and
> > > have no intention of maintaining anything. I don't have a problem with
> > > that.
> > 
> > But we need to clearly state that, when a herd is empty in herds.xml we
> > should consider their packages as orphan even if some devs are listed in
> > the alias.
> 
> I thought that was the case already.  Why would devs on the alias be
> considered maintainers in the first place?
> 
> 

If it's clear that devs on alias shouldn't be considered as maintainers
when herds.xml shows that one as empty, ok then, nothing more to
discuss :)

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Markos Chandras]

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

On 03/24/2012 08:04 AM, Pacho Ramos wrote:
> El vie, 23-03-2012 a las 23:23 -0600, Ryan Hill escribió:
>> On Tue, 20 Mar 2012 19:37:30 +0100 Pacho Ramos <pacho@gentoo.org>
>> wrote:
>> 
>>> El mar, 20-03-2012 a las 11:32 -0400, Mike Gilbert escribió:
>>>> On Tue, Mar 20, 2012 at 5:41 AM, Pacho Ramos
>>>> <pacho@gentoo.org> wrote:
>>>>> Since there is no need to stay in the herd some prefixed
>>>>> time, I see no reason to allow developers to be in mail
>>>>> aliases without adding them to herds.xml, and this allows
>>>>> others to "easily" review herds.xml looking for empty
>>>>> herds.
>>>> 
>>>> From what you've said, the mail alias should just be ignored
>>>> when reviewing herds.
>>>> 
>>>> It is possible that the people on the alias are simply
>>>> curious and have no intention of maintaining anything. I
>>>> don't have a problem with that.
>>> 
>>> But we need to clearly state that, when a herd is empty in
>>> herds.xml we should consider their packages as orphan even if
>>> some devs are listed in the alias.
>> 
>> I thought that was the case already.  Why would devs on the alias
>> be considered maintainers in the first place?
>> 
>> 
> 
> If it's clear that devs on alias shouldn't be considered as
> maintainers when herds.xml shows that one as empty, ok then,
> nothing more to discuss :)

Yes this is somewhat clear. Maintainers are listed on project pages.
mail aliases are a separate thing and everyone can add himself there
without a leaders' approval.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJPbZwrAAoJEPqDWhW0r/LC79IP/iEviufx4S5deuwf1J4sH/jc
+7TAmzQ+Pooee1wuPUZXeUsnOHlvs39t1cRBuF0iS++FYfp9gglMeqDMvd9SSyYl
B49h8nJdP4TqZx09hlL926FYGG/AM4jQD4v+Iq0YdQR/9fG7KFUErPhrMIlFJk+4
o4kZSnlZ3UP6k1bT7USYGwOiBKSpRmkm4zbbO8jvgZ2ngeFXzbgpXr17GNWw+NOv
JgKa92JHNoAWWvusV/6qIVtt49rUGKITpe+tLzEyrQMKjRz2dDdso9t9CQy6ZxOm
7yPNvuEgRLD3MGHcKDURPpPy1/pyvjPR/0W1bXe1JxTeOr4aluHGgBwsx/uajtNd
jrNw3MY4TLbuuMY0Ie0hU4expI1HHwio3I1mlaYTC4Jomor0FCr5k5kSDfwhco+H
vvBydP5QzYFsDatjARxZAsrWjlVkkbBv4QNFmc1Y4DCiUINH37mS6FfiD5IrvMuu
O6GZkLhcmEMdHmaFwXQC3W4eEo1WVMkOrdkqOmPJf/P0obPOKDKKPJha/gJmL4v4
kBOkK9HCfoqb5cOxMUB8PonDRkJfjFv5LcHj2QNCEZ99W6vm/0I3tptaaBzvRSEB
0h6oMMIMp+c8qGyLL9OYoX1u+Mtacakn998kZjk8FMfpuJElH1kG1RP22qqnHRHT
JsFkyGRFV9XZ9NtEAbkr
=mkCE
-----END PGP SIGNATURE-----

[gentoo-project] Re: Call for agenda items - Council meeting 2012-04-03

[Ryan Hill]

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

On Tue, 20 Mar 2012 10:41:38 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> I would like to see this suggestion discussed if possible:
> About making herds.xml addition mandatory for devs when adding to mail
> alias.

Then you should start a thread on -dev and have that discussion.  When you
actually have something concrete you want the council to decide on, propose it
then.

Sorry to single you out, but it always annoys me when people suggest items
for the agenda that haven't been discussed at all anywhere else.  The council
isn't going to make a decision without hearing from other people, so the best
you can hope for is they decide someone should start a thread about it.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

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

Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03

[Tony "Chainsaw" Vroon]

On 20/03/12 06:48, Ulrich Mueller wrote:
> In two weeks from now, the council will meet again. This is the time
> to raise and prepare items that the council should put on the agenda
> to discuss or vote on.

Newer udev (180+) is attempting to force /usr to be mounted *very* early
in the boot sequence. No other software has this requirement, and it is
going to break LVM2 users that have a separate /usr. Our official
documentation recommends this, even today:
http://www.gentoo.org/doc/en/lvm2.xml

Now that it is unmasked and unleashed on ~arch users, this might result
in an attempt to stable it. I would like for the council to decide on
whether a separate /usr is still a supported configuration.
If it is, newer udev can not be stabled and alternatives should be
investigated. If it isn't, a lot of documentation will have to be
updated. (And an alternative should likely still be provided)

Regards,
Tony V.

Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03

[Zac Medico]

On 03/20/2012 04:23 AM, Tony "Chainsaw" Vroon wrote:
> On 20/03/12 06:48, Ulrich Mueller wrote:
>> In two weeks from now, the council will meet again. This is the time
>> to raise and prepare items that the council should put on the agenda
>> to discuss or vote on.
>
> Newer udev (180+) is attempting to force /usr to be mounted *very* early
> in the boot sequence. No other software has this requirement, and it is
> going to break LVM2 users that have a separate /usr. Our official
> documentation recommends this, even today:
> http://www.gentoo.org/doc/en/lvm2.xml
>
> Now that it is unmasked and unleashed on ~arch users, this might result
> in an attempt to stable it. I would like for the council to decide on
> whether a separate /usr is still a supported configuration.

To clarify, the question is whether or not we support a separate /usr 
_without_ mounting it early via an initramfs.

> If it is, newer udev can not be stabled and alternatives should be
> investigated.

A possible compromise would be to use pkg_pretend to check if /usr is a 
mount point, and die if the user hasn't set a variable or a USE flag to 
indicate awareness that /usr must be mounted early.

> If it isn't, a lot of documentation will have to be
> updated. (And an alternative should likely still be provided)
-- 
Thanks,
Zac

Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03

[Rich Freeman]

On Wed, Mar 21, 2012 at 2:12 PM, Zac Medico <zmedico@gentoo.org> wrote:
> On 03/20/2012 04:23 AM, Tony "Chainsaw" Vroon wrote:
>
>> If it is, newer udev can not be stabled and alternatives should be
>> investigated.
>
> A possible compromise would be to use pkg_pretend to check if /usr is a
> mount point, and die if the user hasn't set a variable or a USE flag to
> indicate awareness that /usr must be mounted early.

I'm avoiding commenting redundant with the whole previous email chain,
but I don't really see this as anything other than a mitigation during
some temporary migration period.  That is, unless you want to keep
udev-171 in the tree for the next 15 years or until the default is
some other replacement without this limitation.

Unless somebody is actually willing to maintain a robust alternative I
don't really see that as a real option.  If upstream moves in one
direction, and nobody is willing to maintain things in a different
state, then you just end up with a system package that nobody wants to
use, and something in an overlay that everybody uses instead that is
beyond these debates.  You can't effectively mandate that people
maintain something in a volunteer organization, unless the effort
involved is very minor.

The Council can of course lend moral support to a particular
direction, but Gentoo will only get there if somebody writes the code.
 Right now I don't see anybody maintaining a robust /usr-less udev
fork yet.  If one existed the Council could easily make one vs the
other default, or ask to have it in the handbook, etc.

>
>> If it isn't, a lot of documentation will have to be
>> updated. (And an alternative should likely still be provided)

I'd say that quite a bit of documentation needs to be updated before
udev is stabilized in any case.

Rich