[gentoo-project] Council meeting 2015-01-13: call for agenda items

[gentoo-project] Council meeting 2015-01-13: call for agenda items

[Andreas K. Huettel]

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

The next council meeting will be in roughly two weeks time on Tuesday 
2015-01-13, 19:00 UTC in the #gentoo-council channel on Freenode.

For proposing agenda items and discussion of these, please reply to this mail 
on the gentoo-project mailing list.

Cheers, 
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: 819 bytes --]

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Anthony G. Basile]

On 12/27/14 07:34, Andreas K. Huettel wrote:
> The next council meeting will be in roughly two weeks time on Tuesday
> 2015-01-13, 19:00 UTC in the #gentoo-council channel on Freenode.
>
> For proposing agenda items and discussion of these, please reply to this mail
> on the gentoo-project mailing list.
>
> Cheers,
> Andreas
>

I'd like to add a discussion on glep 39.  In particular, under 
specifications we have:

"It may have one or many leads, and the leads are selected by the 
members of the project. This selection must occur at least once every 12 
months, and may occur at any time."

That requirement and others in the glep assume two things: 1) we have a 
team which is not lame and 2) the team has a lead which is not lame.  
We've seen cases where both are true.  This gives rise to situations 
where we are not sure who's on the team, who is in charge of what, etc.  
Worse, someone willing to help out doesn't feel he/she has the authority 
to make commits, can't get that authority and feels paralyzed or just 
acts without cooperation.

I'd like to discuss this in light of glep 39 and see if we can't 
steamline the workflow in these cases.

-- 
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] Council meeting 2015-01-13: call for agenda items

[Michał Górny]

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

Dnia 2014-12-28, o godz. 06:43:47
"Anthony G. Basile" <blueness@gentoo.org> napisał(a):

> On 12/27/14 07:34, Andreas K. Huettel wrote:
> > The next council meeting will be in roughly two weeks time on Tuesday
> > 2015-01-13, 19:00 UTC in the #gentoo-council channel on Freenode.
> >
> > For proposing agenda items and discussion of these, please reply to this mail
> > on the gentoo-project mailing list.
> 
> I'd like to add a discussion on glep 39.  In particular, under 
> specifications we have:
> 
> "It may have one or many leads, and the leads are selected by the 
> members of the project. This selection must occur at least once every 12 
> months, and may occur at any time."
> 
> That requirement and others in the glep assume two things: 1) we have a 
> team which is not lame and 2) the team has a lead which is not lame.  
> We've seen cases where both are true.  This gives rise to situations 
> where we are not sure who's on the team, who is in charge of what, etc.  
> Worse, someone willing to help out doesn't feel he/she has the authority 
> to make commits, can't get that authority and feels paralyzed or just 
> acts without cooperation.
> 
> I'd like to discuss this in light of glep 39 and see if we can't 
> steamline the workflow in these cases.

We should also finally decide on a clear way of knowing who's on
the team. Right now wiki list seems to be the de-facto solution but
many developers simply don't want to get a wiki account...

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Andreas K. Huettel]

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

Am Sonntag, 28. Dezember 2014, 12:57:16 schrieb Michał Górny:
> 
> We should also finally decide on a clear way of knowing who's on
> the team. Right now wiki list seems to be the de-facto solution but
> many developers simply don't want to get a wiki account...

Given that all project pages are supposed to move to the wiki, the wiki *is* 
the solution...

I'm sorry, but I dont really see the point of refusing to create a wiki 
account. That's a bit like not committing anything because you don't like cvs.

-- 
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: 819 bytes --]

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Michał Górny]

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

Dnia 2014-12-28, o godz. 17:45:36
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> Am Sonntag, 28. Dezember 2014, 12:57:16 schrieb Michał Górny:
> > 
> > We should also finally decide on a clear way of knowing who's on
> > the team. Right now wiki list seems to be the de-facto solution but
> > many developers simply don't want to get a wiki account...
> 
> Given that all project pages are supposed to move to the wiki, the wiki *is* 
> the solution...
> 
> I'm sorry, but I dont really see the point of refusing to create a wiki 
> account. That's a bit like not committing anything because you don't like cvs.

You don't need to tell me that. But what I'm supposed to do, throw
people off the team because they don't have a wiki account? Keep a
second list somewhere with those people?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Patrick Lauer]

On Sunday 28 December 2014 17:45:36 Andreas K. Huettel wrote:
> Am Sonntag, 28. Dezember 2014, 12:57:16 schrieb Michał Górny:
> > We should also finally decide on a clear way of knowing who's on
> > the team. Right now wiki list seems to be the de-facto solution but
> > many developers simply don't want to get a wiki account...
> 
> Given that all project pages are supposed to move to the wiki, the wiki *is*
> the solution...

I only work on Mediawiki if I get paid for it. It's a horrible ... thingy.
Especially the Semantic Mediawiki extensions are something amazingly insane.
(I still babysit a SMW install with ~25k articles, it's so full of race 
condition and glitches that it'd be a great story to scare kids)

If it were something sane it'd be a lot easier to get near it (and not wait 
5-20sec on each pageload)

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Matthew Thode]

On 12/28/2014 10:45 AM, Andreas K. Huettel wrote:
> Am Sonntag, 28. Dezember 2014, 12:57:16 schrieb Michał Górny:
>>
>> We should also finally decide on a clear way of knowing who's on
>> the team. Right now wiki list seems to be the de-facto solution but
>> many developers simply don't want to get a wiki account...
> 
> Given that all project pages are supposed to move to the wiki, the wiki *is* 
> the solution...
> 
> I'm sorry, but I dont really see the point of refusing to create a wiki 
> account. That's a bit like not committing anything because you don't like cvs.
> 

I'd like to see us use something that can be used in more places.
having the source of info be in the wiki seems good for end users, but
bad for using that info programmaticly (if needed).  Something like ldap
groups that feed into the wiki (and anywhere else needed) seems more
usable to me (but more upfront work).

-- 
-- Matthew Thode (prometheanfire)

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Andreas K. Huettel]

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

Am Montag, 29. Dezember 2014, 21:57:44 schrieb Matthew Thode:
> On 12/28/2014 10:45 AM, Andreas K. Huettel wrote:
> > Am Sonntag, 28. Dezember 2014, 12:57:16 schrieb Michał Górny:
> >> We should also finally decide on a clear way of knowing who's on
> >> the team. Right now wiki list seems to be the de-facto solution but
> >> many developers simply don't want to get a wiki account...
> > 
> > Given that all project pages are supposed to move to the wiki, the wiki
> > *is* the solution...
> > 
> > I'm sorry, but I dont really see the point of refusing to create a wiki
> > account. That's a bit like not committing anything because you don't like
> > cvs.
> 
> I'd like to see us use something that can be used in more places.
> having the source of info be in the wiki seems good for end users, but
> bad for using that info programmaticly (if needed).  Something like ldap
> groups that feed into the wiki (and anywhere else needed) seems more
> usable to me (but more upfront work).

As far as I know there are plans for that, around api.gentoo.org (but anyone 
from infra might be better qualified to answer).

-- 
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: 819 bytes --]

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Alex Legler]

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

On 12/29/14 at 9:57 PM, Matthew Thode wote:
> On 12/28/2014 10:45 AM, Andreas K. Huettel wrote:
>> Am Sonntag, 28. Dezember 2014, 12:57:16 schrieb Michał Górny:
>>>
>>> We should also finally decide on a clear way of knowing who's on
>>> the team. Right now wiki list seems to be the de-facto solution but
>>> many developers simply don't want to get a wiki account...
>>
>> Given that all project pages are supposed to move to the wiki, the wiki *is* 
>> the solution...
>>
>> I'm sorry, but I dont really see the point of refusing to create a wiki 
>> account. That's a bit like not committing anything because you don't like cvs.
>>
> 
> I'd like to see us use something that can be used in more places.
> having the source of info be in the wiki seems good for end users, but
> bad for using that info programmaticly (if needed).  Something like ldap
> groups that feed into the wiki (and anywhere else needed) seems more
> usable to me (but more upfront work).
> 

Project membership is stored in a machine-readable way and can already
be extracted from the wiki in (rather specific) RDF/XML. If it should be
actually needed anywhere else, I can easily generate a 'clean' version
and distribute it via api.g.o.


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

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Anthony G. Basile]

On 12/29/14 19:18, Alex Legler wrote:
> On 12/29/14 at 9:57 PM, Matthew Thode wote:
>> On 12/28/2014 10:45 AM, Andreas K. Huettel wrote:
>>> Am Sonntag, 28. Dezember 2014, 12:57:16 schrieb Michał Górny:
>>>> We should also finally decide on a clear way of knowing who's on
>>>> the team. Right now wiki list seems to be the de-facto solution but
>>>> many developers simply don't want to get a wiki account...
>>> Given that all project pages are supposed to move to the wiki, the wiki *is*
>>> the solution...
>>>
>>> I'm sorry, but I dont really see the point of refusing to create a wiki
>>> account. That's a bit like not committing anything because you don't like cvs.
>>>
>> I'd like to see us use something that can be used in more places.
>> having the source of info be in the wiki seems good for end users, but
>> bad for using that info programmaticly (if needed).  Something like ldap
>> groups that feed into the wiki (and anywhere else needed) seems more
>> usable to me (but more upfront work).
>>
> Project membership is stored in a machine-readable way and can already
> be extracted from the wiki in (rather specific) RDF/XML. If it should be
> actually needed anywhere else, I can easily generate a 'clean' version
> and distribute it via api.g.o.
>

I'd like to be able to answer the question "what teams am I on?" and 
"what teams is so-and-so on?"  This is a bit hard to answer from the 
wiki because it answers the opposite question "who is on team X".

-- 
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] Council meeting 2015-01-13: call for agenda items

[Rich Freeman]

On Tue, Dec 30, 2014 at 9:20 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>
> I'd like to be able to answer the question "what teams am I on?" and "what
> teams is so-and-so on?"  This is a bit hard to answer from the wiki because
> it answers the opposite question "who is on team X".

https://wiki.gentoo.org/wiki/User:Blueness

--
Rich

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Anthony G. Basile]

On 12/30/14 10:05, Rich Freeman wrote:
> On Tue, Dec 30, 2014 at 9:20 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> I'd like to be able to answer the question "what teams am I on?" and "what
>> teams is so-and-so on?"  This is a bit hard to answer from the wiki because
>> it answers the opposite question "who is on team X".
> https://wiki.gentoo.org/wiki/User:Blueness
>
> --
> Rich
>
So it automatically updates.  Thanks.

-- 
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] Council meeting 2015-01-13: call for agenda items

[Dean Stephens]

On 12/28/14 11:45, Andreas K. Huettel wrote:
> Am Sonntag, 28. Dezember 2014, 12:57:16 schrieb Michał Górny:
>> 
>> We should also finally decide on a clear way of knowing who's on 
>> the team. Right now wiki list seems to be the de-facto solution
>> but many developers simply don't want to get a wiki account...
> 
> Given that all project pages are supposed to move to the wiki, the
> wiki *is* the solution...
> 
> I'm sorry, but I dont really see the point of refusing to create a
> wiki account. That's a bit like not committing anything because you
> don't like cvs.
> 
That is, at very best, a fatuous argument. The wiki is for
documentation. The wiki is not for ebuild development, nor handling
ops duties in #gentoo, nor handling moderation duties on the forums,
nor doing infrastructure work, nor work on openrc, nor portage, nor
eselect, nor any of the other myriad things that people could be doing
as active members of Gentoo which do not necessarily entail writing
documentation on the wiki. Even aside from the fact that most Gentoo
repositories have migrated to git at this point, including project
overlays.

There is no evident technical reason to not have projects track their
membership in LDAP, which happens to be accessible via dev.g.o, which
people need access to in order to handle their @g.o e-mail, at least
to the extent of setting up forwarding. Doing so would remove the
purported necessity of having yet another login to keep track of for
the exclusive purpose of formally joining projects.

The current "solution" is further suboptimal in that any individuals
who take part in the project but are not formally Gentoo developers or
staff members evidently cannot be listed with the project at all,
there are at least two projects where such listings would make sense.

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[hasufell]

Anthony G. Basile:
> 
> I'd like to add a discussion on glep 39.  In particular, under
> specifications we have:
> 
> "It may have one or many leads, and the leads are selected by the
> members of the project. This selection must occur at least once every 12
> months, and may occur at any time."
> 

That requirement imposes a specific structure on projects. There are
ways to have a functional project without any lead.

So that phrase should be removed altogether.

Instead, we need a functional ComRel project and need to stop treating
some developers differently, because we do.

And this is not really a specification problem (not saying you said that).

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Rich Freeman]

On Mon, Dec 29, 2014 at 2:34 PM, hasufell <hasufell@gentoo.org> wrote:
> Anthony G. Basile:
>>
>> I'd like to add a discussion on glep 39.  In particular, under
>> specifications we have:
>>
>> "It may have one or many leads, and the leads are selected by the
>> members of the project. This selection must occur at least once every 12
>> months, and may occur at any time."
>>
>
> That requirement imposes a specific structure on projects. There are
> ways to have a functional project without any lead.
>
> So that phrase should be removed altogether.
>

I think we need to step back and think about why we have projects.
The whole point of projects is to have something in-between the
Council and anything-goes.  So, if you want to know whether doing xyz
is acceptable for Python modules, you can ask the Python project.  If
you REALLY disagree you can then complain to the Council, but they're
probably going to just side with the Python project since that is the
whole reason for having a Python project.

Well, since projects are inanimate concepts you can't actually ask
them questions - you need people to talk for them.  So, if 3 people on
the Python project say one thing, and 3 others say something else,
then what IS the opinion of the Python project?  To settle that we
have project leads.

I'll certainly agree that not everything needs a formal project.
However, if a project wants to have authority/autonomy beyond
anything-goes, then it should welcome members and elect a lead
regularly.

I think that some of what sparked this question is that some projects
are fairly non-responsive, and devs don't feel at liberty to make
commits to packages under the authority of that project.  IMHO the
simplest solution here is to tell people to just announce their
changes and go ahead and make them if there are no objections.  The
onus has to be on the person blocking change to prevent it, unless we
want to fossilize.  Of course, anybody can always go to the Council
for help, but the point isn't to micromanage every little decision
anybody wants to make.

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Matthew Thode]

On 12/29/2014 02:06 PM, Rich Freeman wrote:
> On Mon, Dec 29, 2014 at 2:34 PM, hasufell <hasufell@gentoo.org> wrote:
>> Anthony G. Basile:
>>>
>>> I'd like to add a discussion on glep 39.  In particular, under
>>> specifications we have:
>>>
>>> "It may have one or many leads, and the leads are selected by the
>>> members of the project. This selection must occur at least once every 12
>>> months, and may occur at any time."
>>>
>>
>> That requirement imposes a specific structure on projects. There are
>> ways to have a functional project without any lead.
>>
>> So that phrase should be removed altogether.
>>
> 
> I think we need to step back and think about why we have projects.
> The whole point of projects is to have something in-between the
> Council and anything-goes.  So, if you want to know whether doing xyz
> is acceptable for Python modules, you can ask the Python project.  If
> you REALLY disagree you can then complain to the Council, but they're
> probably going to just side with the Python project since that is the
> whole reason for having a Python project.
> 
> Well, since projects are inanimate concepts you can't actually ask
> them questions - you need people to talk for them.  So, if 3 people on
> the Python project say one thing, and 3 others say something else,
> then what IS the opinion of the Python project?  To settle that we
> have project leads.
> 
> I'll certainly agree that not everything needs a formal project.
> However, if a project wants to have authority/autonomy beyond
> anything-goes, then it should welcome members and elect a lead
> regularly.
> 
> I think that some of what sparked this question is that some projects
> are fairly non-responsive, and devs don't feel at liberty to make
> commits to packages under the authority of that project.  IMHO the
> simplest solution here is to tell people to just announce their
> changes and go ahead and make them if there are no objections.  The
> onus has to be on the person blocking change to prevent it, unless we
> want to fossilize.  Of course, anybody can always go to the Council
> for help, but the point isn't to micromanage every little decision
> anybody wants to make.
> 

The onus was already on them to stop a commit.  question 13 of the
second section.

http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt

I would love some sort of automatic process for doing elections though.
 I'm not the best at this (scheduling and admin work).

-- 
-- Matthew Thode (prometheanfire)

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[hasufell]

Rich Freeman:
> On Mon, Dec 29, 2014 at 2:34 PM, hasufell <hasufell@gentoo.org> wrote:
>> Anthony G. Basile:
>>>
>>> I'd like to add a discussion on glep 39.  In particular, under
>>> specifications we have:
>>>
>>> "It may have one or many leads, and the leads are selected by the
>>> members of the project. This selection must occur at least once every 12
>>> months, and may occur at any time."
>>>
>>
>> That requirement imposes a specific structure on projects. There are
>> ways to have a functional project without any lead.
>>
>> So that phrase should be removed altogether.
>>
> 
> I think we need to step back and think about why we have projects.
> The whole point of projects is to have something in-between the
> Council and anything-goes.  So, if you want to know whether doing xyz
> is acceptable for Python modules, you can ask the Python project.  If
> you REALLY disagree you can then complain to the Council, but they're
> probably going to just side with the Python project since that is the
> whole reason for having a Python project.
> 
> Well, since projects are inanimate concepts you can't actually ask
> them questions - you need people to talk for them.  So, if 3 people on
> the Python project say one thing, and 3 others say something else,
> then what IS the opinion of the Python project?  To settle that we
> have project leads.
> 

No, you don't need a project lead. You can just say any member can speak
for the whole project at any time. Whether that works or not, is a
different thing, but it's a valid model.
Decisions can be reached by whatever method you want, with or without a
lead.

What matters is that the project is _functional_ and _responsive_. How
they do that should be up to the and should not be specified anywhere.

> I think that some of what sparked this question is that some projects
> are fairly non-responsive, and devs don't feel at liberty to make
> commits to packages under the authority of that project.  IMHO the
> simplest solution here is to tell people to just announce their
> changes and go ahead and make them if there are no objections.  The
> onus has to be on the person blocking change to prevent it, unless we
> want to fossilize.  Of course, anybody can always go to the Council
> for help, but the point isn't to micromanage every little decision
> anybody wants to make.
> 

Yeah, that's your diplomatic approach, but it doesn't work.

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Rich Freeman]

On Mon, Dec 29, 2014 at 9:22 PM, hasufell <hasufell@gentoo.org> wrote:
>
> No, you don't need a project lead. You can just say any member can speak
> for the whole project at any time. Whether that works or not, is a
> different thing, but it's a valid model.
> Decisions can be reached by whatever method you want, with or without a
> lead.
>
> What matters is that the project is _functional_ and _responsive_. How
> they do that should be up to the and should not be specified anywhere.
>

Well, as long as everybody agrees there is no need for rules.  The
rules come into play when people disagree.  Nobody is suggesting that
project members can't just speak for the project if that is how the
project wants to operate.  However, when there is disagreement then it
makes sense to allow an elected lead to step in, otherwise everybody
is just going to appeal to the council, which is after all intended to
be the escalation path for stuff projects can't handle on their own.
I'm sure the Council members don't want to be stepping into every
little debate, and I'm even more sure that everybody else doesn't want
that either.

I think some kind of standardization is useful just so that people
know how to engage projects.  However, if we want to have projects
specify their own engagement/escalation models I don't have a problem
with that.  Of course, if the project can't bother to elect a lead,
I'd be shocked if they actually reached a formal consensus on some
other governance model.

I don't think anybody wants to increase the level of formality.

--
Rich

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Dean Stephens]

On 12/29/14 15:06, Rich Freeman wrote:
> I'll certainly agree that not everything needs a formal project.
> However, if a project wants to have authority/autonomy beyond
> anything-goes, then it should welcome members and elect a lead
> regularly.
> 
There is at least a defensible argument to be made that being able to
reject applicants is more important to being able to maintain a coherent
project than the often indicated duty to accept anyone who shows interest.

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Ciaran McCreesh]

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

On Tue, 30 Dec 2014 00:00:04 -0500
Dean Stephens <desultory@gentoo.org> wrote:
> On 12/29/14 15:06, Rich Freeman wrote:
> > I'll certainly agree that not everything needs a formal project.
> > However, if a project wants to have authority/autonomy beyond
> > anything-goes, then it should welcome members and elect a lead
> > regularly.
> > 
> There is at least a defensible argument to be made that being able to
> reject applicants is more important to being able to maintain a
> coherent project than the often indicated duty to accept anyone who
> shows interest.

But Gentoo is primarily about the Community, not the quality of the
product. Requiring technical ability discourages contributions, and a
lack of bugs decreases the volume of forum posts, so they are
poisonous to the Community.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Rich Freeman]

On Tue, Dec 30, 2014 at 3:28 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Tue, 30 Dec 2014 00:00:04 -0500
> Dean Stephens <desultory@gentoo.org> wrote:
>> On 12/29/14 15:06, Rich Freeman wrote:
>> > I'll certainly agree that not everything needs a formal project.
>> > However, if a project wants to have authority/autonomy beyond
>> > anything-goes, then it should welcome members and elect a lead
>> > regularly.
>> >
>> There is at least a defensible argument to be made that being able to
>> reject applicants is more important to being able to maintain a
>> coherent project than the often indicated duty to accept anyone who
>> shows interest.
>
> But Gentoo is primarily about the Community, not the quality of the
> product. Requiring technical ability discourages contributions, and a
> lack of bugs decreases the volume of forum posts, so they are
> poisonous to the Community.

I'll leave it as an exercise to the casual reader of this thread to
judge what kinds of behavior are poisonous to the community.

In any case, if a project is actively rejecting applicants I'd say
that this would make it far more alive than the typical Gentoo project
from the complaints I've been hearing.  Part of me suspects that we've
gotten so good at ticking each other off that most of us just retreat
into our private interests and just do what we want to do until we
step on enough toes that we lose our commit rights.  You can't have
"quality of the product" if nobody is interested in actually working
on a "product" as opposed to a few random components that can be used
to build a product if people are willing to deal with the integration
issues, especially when things like creating documentation apparently
aren't essential to doing development, so it would just KILL us to
have to create a wiki account.

Since most of us don't have the time to completely build a
self-contained Linux distro on our own, we're left with the
apparently-unenviable task of working with other people to accomplish
this.  I'm all for making this as painless as possible, but I'm not
entirely convinced that going along with pleas like "do I HAVE to read
mailing lists" or "do I HAVE to let somebody co-maintain MY package or
join MY team" or "why CAN'T I get into a revert-war with somebody who
wants to add a feature to MY package that I don't personally use" is
really going to lead to the sort of distro that any of us actually
want to use.

If dealing with this kind of stuff seems unpleasant to you, take some
comfort in the fact that it isn't any more pleasant for the rest of
us.  :)

--
Rich

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[hasufell]

Dean Stephens:
> On 12/29/14 15:06, Rich Freeman wrote:
>> I'll certainly agree that not everything needs a formal project.
>> However, if a project wants to have authority/autonomy beyond
>> anything-goes, then it should welcome members and elect a lead
>> regularly.
>>
> There is at least a defensible argument to be made that being able to
> reject applicants is more important to being able to maintain a coherent
> project than the often indicated duty to accept anyone who shows interest.
> 

What about projects that don't even reject, but rather ignore
devs/contributors?

We tell them to elect a new lead, so we don't have to deal with the
people who screwed up, but can say "here, they formally are a functional
project according to a random glep... problem solved".

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Rich Freeman]

On Tue, Dec 30, 2014 at 9:25 AM, hasufell <hasufell@gentoo.org> wrote:
> Dean Stephens:
>> On 12/29/14 15:06, Rich Freeman wrote:
>>> I'll certainly agree that not everything needs a formal project.
>>> However, if a project wants to have authority/autonomy beyond
>>> anything-goes, then it should welcome members and elect a lead
>>> regularly.
>>>
>> There is at least a defensible argument to be made that being able to
>> reject applicants is more important to being able to maintain a coherent
>> project than the often indicated duty to accept anyone who shows interest.
>>
>
> What about projects that don't even reject, but rather ignore
> devs/contributors?
>
> We tell them to elect a new lead, so we don't have to deal with the
> people who screwed up, but can say "here, they formally are a functional
> project according to a random glep... problem solved".
>

Keep in mind that rules don't exist to justify bad behavior, but to
promote good behavior.

I can guarantee that whatever rules come out of the council meeting
are going to have some loophole that somebody can point to in order to
justify their idiotic behavior.

We should be aiming for a GLEP that promotes a reasonable way for
projects to govern themselves without a lot of unnecessary
overhead/etc.  If somebody wants to contribute to a project and feels
that they can't, they should just ask for help.  I don't want to
burden every group in Gentoo that gets along just fine because some
projects aren't that way.

Really, though, it seems like the biggest complaint is AWOL project
leads or members.  I suggest that the simplest solution in such a case
is for somebody to step up and be bold.  Just send out an email to the
alias announcing that they added themselves to the alias (non-devs can
ask somebody to help out with that), call meetings to discuss things
that are important, and so on.  If not having an active person in
charge is detrimental then the team can just organize an election.
Leadership is more than titles.  FOSS tends to be do-acracy, so if
you're trying to do something you probably have more power than you
realize.

--
Rich

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[hasufell]

Rich Freeman:
> 
> Really, though, it seems like the biggest complaint is AWOL project
> leads or members.

I don't think that's the biggest complaint. Unless you like in-tree
revert-wars (ask patrick about it), bugzilla-wars (ask diego about it)
and alienated users and devs we have to have a minimum of consensus and
communication.

If people don't answer e-mails, IRC pings, don't care about important
discussions (e.g. eclasses) and close valid bug reports, but STILL do a
lot of work themselves (which is the important point), then it doesn't
matter how much you do or want to do. It will just fail.

The lack of some functional projects is just a side effect of the fact,
that this behavior is tolerated. And you cannot make it go away with a GLEP.

Discussing the GLEP is effectively just downplaying the issue and hoping
that people will stop caring (most already do) and won't start forking.

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Dean Stephens]

On 12/30/14 09:25, hasufell wrote:
> Dean Stephens:
>> On 12/29/14 15:06, Rich Freeman wrote:
>>> I'll certainly agree that not everything needs a formal project.
>>> However, if a project wants to have authority/autonomy beyond
>>> anything-goes, then it should welcome members and elect a lead
>>> regularly.
>>>
>> There is at least a defensible argument to be made that being able to
>> reject applicants is more important to being able to maintain a coherent
>> project than the often indicated duty to accept anyone who shows interest.
>>
> 
> What about projects that don't even reject, but rather ignore
> devs/contributors?
> 
If they have a maintained project page, have elected a lead in the past
12 months, and that lead is otherwise active; take it for what it is:
rejection [1]. Otherwise, they either need to elect a new lead or allow
the project to dissolve, according to GLEP 39 [2].

> We tell them to elect a new lead, so we don't have to deal with the
> people who screwed up, but can say "here, they formally are a functional
> project according to a random glep... problem solved".
> 
> 
So, the document specifying the organizational structure of Gentoo as a
whole [2, again] is just "a random glep" now? Is anyone supposed to take
that rhetoric seriously or were you attempting to use humor? Either make
a concrete proposal to update or entirely supersede the existing project
structure or work within it, merely complaining about it is pointless.

[1] http://en.wikipedia.org/wiki/Pocket_veto
[2] http://wiki.gentoo.org/wiki/GLEP:39

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[hasufell]

Dean Stephens:
> On 12/30/14 09:25, hasufell wrote:
>> Dean Stephens:
>>> On 12/29/14 15:06, Rich Freeman wrote:
>>>> I'll certainly agree that not everything needs a formal project.
>>>> However, if a project wants to have authority/autonomy beyond
>>>> anything-goes, then it should welcome members and elect a lead
>>>> regularly.
>>>>
>>> There is at least a defensible argument to be made that being able to
>>> reject applicants is more important to being able to maintain a coherent
>>> project than the often indicated duty to accept anyone who shows interest.
>>>
>>
>> What about projects that don't even reject, but rather ignore
>> devs/contributors?
>>
> If they have a maintained project page, have elected a lead in the past
> 12 months, and that lead is otherwise active; take it for what it is:
> rejection [1]. Otherwise, they either need to elect a new lead or allow
> the project to dissolve, according to GLEP 39 [2].
> 
>> We tell them to elect a new lead, so we don't have to deal with the
>> people who screwed up, but can say "here, they formally are a functional
>> project according to a random glep... problem solved".
>>
>>
> So, the document specifying the organizational structure of Gentoo as a
> whole [2, again] is just "a random glep" now? Is anyone supposed to take
> that rhetoric seriously or were you attempting to use humor? Either make
> a concrete proposal to update or entirely supersede the existing project
> structure or work within it, merely complaining about it is pointless.
> 

You did not get the point. The point is that the problem is not the GLEP
in the first place. By forging just the GLEP, you will not get the
problem solved.

And I have been very specific indeed.

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Dean Stephens]

On 01/04/15 18:27, hasufell wrote:
> Dean Stephens:
>> On 12/30/14 09:25, hasufell wrote:
>>> Dean Stephens:
>>>> On 12/29/14 15:06, Rich Freeman wrote:
>>>>> I'll certainly agree that not everything needs a formal project.
>>>>> However, if a project wants to have authority/autonomy beyond
>>>>> anything-goes, then it should welcome members and elect a lead
>>>>> regularly.
>>>>>
>>>> There is at least a defensible argument to be made that being able to
>>>> reject applicants is more important to being able to maintain a coherent
>>>> project than the often indicated duty to accept anyone who shows interest.
>>>>
>>>
>>> What about projects that don't even reject, but rather ignore
>>> devs/contributors?
>>>
>> If they have a maintained project page, have elected a lead in the past
>> 12 months, and that lead is otherwise active; take it for what it is:
>> rejection [1]. Otherwise, they either need to elect a new lead or allow
>> the project to dissolve, according to GLEP 39 [2].
>>
>>> We tell them to elect a new lead, so we don't have to deal with the
>>> people who screwed up, but can say "here, they formally are a functional
>>> project according to a random glep... problem solved".
>>>
>>>
>> So, the document specifying the organizational structure of Gentoo as a
>> whole [2, again] is just "a random glep" now? Is anyone supposed to take
>> that rhetoric seriously or were you attempting to use humor? Either make
>> a concrete proposal to update or entirely supersede the existing project
>> structure or work within it, merely complaining about it is pointless.
>>
> 
> You did not get the point. The point is that the problem is not the GLEP
> in the first place. By forging just the GLEP, you will not get the
> problem solved.
> 
Are you then proposing that some entity enforce GLEP 39 constraints?
(Hint: a mechanism already exists for that.)
Are you proposing that those constraints be relaxed in some specific way?
If so, under what conditions?
If a project has no leads, who is responsible for maintaining project
roll call?
If nobody is tasked with keeping the roll call up to date, as much as
possible given technical constraints, how can a project page be
determined to be definitely out of date?
If there are no constraints with regard to a project page being kept up
to date and no need for project leads for anything at all, what are your
new constraints for a project to be considered active?
Am I to keep guessing until you deign to reveal something resembling a
proposal?

If this is all still about your witch hunt, do kindly consider the
pocket veto article[1] I had referred you to earlier, it applies. Not
everyone is necessarily going to want to work with everyone else,
especially when there is negative personal history or indications that
the prospective newcomer, to whatever role, is ill suited to that role
to consider. Even if it is merely a matter of disinterest, if a project
lead does not want to work with you, trying to force them to will only
end badly.

> And I have been very specific indeed.
> 
> 
Where, pray tell?

The closest that you appear to have come to a concrete suggestion in
this entire discussion is "No, you don't need a project lead. You can
just say any member can speak for the whole project at any time."
Is that supposed to be across Gentoo as a whole?
If so, what about teams that actually want a designated external
interface or technical decision maker? Are they just to individually
reply "ask the person we decided to fill the role of lead, but we can't
call them that because hasufell didn't like the terminology"?
If not, how, exactly is that decision to be formally reached, and
published, so that other projects can know that that is actually the
intended interface for a given project?
What about rescinding that decision?
Is publishing it in their project pages enough?

A the moment what, exactly, is stopping a project from electing every
member as a co-lead, or a figurehead lead who leaves a note in their
project page that anyone in the project can respond to anything for the
project as a whole? (Nothing, in case you were wondering.) How would
that functionally differ from what you have so vaguely suggested so far?
(It wouldn't.)

In short: what exactly are you proposing and could it be done without
adding new rules?

[1] http://en.wikipedia.org/wiki/Pocket_veto

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[hasufell]

Dean Stephens:
> On 01/04/15 18:27, hasufell wrote:
>> Dean Stephens:
>>> On 12/30/14 09:25, hasufell wrote:
>>>> Dean Stephens:
>>>>> On 12/29/14 15:06, Rich Freeman wrote:
>>>>>> I'll certainly agree that not everything needs a formal project.
>>>>>> However, if a project wants to have authority/autonomy beyond
>>>>>> anything-goes, then it should welcome members and elect a lead
>>>>>> regularly.
>>>>>>
>>>>> There is at least a defensible argument to be made that being able to
>>>>> reject applicants is more important to being able to maintain a coherent
>>>>> project than the often indicated duty to accept anyone who shows interest.
>>>>>
>>>>
>>>> What about projects that don't even reject, but rather ignore
>>>> devs/contributors?
>>>>
>>> If they have a maintained project page, have elected a lead in the past
>>> 12 months, and that lead is otherwise active; take it for what it is:
>>> rejection [1]. Otherwise, they either need to elect a new lead or allow
>>> the project to dissolve, according to GLEP 39 [2].
>>>
>>>> We tell them to elect a new lead, so we don't have to deal with the
>>>> people who screwed up, but can say "here, they formally are a functional
>>>> project according to a random glep... problem solved".
>>>>
>>>>
>>> So, the document specifying the organizational structure of Gentoo as a
>>> whole [2, again] is just "a random glep" now? Is anyone supposed to take
>>> that rhetoric seriously or were you attempting to use humor? Either make
>>> a concrete proposal to update or entirely supersede the existing project
>>> structure or work within it, merely complaining about it is pointless.
>>>
>>
>> You did not get the point. The point is that the problem is not the GLEP
>> in the first place. By forging just the GLEP, you will not get the
>> problem solved.
>>
> Are you then proposing that some entity enforce GLEP 39 constraints?
> (Hint: a mechanism already exists for that.)
> Are you proposing that those constraints be relaxed in some specific way?
> If so, under what conditions?
> If a project has no leads, who is responsible for maintaining project
> roll call?
> If nobody is tasked with keeping the roll call up to date, as much as
> possible given technical constraints, how can a project page be
> determined to be definitely out of date?
> If there are no constraints with regard to a project page being kept up
> to date and no need for project leads for anything at all, what are your
> new constraints for a project to be considered active?
> Am I to keep guessing until you deign to reveal something resembling a
> proposal?

I said earlier in this thread that it's a cultural problem (in some
degree also a technical, but not as much as people think and I think
some people try to downplay it to just the technical level).

Rich said that "FOSS tends to be do-acracy", but do-acracy doesn't say
if the project is open to collaboration. Such projects usually end up
being a one-man project (we already have those and this thread is
exactly about them). Do we want gentoo as a whole to be a one-man
project again?

> 
> If this is all still about your witch hunt, do kindly consider the
> pocket veto article[1] I had referred you to earlier, it applies. Not
> everyone is necessarily going to want to work with everyone else,
> especially when there is negative personal history or indications that
> the prospective newcomer, to whatever role, is ill suited to that role
> to consider. Even if it is merely a matter of disinterest, if a project
> lead does not want to work with you, trying to force them to will only
> end badly.
> 

You again miss the point and ignore the fact that the council has
already agreed that SEVERAL (I'm not just talking about one) projects
are non-functional in the recent past.
It's not just about not responding to membership applications (which is
NOT a rejection) which has happened to several gentoo devs and had to be
fixed by the council.
It's about being non-collaborative in the sense of
* almost never responding to users
* barely responding to gentoo devs (not just me, even if you think that)
* sometimes not reviewing (I am serious and can give several examples)
ebuild/eclass proposals at all (and don't tell me not reviewing
something is a rejection)
* not keeping a project functional in so many ways that it has to be
brought up to the council (this shouldn't happen... we have
theoretically two projects before this instance: undertakers and ComRel,
but both seem to think it's not within their scope)

If you think this is something about a personal vendetta, then you
didn't follow the project ML in the last few months. It's not even about
a single person.

It's about do-acracy and the fact that it doesn't work without a
collaboration model AND mindest.

And yes... collaboration is also "no, we won't do it that way" or "no,
we do it differently". But it's not about "i don't give two shits what
bonsaikitten thinks" (some users get ComReld for saying similar things
on bugzilla... but if you have enough commits in gx86...)

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Dean Stephens]

On 01/05/15 09:06, hasufell wrote:
> Dean Stephens:
>> Are you then proposing that some entity enforce GLEP 39 constraints?
>> (Hint: a mechanism already exists for that.)
>> Are you proposing that those constraints be relaxed in some specific way?
>> If so, under what conditions?
>> If a project has no leads, who is responsible for maintaining project
>> roll call?
>> If nobody is tasked with keeping the roll call up to date, as much as
>> possible given technical constraints, how can a project page be
>> determined to be definitely out of date?
>> If there are no constraints with regard to a project page being kept up
>> to date and no need for project leads for anything at all, what are your
>> new constraints for a project to be considered active?
>> Am I to keep guessing until you deign to reveal something resembling a
>> proposal?
> 
> I said earlier in this thread that it's a cultural problem (in some
> degree also a technical, but not as much as people think and I think
> some people try to downplay it to just the technical level).
> 
> Rich said that "FOSS tends to be do-acracy", but do-acracy doesn't say
> if the project is open to collaboration. Such projects usually end up
> being a one-man project (we already have those and this thread is
> exactly about them). Do we want gentoo as a whole to be a one-man
> project again?
> 
Reductio ad absurdum is itself absurd here, unless you actually have
some examples of projects with a single developer who is refusing
qualified applicants with whom they can maintain functional collaboration.

Do "we" want to force people to work with anyone and everyone who claims
any interest, regardless of technical and social mismatches between
them? Regardless of whether their professed interest is beneficial to
the goals of the project at hand?

>> If this is all still about your witch hunt, do kindly consider the
>> pocket veto article[1] I had referred you to earlier, it applies. Not
>> everyone is necessarily going to want to work with everyone else,
>> especially when there is negative personal history or indications that
>> the prospective newcomer, to whatever role, is ill suited to that role
>> to consider. Even if it is merely a matter of disinterest, if a project
>> lead does not want to work with you, trying to force them to will only
>> end badly.
>>
> 
> You again miss the point and ignore the fact that the council has
> already agreed that SEVERAL (I'm not just talking about one) projects
> are non-functional in the recent past.
And you mistake asking you to make your point for missing what you have
actually conveyed so far.

Let us review these council findings. What follows is a list of Council
meeting summaries for all votes regarding standing projects in the past
two years.

QA disbanded:
http://www.gentoo.org/proj/en/council/meeting-logs/20131112-summary.txt

Kolab, GSE and Gentoo/Alt AT disbanded:
http://www.gentoo.org/proj/en/council/meeting-logs/20131119-summary.txt

Regarding the operational scope of the new QA team:
http://www.gentoo.org/proj/en/council/meeting-logs/20131210-summary.txt

An effectively null mention of the functional scope of QA, no summary:
http://www.gentoo.org/proj/en/council/meeting-logs/20140225.txt

Regarding games team work flow and scope, not its validity as a project:
http://www.gentoo.org/proj/en/council/meeting-logs/20140812-summary.txt

Regarding games team, again not finding against it as a project:
http://www.gentoo.org/proj/en/council/meeting-logs/20141021-summary.txt

Another effectively null vote regarding the games team:
http://www.gentoo.org/proj/en/council/meeting-logs/20141111-summary.txt

With no meeting log nor summary yet posted for the 2014-12-09 meeting.

In summary, no projects have been found to be "non-functional" in over a
year, none. Prior to that, one active project was forcibly disbanded and
three seemingly inactive projects were dissolved.

Calling votes taken over a year ago "recent" seems somewhat pushing
terminology, especially given your rather emphatic usage of several,
which apparently related only to inactive projects.

Even aside from it being rather sad that you knew exactly what was meant
by "your witch hunt", which implies that you recognize on some level
that it at least appears to others to be exactly that.

> It's not just about not responding to membership applications (which is
> NOT a rejection) which has happened to several gentoo devs and had to be
> fixed by the council.
It is certainly not acceptance, unless they silently add the applicant
to their project page, IRC channel(s) (if applicable), and any relevant
restricted access repositories; as such basic logic implies that what is
not acceptance is not acceptance. One might even call that a tautology.

> It's about being non-collaborative in the sense of
> * almost never responding to users
> * barely responding to gentoo devs (not just me, even if you think that)
> * sometimes not reviewing (I am serious and can give several examples)
> ebuild/eclass proposals at all (and don't tell me not reviewing
> something is a rejection)
> * not keeping a project functional in so many ways that it has to be
> brought up to the council (this shouldn't happen... we have
> theoretically two projects before this instance: undertakers and ComRel,
> but both seem to think it's not within their scope)
> 
Now that you have a problem statement that is not in the form of "the
problem is not X", you are half way to making a proposal.

> If you think this is something about a personal vendetta, then you
> didn't follow the project ML in the last few months. It's not even about
> a single person.
> 
Actually, following this mailing list and gentoo-dev is in large part
why I have the distinct impression that a personal problem is precisely
what is driving your call for still ill-defined reform.

> It's about do-acracy and the fact that it doesn't work without a
> collaboration model AND mindest.
> 
What are you actually proposing?

> And yes... collaboration is also "no, we won't do it that way" or "no,
> we do it differently". But it's not about "i don't give two shits what
> bonsaikitten thinks" (some users get ComReld for saying similar things
> on bugzilla... but if you have enough commits in gx86...)
> 
> 

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Rich Freeman]

On Sat, Dec 27, 2014 at 7:34 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
>
> For proposing agenda items and discussion of these, please reply to this mail
> on the gentoo-project mailing list.
>

I think that it is probably worth discussing what the right policy
should be around allowing masked packages to remain in the tree (if
they have a maintainer).  This would include packages with documented
security flaws in the mask message, but it could also include other
kinds of flaws.  If the maintainer wants to keep them around, should
they be permitted to?  Are there any conditions on this, or is it
maintainer-preference as long as it stays masked?

See:
http://article.gmane.org/gmane.linux.gentoo.devel/94200
http://article.gmane.org/gmane.linux.gentoo.devel/94199

-- 
Rich

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[William Hubbs]

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

On Wed, Jan 07, 2015 at 08:03:04AM -0500, Rich Freeman wrote:
> On Sat, Dec 27, 2014 at 7:34 AM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
> >
> > For proposing agenda items and discussion of these, please reply to this mail
> > on the gentoo-project mailing list.
> >
> 
> I think that it is probably worth discussing what the right policy
> should be around allowing masked packages to remain in the tree (if
> they have a maintainer).  This would include packages with documented
> security flaws in the mask message, but it could also include other
> kinds of flaws.  If the maintainer wants to keep them around, should
> they be permitted to?  Are there any conditions on this, or is it
> maintainer-preference as long as it stays masked?
> 
> See:
> http://article.gmane.org/gmane.linux.gentoo.devel/94200
> http://article.gmane.org/gmane.linux.gentoo.devel/94199

(qa hat firmly in place)

I gave people several weeks to respond to the last rites and discuss
which packages should be kept. I will adjust my list based on their
responses.

That's the whole point of a last rites, to get people to step up and
take responsibility for packages. Also, this was cleared with the qa
lead before it was ever sent out.

So I am operating clearly within the scope of qa, since the job of QA is
to keep the tree in a consistent state for our users.

So with all respect, I don't understand why this even needs to be
escalated to the council.

Thanks,

William


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

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Rich Freeman]

On Wed, Jan 7, 2015 at 11:30 AM, William Hubbs <williamh@gentoo.org> wrote:
> That's the whole point of a last rites, to get people to step up and
> take responsibility for packages. Also, this was cleared with the qa
> lead before it was ever sent out.

Define "take responsibility for packages."  As far as I'm aware there
is no policy that requires maintainers to fix any upstream bug, and
security issues are almost always upstream bugs.

A package with a security bug for 10 years could be perfectly
well-maintained, with regular updates/etc as often as upstream
publishes them.  Some software projects are fairly mature and don't
get a lot of upstream updates, so a package might be untouched for 5
years and have security issues and still be "well-maintained."

I think the solution to this is to have the community agree on just
what "well-maintained" actually means and documenting this as policy,
versus just making individual judgment calls.  To be sure there will
still be grey areas, but I think that right now the policies are too
vague to try to enforce something like this.

>
> So I am operating clearly within the scope of qa, since the job of QA is
> to keep the tree in a consistent state for our users.
>
> So with all respect, I don't understand why this even needs to be
> escalated to the council.

There are many who would probably say that the tree is already in a
consistent state for our users.  I realize that you feel otherwise,
and perhaps others in QA also feel otherwise.  Maybe the vast majority
of the community would agree with you, but the whole reason for this
discussion and putting this on the Council agenda is so that we can
can get a sense for what the community wants and then consistently
follow that as policy.

It makes far more sense to deal with general policy issues like this
before we start treecleaning than to just leave it up to QA, have
users switching to overlays, and then have it appealed to the council
and potentially have everything re-introduced to the main tree.

-- 
Rich

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[William Hubbs]

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

On Wed, Jan 07, 2015 at 12:45:07PM -0500, Rich Freeman wrote:
> On Wed, Jan 7, 2015 at 11:30 AM, William Hubbs <williamh@gentoo.org> wrote:
> > That's the whole point of a last rites, to get people to step up and
> > take responsibility for packages. Also, this was cleared with the qa
> > lead before it was ever sent out.
> 
> Define "take responsibility for packages."  As far as I'm aware there
> is no policy that requires maintainers to fix any upstream bug, and
> security issues are almost always upstream bugs.

You're right, there isn't a requirement for us to fix upstream bugs, and
there shouldn't be.

> 
> A package with a security bug for 10 years could be perfectly
> well-maintained, with regular updates/etc as often as upstream
> publishes them.  Some software projects are fairly mature and don't
> get a lot of upstream updates, so a package might be untouched for 5
> years and have security issues and still be "well-maintained."
> 
> I think the solution to this is to have the community agree on just
> what "well-maintained" actually means and documenting this as policy,
> versus just making individual judgment calls.  To be sure there will
> still be grey areas, but I think that right now the policies are too
> vague to try to enforce something like this.

Based on our conversation on irc, what about this -- this is really
about information in package.mask.

If we want to keep proprietary packages with security issues in the
tree, they should be marked as proprietary in package.mask so it is
obvious that they will never be fixed.

If there is an upstream security issue with a non-proprietary
package:

When a version or revision with the fix is available, it should be
fast stabled.  Once that is done, all older versions should be removed
if possible.  if this is not possible right away, the older versions
should go in p.mask with a removal date.

Thoughts?

William


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

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[Andrew Savchenko]

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

Hello,

On Wed, 7 Jan 2015 13:35:17 -0600 William Hubbs wrote:
> If we want to keep proprietary packages with security issues in the
> tree, they should be marked as proprietary in package.mask so it is
> obvious that they will never be fixed.
> 
> If there is an upstream security issue with a non-proprietary
> package:
> 
> When a version or revision with the fix is available, it should be
> fast stabled.  Once that is done, all older versions should be removed
> if possible.  if this is not possible right away, the older versions
> should go in p.mask with a removal date.
> 
> Thoughts?

What about open source packages with no fixes or where doesn't
consider bug as a security issue? Good example is
games-roguelike/nethack, bug 125902, where upstream doesn't
consider issue as a security problem and for many setups (e.g.
personal device with single user is the games group) this is not a
problem at all?

IMO packages (not specific versions, but whole packages) should not
be removed if they work. Maybe masked, but no more.

Best regards,
Andrew Savchenko

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

Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items

[William Hubbs]

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

On Thu, Jan 08, 2015 at 12:21:18AM +0300, Andrew Savchenko wrote:
> Hello,
> 
> On Wed, 7 Jan 2015 13:35:17 -0600 William Hubbs wrote:
> > If we want to keep proprietary packages with security issues in the
> > tree, they should be marked as proprietary in package.mask so it is
> > obvious that they will never be fixed.
> > 
> > If there is an upstream security issue with a non-proprietary
> > package:
> > 
> > When a version or revision with the fix is available, it should be
> > fast stabled.  Once that is done, all older versions should be removed
> > if possible.  if this is not possible right away, the older versions
> > should go in p.mask with a removal date.
> > 
> > Thoughts?
> 
> What about open source packages with no fixes or where doesn't
> consider bug as a security issue? Good example is
> games-roguelike/nethack, bug 125902, where upstream doesn't
> consider issue as a security problem and for many setups (e.g.
> personal device with single user is the games group) this is not a
> problem at all?
 
I just read through this bug, and I see it the same way most people who
posted to the bug see it. It is a major flaw in how our games policies
were designed. Since it is known that we are moving toward getting rid
of games.eclass, and this is a popular game, whoever takes over
maintenance should make fixing this a high priority.

If I were taking over this game, I would immediately look into rewriting
the ebuild to not use games.eclass.

> IMO packages (not specific versions, but whole packages) should not
> be removed if they work. Maybe masked, but no more.

The problem is that defining "work" is too vague. I would rather not see
something like this statement made into a distro-wide policy.

William

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