[gentoo-project] Call for agenda items - Council meeting 2013-09-10

[gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Ulrich Mueller]

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

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 message with agenda items. Do not hesitate to
repeat your agenda item here with a pointer if you previously
suggested one (since the last meeting).

The agenda for the next meeting will be sent out on Tuesday 2013-09-03.

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

Ulrich

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

[gentoo-project] Re: Call for agenda items - Council meeting 2013-09-10

[Ulrich Mueller]

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

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

I'd like to ask the council to perform two votes about behaviour of
install functions and about default src_install(). This arises from
bug 481664, see the long discussion there [1].

In a nutshell: The default src_install() implementation in EAPIs 4
and 5 is flawed because it doesn't account for the DOCS variable being
defined but empty. It ends up calling dodoc without any arguments in
this case. This will work in Portage (with a QA warning), but the
stricter implementation in Paludis will error out.

1. I propose that we clarify PMS wording to say that the do*() install
   functions take one or filenames as arguments [2]. This would match
   established behaviour of all package managers.

2. There is consensus that default src_install should be fixed in the
   next EAPI. The question is if we should retroactively change the
   specification [3]. Effectively, that wouldn't change Portage
   behaviour much (only suppress a QA warning), because it doesn't
   make any difference if checking for empty DOCS takes place in dodoc
   or in the caller. OTOH, it turns out that no ebuild is directly
   affected by the flaw in the package manager function (only
   indirectly, because the PM's implementation was copied to some
   eclasses). So maybe this change is not so urgent.

To summarise the timeline of events so far:
- Long-time Portage behaviour is that do* functions error out when
  called with no arguments.
- PMS has documented this Portage behaviour, but wording isn't very
  clear for the issue at hand.
- Other package managers also follow the Portage implementation.
- EAPI 4 has introduced a default src_install function. The function
  doesn't account for empty DOCS.
- Subsequently, the EAPI 4 default was copied to src_install of a few
  eclasses (e.g., multilib-minimal.eclass).
- Portage was then changed to allow dodoc with no arguments [4].
  Other do* functions keep their strict behaviour, though.
- Some ebuilds started setting empty DOCS. This succeeds with Portage,
  but fails with other package managers. Bug 480892 was filed.
- Recently, a QA warning was added to dodoc in Portage [5], so that
  ebuilds using empty DOCS can be spotted and fixed.

Ulrich

[1] https://bugs.gentoo.org/show_bug.cgi?id=481664
[2] http://article.gmane.org/gmane.linux.gentoo.pms/764
[3] http://article.gmane.org/gmane.linux.gentoo.pms/765
[4] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6271cfe43dcf0cb42d4c2c0b772a7be17be78d2f
[5] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=83ac345bb227dc1752a895d53037fce36c9c7966

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

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-09-10

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27/08/13 05:59 AM, Ulrich Mueller wrote:
> In a nutshell: The default src_install() implementation in EAPIs 4
>  and 5 is flawed because it doesn't account for the DOCS variable 
> being defined but empty. It ends up calling dodoc without any 
> arguments in this case. This will work in Portage (with a QA 
> warning), but the stricter implementation in Paludis will error 
> out.
> 
> 2. There is consensus that default src_install should be fixed in 
> the next EAPI. The question is if we should retroactively change 
> the specification [3].

(Replying to original list -- are we supposed to move these
discussions to -dev@ ??)

It's unfortunate that this bug is there (DOCS must always have a value
in the default src_install, whether it be set by the default phase or
in the ebuild), but I don't think we can just retroactively fix
EAPI4/5 to do it without consensus from all of the PM implementation
upstreams.  Inviting them all to the council meeting to seek their
approval is always a possibility, of course.

It would probably be best to just enforce workarounds in eclasses and
remove the empty/null assignments in ebuilds, and make sure the spec
(and therefore PMs) are fixed to allow empty DOCS in EAPI6 and above.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlIctJAACgkQ2ugaI38ACPBrKwD9HKGj9mZLrHmK9OlBkwngp20M
l2CVE+X5l9bFCK4g0KUA/3FT6+h0sb3UrW+eK+/mvTBabLIbgIrFV+rgjfZhjprc
=c7bt
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-09-10

[Michał Górny]

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

Dnia 2013-08-27, o godz. 11:59:42
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> > 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.
> 
> I'd like to ask the council to perform two votes about behaviour of
> install functions and about default src_install(). This arises from
> bug 481664, see the long discussion there [1].

I would like to expand this a bit. I would like the Council to take
a preliminary vote on the EAPI 6 einstalldocs feature and its
reference implementation [1].

Since, as ulm mentioned, we have a live issue here, I'd like to
'backport' the feature from EAPI 6 to eutils.eclass in EAPIs 5
and older. For that reason, I'd like to have an early agreement on
the implementation so that we could avoid diverging from it
in EAPI 6.

[1]:http://article.gmane.org/gmane.linux.gentoo.devel/87803

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Markos Chandras]

On 27 August 2013 10:54, Ulrich Mueller <ulm@gentoo.org> 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.
>
> Please respond to this message with agenda items. Do not hesitate to
> repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).
>
> The agenda for the next meeting will be sent out on Tuesday 2013-09-03.
>
> Please respond to the gentoo-project list, if possible.
>
> Ulrich

Hi,

I'd like to ask the council to vote on the following topics regarding the
'minor arches' based on the feedback I received on the respective
thread in the gentoo-dev mailing list

http://marc.info/?l=gentoo-dev&m=137708312817671&w=1

Drop the following arches to ~arch

- s390
- sh
- ia64
- alpha
- m68k
- sparc
-(maybe ppc and ppc64?)

The feedback on the original question was mostly positive.
Most people agree that the long stabilization queues for these
architectures create problems
for maintainers wishing to drop old versions.
The council should also take into consideration that the stabilization process
for these arches is mostly a one-man job (Agostino).

However, some people raised the point that we should provide stable stages
for these architectures and drop everything else to ~arch.

So if the Council votes 'NO' to the original question, vote on whether
only @system should
be stable for these architectures.

The Council should also provide a list of the arches that wishes to
"mark" as ~arch (even if they only do stable @system)
so maintainers are aware of the situation.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Wed, Aug 28, 2013 at 7:15 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
>
> However, some people raised the point that we should provide stable stages
> for these architectures and drop everything else to ~arch.
>
> So if the Council votes 'NO' to the original question, vote on whether
> only @system should
> be stable for these architectures.

I'd be interested in whether anybody on the arch teams themselves
actually supports this proposal.  I don't think I actually heard much
commentary in that thread one way or another from arch team members,
which is as good a reason as any to just completely drop the arch to
testing.  If some spoke up about being willing to keep up with the
@system packages then considering allowing stable keywords for those
would make more sense.

And yes, I was one of the proponents of the model I tossed out there.
A good idea that isn't going to be properly supported isn't a good
idea.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Matt Turner]

On Wed, Aug 28, 2013 at 4:24 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Aug 28, 2013 at 7:15 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
>>
>> However, some people raised the point that we should provide stable stages
>> for these architectures and drop everything else to ~arch.
>>
>> So if the Council votes 'NO' to the original question, vote on whether
>> only @system should
>> be stable for these architectures.
>
> I'd be interested in whether anybody on the arch teams themselves
> actually supports this proposal.  I don't think I actually heard much
> commentary in that thread one way or another from arch team members,
> which is as good a reason as any to just completely drop the arch to
> testing.  If some spoke up about being willing to keep up with the
> @system packages then considering allowing stable keywords for those
> would make more sense.
>
> And yes, I was one of the proponents of the model I tossed out there.
> A good idea that isn't going to be properly supported isn't a good
> idea.
>
> Rich
>

I'm an Alpha maintainer and a MIPS (which is unstable only)
maintainer. I'm against the proposal and I said so in the thread.

It seemed to me that I was the only arch team member to respond. All
of the +1s were from people with no stake in the architectures
themselves, and for me hold very little value.

I can respond with arguments and data to support my case now, or just
as easily (assuming I remember to attend) the upcoming council
meeting.

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/08/13 01:28 PM, Matt Turner wrote:
> 
> I can respond with arguments and data to support my case now, or
> just as easily (assuming I remember to attend) the upcoming
> council meeting.
> 

Do it now ; no point in potentially missing the date and not being
heard...  IIRC the issue primer thread that the chair puts together
will include either the whole posting or at least your relevant points.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlIeNcwACgkQ2ugaI38ACPD0FwEAjMtCxxyKgxGQlJYeS9dg9mti
vyTtpDJXdIECSOHXENEA/2GEQkgXkk1qMgxc9qrg7aYiuOhKGD/BO9/hwlzSyhHL
=77DZ
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Samuli Suominen]

On 28/08/13 14:15, Markos Chandras wrote:
> On 27 August 2013 10:54, Ulrich Mueller <ulm@gentoo.org> 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.
>>
>> Please respond to this message with agenda items. Do not hesitate to
>> repeat your agenda item here with a pointer if you previously
>> suggested one (since the last meeting).
>>
>> The agenda for the next meeting will be sent out on Tuesday 2013-09-03.
>>
>> Please respond to the gentoo-project list, if possible.
>>
>> Ulrich
>
> Hi,
>
> I'd like to ask the council to vote on the following topics regarding the
> 'minor arches' based on the feedback I received on the respective
> thread in the gentoo-dev mailing list
>
> http://marc.info/?l=gentoo-dev&m=137708312817671&w=1
>
> Drop the following arches to ~arch
>
> - s390
> - sh
> - ia64
> - alpha
> - m68k

armin76 just posted on planet.gentoo.org how m68k emulator can be used 
as an m68k arch tool (build host)
but this one is the one that is worringly behind others, even other 
minor arches, the one that gets left behind alone in bug reports and 
often have 3 different stablereqs for just 1 package :/

maybe separate voting on m68k, since it seems like the m68k-problem is 
being dwelled into more generic lesser problem
imho :)

> - sparc
> -(maybe ppc and ppc64?)
>
> The feedback on the original question was mostly positive.
> Most people agree that the long stabilization queues for these
> architectures create problems
> for maintainers wishing to drop old versions.
> The council should also take into consideration that the stabilization process
> for these arches is mostly a one-man job (Agostino).
>
> However, some people raised the point that we should provide stable stages
> for these architectures and drop everything else to ~arch.
>
> So if the Council votes 'NO' to the original question, vote on whether
> only @system should
> be stable for these architectures.
>
> The Council should also provide a list of the arches that wishes to
> "mark" as ~arch (even if they only do stable @system)
> so maintainers are aware of the situation.
>

Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Andreas K. Huettel]

Am Mittwoch 28 August 2013, 12:15:14 schrieb Markos Chandras:
>
> Drop the following arches to ~arch
> 
> - s390
> - sh
> - ia64
> - alpha
> - m68k
> - sparc
> -(maybe ppc and ppc64?)
> 

++, in particular for m68k. 

Any decision should be made per-arch though, not for the whole list in one go.

If an arch team objects here and now with good arguments that would likely 
influence the decision. 

If an arch team ignores this discussion completely and no reply comes at all 
until the council meeting, or the reply just consists of a "No", that would 
likely influence the decision too...

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Michael Weber]

On 08/28/2013 01:15 PM, Markos Chandras wrote:
> Hi,
> 
> I'd like to ask the council to vote on the following topics regarding the
> 'minor arches' based on the feedback I received on the respective
> thread in the gentoo-dev mailing list
> 
> http://marc.info/?l=gentoo-dev&m=137708312817671&w=1
> 
> Drop the following arches to ~arch
> 
> - s390
> - sh
> - ia64
> - alpha
> - m68k
> - sparc
> -(maybe ppc and ppc64?)
make that x86 to be consequent.
> 
> The feedback on the original question was mostly positive.
> Most people agree that the long stabilization queues for these
> architectures create problems
> for maintainers wishing to drop old versions.
Is this the only motivation? Drop all the effort that has been put into
stabilization work on minor arches just for some impatient maintainers?

Keywording/Stabilization is a process we all agreed on joining, so live
with it.

> The council should also take into consideration that the stabilization process
> for these arches is mostly a one-man job (Agostino).
It's the same one man show for amd64 and x86. Well, there are others on
the arch teams that do stabilizations, but an very active Agostino makes
them rely on his caring and drags away focus - imho.

> However, some people raised the point that we should provide stable stages
> for these architectures and drop everything else to ~arch.
Minor arches tend to have less cpu/io performance than this fancy
show-off amd64 dev machines.
Running the @world\@system on bleeding edge might be a never ending
compile job.

Please give it thorough consideration before throwing all the work out
of the window.

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Markos Chandras]

On 29 August 2013 07:09, Michael Weber <xmw@gentoo.org> wrote:
> On 08/28/2013 01:15 PM, Markos Chandras wrote:
>> Hi,
>>
>> I'd like to ask the council to vote on the following topics regarding the
>> 'minor arches' based on the feedback I received on the respective
>> thread in the gentoo-dev mailing list
>>
>> http://marc.info/?l=gentoo-dev&m=137708312817671&w=1
>>
>> Drop the following arches to ~arch
>>
>> - s390
>> - sh
>> - ia64
>> - alpha
>> - m68k
>> - sparc
>> -(maybe ppc and ppc64?)
> make that x86 to be consequent.

I don't think being sarcastic adds anything valuable to the conversation

>>
>> The feedback on the original question was mostly positive.
>> Most people agree that the long stabilization queues for these
>> architectures create problems
>> for maintainers wishing to drop old versions.
> Is this the only motivation? Drop all the effort that has been put into
> stabilization work on minor arches just for some impatient maintainers?

Others reasons are explained to the thread in -dev ML

>
> Keywording/Stabilization is a process we all agreed on joining, so live
> with it.
>
>> The council should also take into consideration that the stabilization process
>> for these arches is mostly a one-man job (Agostino).
> It's the same one man show for amd64 and x86.

It is not.

> Minor arches tend to have less cpu/io performance than this fancy
> show-off amd64 dev machines.
> Running the @world\@system on bleeding edge might be a never ending
> compile job.

This is one of the reasons they are so slow. And combining it with the
one-man show argument,
you see why we have problems. Moreover, as you can see, nobody from
these arch teams
ever replied (apart from Matt) which kinda proves my point.

>
> Please give it thorough consideration before throwing all the work out
> of the window.

The council members are supposed to read the original thread in
gentoo-dev before they make a decision.
I believe adding more feedback to this thread might end up in
/dev/null so if you want to contribute to the
conversation please do so in the original thread. It would be easier
for them to have everything collected
in a single thread when they discuss this.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Michael Weber]

On 08/29/2013 10:32 AM, Markos Chandras wrote:
> On 29 August 2013 07:09, Michael Weber <xmw@gentoo.org> wrote:
>> On 08/28/2013 01:15 PM, Markos Chandras wrote:
>>> Hi,
>>>
>>> I'd like to ask the council to vote on the following topics regarding the
>>> 'minor arches' based on the feedback I received on the respective
>>> thread in the gentoo-dev mailing list
>>>
>>> http://marc.info/?l=gentoo-dev&m=137708312817671&w=1
>>>
>>> Drop the following arches to ~arch
>>>
>>> - s390
>>> - sh
>>> - ia64
>>> - alpha
>>> - m68k
>>> - sparc
>>> -(maybe ppc and ppc64?)
>> make that x86 to be consequent.
> 
> I don't think being sarcastic adds anything valuable to the conversation
Neither does diving partial summaries or exaggerating the reality.
> 
>>>
>>> The feedback on the original question was mostly positive.
>>> Most people agree that the long stabilization queues for these
>>> architectures create problems
>>> for maintainers wishing to drop old versions.
>> Is this the only motivation? Drop all the effort that has been put into
>> stabilization work on minor arches just for some impatient maintainers?
> 
> Others reasons are explained to the thread in -dev ML
> 
>>
>> Keywording/Stabilization is a process we all agreed on joining, so live
>> with it.
>>
>>> The council should also take into consideration that the stabilization process
>>> for these arches is mostly a one-man job (Agostino).
>> It's the same one man show for amd64 and x86.
> 
> It is not.
Neither is it for minor arches. There are others doing stabilizations, too.

>> Minor arches tend to have less cpu/io performance than this fancy
>> show-off amd64 dev machines.
>> Running the @world\@system on bleeding edge might be a never ending
>> compile job.
> 
> This is one of the reasons they are so slow. And combining it with the
> one-man show argument,
> you see why we have problems. Moreover, as you can see, nobody from
> these arch teams
> ever replied (apart from Matt) which kinda proves my point.
I did stabilizations on sparc/ppc before ago kicked in.

A arm/ppc/sparc arch member.

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Ben de Groot]

On 29 August 2013 14:09, Michael Weber <xmw@gentoo.org> wrote:
> On 08/28/2013 01:15 PM, Markos Chandras wrote:
>> The feedback on the original question was mostly positive.
>> Most people agree that the long stabilization queues for these
>> architectures create problems
>> for maintainers wishing to drop old versions.
> Is this the only motivation? Drop all the effort that has been put into
> stabilization work on minor arches just for some impatient maintainers?
>
> Keywording/Stabilization is a process we all agreed on joining, so live
> with it.

Minor arches holding up GLSAs and removal of vulnerable stable ebuilds
for 3 months or more is *not* acceptable, and not something I agreed
to when joining...

If they can't even do security stabilizations in a reasonable
timeframe, they have no business being considered stable arches.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Markos Chandras]

On 29 August 2013 14:16, Ben de Groot <yngwin@gentoo.org> wrote:
> On 29 August 2013 14:09, Michael Weber <xmw@gentoo.org> wrote:
>> On 08/28/2013 01:15 PM, Markos Chandras wrote:
>>> The feedback on the original question was mostly positive.
>>> Most people agree that the long stabilization queues for these
>>> architectures create problems
>>> for maintainers wishing to drop old versions.
>> Is this the only motivation? Drop all the effort that has been put into
>> stabilization work on minor arches just for some impatient maintainers?
>>
>> Keywording/Stabilization is a process we all agreed on joining, so live
>> with it.
>
> Minor arches holding up GLSAs and removal of vulnerable stable ebuilds
> for 3 months or more is *not* acceptable, and not something I agreed
> to when joining...
>
> If they can't even do security stabilizations in a reasonable
> timeframe, they have no business being considered stable arches.
>
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
>

I don't understand why moving an arch to ~testing is considered such
an insult by their members and
they react like this. It works great for MIPS, it can work great for
the others too.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Jack Morgan]

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

On Thu, Aug 29, 2013 at 09:16:03PM +0800, Ben de Groot wrote:
> On 29 August 2013 14:09, Michael Weber <xmw@gentoo.org> wrote:
> > On 08/28/2013 01:15 PM, Markos Chandras wrote:
> >> The feedback on the original question was mostly positive.
> >> Most people agree that the long stabilization queues for these
> >> architectures create problems
> >> for maintainers wishing to drop old versions.
> > Is this the only motivation? Drop all the effort that has been put into
> > stabilization work on minor arches just for some impatient maintainers?
> >
> > Keywording/Stabilization is a process we all agreed on joining, so live
> > with it.
> 
> Minor arches holding up GLSAs and removal of vulnerable stable ebuilds
> for 3 months or more is *not* acceptable, and not something I agreed
> to when joining...
> 
> If they can't even do security stabilizations in a reasonable
> timeframe, they have no business being considered stable arches.

I think this is a good point but again needs to be defined somewhere
besides comments on a ML. If an ARCH is not able to respond to a GLSA
within a reasonable timeframe due to lack of developer resources, then it
shouldn't be offically supported by Gentoo Linux. 

The problem is that a "reasonable timeframe" is not defined AFAIK and
what happens to an ARCH that fails here is not defined. Let's move away
from peoples presonal idea on the matter and define a policy or GLEP. 


-- 
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan <jmorgan@gentoo.org>>
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

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

Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Andreas K. Huettel]

> > > Is this the only motivation? Drop all the effort that has been put into
> > > stabilization work on minor arches just for some impatient maintainers?
> > > 
> > > Keywording/Stabilization is a process we all agreed on joining, so live
> > > with it.
> > 
> > Minor arches holding up GLSAs and removal of vulnerable stable ebuilds
> > for 3 months or more is *not* acceptable, and not something I agreed
> > to when joining...
> > 
> > If they can't even do security stabilizations in a reasonable
> > timeframe, they have no business being considered stable arches.
> 
> I think this is a good point but again needs to be defined somewhere
> besides comments on a ML. If an ARCH is not able to respond to a GLSA
> within a reasonable timeframe due to lack of developer resources, then it
> shouldn't be offically supported by Gentoo Linux.

The braindead thing is that the GLSA is only going out after all arches have 
stabilized.

Meaning, the slowest arch in practice blocks the GLSA process.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Sergey Popov]

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

29.08.2013 19:57, Andreas K. Huettel пишет:
> The braindead thing is that the GLSA is only going out after all arches have 
> stabilized.
> 
> Meaning, the slowest arch in practice blocks the GLSA process.
> 

We have security-supported arches list with arch teams liassons. When
they are all stabilized package, we can begin to make GLSA even if there
are other arches pending(e.g. s390/sh/m68k are NEVER considered
security-stable arches, per out docs[1]). However i think we should
reconsider this list, probably throw some arches away(and add some new,
for example arm, for which i can became security liasson).

[1] - http://www.gentoo.org/security/en/vulnerability-policy.xml

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Chris Reffett]

On 8/30/2013 4:52 AM, Sergey Popov wrote:
> 29.08.2013 19:57, Andreas K. Huettel пишет:
>> The braindead thing is that the GLSA is only going out after all
arches have
>> stabilized.
>>
>> Meaning, the slowest arch in practice blocks the GLSA process.
>>
>
> We have security-supported arches list with arch teams liassons. When
> they are all stabilized package, we can begin to make GLSA even if there
> are other arches pending(e.g. s390/sh/m68k are NEVER considered
> security-stable arches, per out docs[1]). However i think we should
> reconsider this list, probably throw some arches away(and add some new,
> for example arm, for which i can became security liasson).
>
> [1] - http://www.gentoo.org/security/en/vulnerability-policy.xml
>
The problem here is one of workflow. Even if we ignore
security-unsupported arches, our workflow is generally bump packages ->
stabilize -> clean up -> release GLSA -> close bug. The problem is that
while we can skip ahead and start drafting a GLSA, we can't clean up and
close the bug until the slow arches catch up on stabilizing, so they
hold us up regardless. I'm all for changing the officially supported
list, but I'm not sure how much good it will do us.

Chris Reffett

[gentoo-project] Re: Call for agenda items - Council meeting 2013-09-10

[Steven J. Long]

On Fri, Aug 30, 2013 at 08:53:38AM -0400, Chris Reffett wrote:
> On 8/30/2013 4:52 AM, Sergey Popov wrote:
> > 29.08.2013 19:57, Andreas K. Huettel пишет:
> >> The braindead thing is that the GLSA is only going out after all
> arches have
> >> stabilized.
> >>
> >> Meaning, the slowest arch in practice blocks the GLSA process.
> >>
> >
> > We have security-supported arches list with arch teams liassons. When
> > they are all stabilized package, we can begin to make GLSA even if there
> > are other arches pending(e.g. s390/sh/m68k are NEVER considered
> > security-stable arches, per out docs[1]). However i think we should
> > reconsider this list, probably throw some arches away(and add some new,
> > for example arm, for which i can became security liasson).
> >
> > [1] - http://www.gentoo.org/security/en/vulnerability-policy.xml
> >
> The problem here is one of workflow. Even if we ignore
> security-unsupported arches, our workflow is generally bump packages ->
> stabilize -> clean up -> release GLSA -> close bug. The problem is that
> while we can skip ahead and start drafting a GLSA, we can't clean up and
> close the bug until the slow arches catch up on stabilizing, so they
> hold us up regardless. I'm all for changing the officially supported
> list, but I'm not sure how much good it will do us.

Well, dropping an arch from the GLSA list is a far less drastic option, and
afaict from your description, would answer the concerns of long stabilisation
queues for devs on faster-moving archs, working on popular/volatile packages.

Perhaps that could be automated, with whatever timeframe QA blesses, and
act as a prelude or interim measure; either the arch goes unstable eg 6 or
12 months later or it shows it can keep up with GLSAs. That gives the team
enough time to either recruit, or taper down their workload, without losing
the work they've put in. The demoralisation effect of the latter is too 
serious to ignore, especially for already-undermanned teams.

Under this view, if you don't have enough semi-skilled users interested
enough to help out with GLSAs, and can't get them in say 6 months, you don't
have enough developers to stay stable, but still have time to warn your users,
and wind-down after making the decision. Meantime, some of them might take
it as a wake-up call, and pitch in.

Regards,
steveL.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Thu, Aug 29, 2013 at 11:34 AM, Jack Morgan <jmorgan@gentoo.org> wrote:
> I think this is a good point but again needs to be defined somewhere
> besides comments on a ML.

Honestly, I think half the problems that come up tend to come up over
and over because there isn't any place to document them other than MLs
(too informal), or GLEPs (too formal).

I think we really need something in-between.  A GLEP makes sense for a
specification, but not much sense for a one-line policy.  The
devmanual has sort-of filled in as a substitute but isn't really the
right place for an issue like this one.

Rich

Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Andreas K. Huettel]

Am Donnerstag 29 August 2013, 21:16:03 schrieb Ben de Groot:
>
> > Keywording/Stabilization is a process we all agreed on joining, so live
> > with it.
> 
> Minor arches holding up GLSAs and removal of vulnerable stable ebuilds
> for 3 months or more is *not* acceptable, and not something I agreed
> to when joining...
> 
> If they can't even do security stabilizations in a reasonable
> timeframe, they have no business being considered stable arches.

+1

See net-print/cups, only m68k left and not responding for ages
https://bugs.gentoo.org/show_bug.cgi?id=442926

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Matt Turner]

On Thu, Aug 29, 2013 at 6:16 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 29 August 2013 14:09, Michael Weber <xmw@gentoo.org> wrote:
>> On 08/28/2013 01:15 PM, Markos Chandras wrote:
>>> The feedback on the original question was mostly positive.
>>> Most people agree that the long stabilization queues for these
>>> architectures create problems
>>> for maintainers wishing to drop old versions.
>> Is this the only motivation? Drop all the effort that has been put into
>> stabilization work on minor arches just for some impatient maintainers?
>>
>> Keywording/Stabilization is a process we all agreed on joining, so live
>> with it.
>
> Minor arches holding up GLSAs and removal of vulnerable stable ebuilds
> for 3 months or more is *not* acceptable, and not something I agreed
> to when joining...
>
> If they can't even do security stabilizations in a reasonable
> timeframe, they have no business being considered stable arches.
>
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
>

Has this actually happened? The only thing I ever see about GLSAs is
the occasional closing of a multi-year-old bug for a version of a
package no longer in the tree as "no glsa"

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Matt Turner]

On Thu, Aug 29, 2013 at 9:15 AM, Matt Turner <mattst88@gentoo.org> wrote:
> On Thu, Aug 29, 2013 at 6:16 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 29 August 2013 14:09, Michael Weber <xmw@gentoo.org> wrote:
>>> On 08/28/2013 01:15 PM, Markos Chandras wrote:
>>>> The feedback on the original question was mostly positive.
>>>> Most people agree that the long stabilization queues for these
>>>> architectures create problems
>>>> for maintainers wishing to drop old versions.
>>> Is this the only motivation? Drop all the effort that has been put into
>>> stabilization work on minor arches just for some impatient maintainers?
>>>
>>> Keywording/Stabilization is a process we all agreed on joining, so live
>>> with it.
>>
>> Minor arches holding up GLSAs and removal of vulnerable stable ebuilds
>> for 3 months or more is *not* acceptable, and not something I agreed
>> to when joining...
>>
>> If they can't even do security stabilizations in a reasonable
>> timeframe, they have no business being considered stable arches.
>>
>> --
>> Cheers,
>>
>> Ben | yngwin
>> Gentoo developer
>>
>
> Has this actually happened? The only thing I ever see about GLSAs is
> the occasional closing of a multi-year-old bug for a version of a
> package no longer in the tree as "no glsa"

Ah, I see the m68k bug referenced in this thread.

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[William Hubbs]

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

All, I'm responding to this particular message because I think there is
another  sub-thread we should think about.

On Thu, Aug 29, 2013 at 09:16:03PM +0800, Ben de Groot wrote:
> On 29 August 2013 14:09, Michael Weber <xmw@gentoo.org> wrote:
> > On 08/28/2013 01:15 PM, Markos Chandras wrote:
> >> The feedback on the original question was mostly positive.
> >> Most people agree that the long stabilization queues for these
> >> architectures create problems
> >> for maintainers wishing to drop old versions.
> > Is this the only motivation? Drop all the effort that has been put into
> > stabilization work on minor arches just for some impatient maintainers?
> >
> > Keywording/Stabilization is a process we all agreed on joining, so live
> > with it.
> 
> Minor arches holding up GLSAs and removal of vulnerable stable ebuilds
> for 3 months or more is *not* acceptable, and not something I agreed
> to when joining...
> 
> If they can't even do security stabilizations in a reasonable
> timeframe, they have no business being considered stable arches.

In the past, I have had arch teams refuse to stabilize a newer version
of a package after an older version is stable unless a user of the arch
wants the new version to be stabilized, thus forcing  older versions to be
kept around for their stable users.

IMO if an arch team does this, maintainers should be able to move
the affected package to ~ on that arch, or maybe even drop that arch's
keyword entirely.

William


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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Jack Morgan]

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

On Wed, Aug 28, 2013 at 12:15:14PM +0100, Markos Chandras wrote:
> On 27 August 2013 10:54, Ulrich Mueller <ulm@gentoo.org> 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.
> >
> > Please respond to this message with agenda items. Do not hesitate to
> > repeat your agenda item here with a pointer if you previously
> > suggested one (since the last meeting).
> >
> > The agenda for the next meeting will be sent out on Tuesday 2013-09-03.
> >
> > Please respond to the gentoo-project list, if possible.
> >
> > Ulrich
> 
> Hi,
> 
> I'd like to ask the council to vote on the following topics regarding the
> 'minor arches' based on the feedback I received on the respective
> thread in the gentoo-dev mailing list
> 
> http://marc.info/?l=gentoo-dev&m=137708312817671&w=1
> 
> Drop the following arches to ~arch
> 
> - s390
> - sh
> - ia64
> - alpha
> - m68k
> - sparc
> -(maybe ppc and ppc64?)

I work on ia64, sparc, ppc and ppc64. I'm completely against this
proposal in its current form.  


> The feedback on the original question was mostly positive.
> Most people agree that the long stabilization queues for these
> architectures create problems for maintainers wishing to drop old versions.

Only a hand full of people responded to the email thread (possitively or
negatively) so I don't think that your statement above is correct about
"most people agree" since we have somewhere over a hundred developers?

Please provide data to support your claim here about "problems for
maintainers". I've not seen this. What I have seen is someone posting,
"hey we need more people to help out with ppc" and several people
helped out. In addition, we have ARCH specific hardware[1] that any
developer can gain access to to do ARCH testing. I beleive this is what
ago does. 

As I mentioned in the -dev ML, I don't think this is the right approach
to your concern. There should be a clear definition of what is  expected
from an arch that is offically supported by Gentoo Linux. By offically
supportd I mean ARCH/stable keyworded. If an arch fails to meet those
requirements, then "demote" it to ~arch only status. This should be a
GLEP. Otherwise, you are asking others to base their decision on someones
perception. 

> The council should also take into consideration that the stabilization process
> for these arches is mostly a one-man job (Agostino).

This is not true. Ago does do a majority share true but he is not the only
one. I do like how he does arch testing. I think we should strive to
replicate his process thus removing this concern. 

> However, some people raised the point that we should provide stable stages
> for these architectures and drop everything else to ~arch.

What for? So we can give the false precetion that Gentoo Linux supports
a specific ARCH?

> So if the Council votes 'NO' to the original question, vote on whether
> only @system should be stable for these architectures.
> 
> The Council should also provide a list of the arches that wishes to
> "mark" as ~arch (even if they only do stable @system)
> so maintainers are aware of the situation
 
This is a confusing. What is the real problem you are trying to solve
here? Stable @system but not having to worry about keywording anything
else.. like a desktop (gnome, KDE)?


If keywording an ARCH is a real concern, then Gentoo Linux should have
a long hard look as what it wants to support as a developer community. I
want to challange the council to take this as an opportunity to define
this. If developer resources are limited, then Gentoo Linux can't
support everything it has in the portage tree.

 
[1] http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml

-- 
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan <jmorgan@gentoo.org>>
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Thu, Aug 29, 2013 at 11:22 AM, Jack Morgan <jmorgan@gentoo.org> wrote:
> As I mentioned in the -dev ML, I don't think this is the right approach
> to your concern. There should be a clear definition of what is  expected
> from an arch that is offically supported by Gentoo Linux. By offically
> supportd I mean ARCH/stable keyworded. If an arch fails to meet those
> requirements, then "demote" it to ~arch only status. This should be a
> GLEP. Otherwise, you are asking others to base their decision on someones
> perception.

That seems like a reasonable question for the council to address.

Personally my sense is that if a package has a STABLEREQ pending for
60 days maintainers should be able to drop the stable version of the
package at their discretion.  This really should be a max though.  If
this is happening with any regularity then the arch should be dropped
from stable keywords, unless some other arrangement is made (like
@system-only stable - an arrangement with its own pros and cons).

It probably makes sense for those calls to be made by the Council
unless the arch project lead agrees.

> If keywording an ARCH is a real concern, then Gentoo Linux should have
> a long hard look as what it wants to support as a developer community. I
> want to challange the council to take this as an opportunity to define
> this. If developer resources are limited, then Gentoo Linux can't
> support everything it has in the portage tree.
>

Developer resources would be limited even if we had a paid staff of
20k developers.

Unmaintained packages do get treecleaned.  However, the issue here is
with arch maintenance, not package maintenance.  It isn't the
responsibility of package maintainers to do arch testing, though many
choose to do so with the agreement of the appropriate arch projects.

Rich

Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Andreas K. Huettel]

Am Donnerstag 29 August 2013, 11:44:13 schrieb Rich Freeman:
>
> Personally my sense is that if a package has a STABLEREQ pending for
> 60 days maintainers should be able to drop the stable version of the
> package at their discretion.
>

Sounds reasonable, but then you get just abused by Mr_Bones for breaking the 
deptree.

Anyway, how about when the arch has not even responded to the (much older) 
KEYWORDREQ for that package? :|

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Thu, Aug 29, 2013 at 12:06 PM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
>
> Sounds reasonable, but then you get just abused by Mr_Bones for breaking the
> deptree.

The solution to that is to either ignore the abuse, or drop the stable
keywords on all reverse deps as well.

Dropping individual package keywords shouldn't happen much, since the
fact that it is happening is a good sign that the whole arch should be
dropped.  If an arch team can't keep up with a single package they
should remove the stable keywords themselves so that this can be done
in an orderly manner.

>
> Anyway, how about when the arch has not even responded to the (much older)
> KEYWORDREQ for that package? :|

I see this as less of an issue - maybe the maintainer just drops
themselves from the bug to be added-back by the arch team only if
needed.  If the maintainer logged it they can also cancel it if they
don't care to see it open.

The only people affected by a pending KEYWORDREQ are the users of that
arch.  They're at the mercy of the arch team no matter what - if the
package matters that much to them they should step up to arch test.

Please don't interpret anything I'm saying as a lack of care for small
archs.  I'd just rather see them define their goals in terms of things
they can actually accomplish and then accomplish those.  Having a
bunch of ancient stable versions that are just weighing down the rest
of the distro isn't really a good measure of success.  That was why I
suggested the possible @system-only compromise - it might be a way to
capture some of the value of having stable keywords while greatly
reducing the amount of work involved.  Better to do less but do it
properly.

That said, I'd also encourage maintainers to leave around old versions
as long as they aren't actually maintenance burdens.  If they become
such, well, time to prune if the STABLEREQ is stale.

Rich

Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Thu, Aug 29, 2013 at 1:49 PM, Rich Freeman <rich0@gentoo.org> wrote:
>
> Please don't interpret anything I'm saying as a lack of care for small
> archs.  I'd just rather see them define their goals in terms of things
> they can actually accomplish and then accomplish those.  Having a
> bunch of ancient stable versions that are just weighing down the rest
> of the distro isn't really a good measure of success.  That was why I
> suggested the possible @system-only compromise - it might be a way to
> capture some of the value of having stable keywords while greatly
> reducing the amount of work involved.  Better to do less but do it
> properly.
>

I didn't really get any response to this one way or another.  At the
last council meeting a majority of the votes were in favor of delaying
taking action, so this is back on the agenda.
I have yet to see either of the following on this list:
1.  Specific examples of bugs where a minor arch is making a
maintainer's life difficult.  Please post if you have them.
2.  Members of these arch teams posting here committing to either
stabilize new versions or unkeyword old versions in a timely manner.

The responses to either of these (or lack thereof) are likely to
influence my vote at the meeting.  Note, I'm not interested in mere
comments that people want an arch to stay stable supported (which I've
seen plenty of).  I'm interested in COMMITMENT to be
stable-supportable (which I've seen none of).  The lack of the latter
is what is going to cause a package to be dropped - I'd love to see
every arch that exists stable-supported on Gentoo, along with world
peace.  This is a volunteer distro - in general you get the features
you pitch in to help deliver, and if you're depending on a minor arch
you REALLY need to step up as there aren't many of you out there.
That said, I would like specific examples of cases where dropping a
minor arch would have helped - the onus is on those wanting the status
quo changed to present a case.

Rich

[gentoo-project] Minor arches (was: Call for agenda items - Council meeting 2013-09-10)

[Ulrich Mueller]

>>>>> On Sun, 15 Sep 2013, Rich Freeman wrote:

> I didn't really get any response to this one way or another.  At the
> last council meeting a majority of the votes were in favor of
> delaying taking action, so this is back on the agenda.

> I have yet to see either of the following on this list:
> 1.  Specific examples of bugs where a minor arch is making a
> maintainer's life difficult.  Please post if you have them.
> 2.  Members of these arch teams posting here committing to either
> stabilize new versions or unkeyword old versions in a timely manner.

> The responses to either of these (or lack thereof) are likely to
> influence my vote at the meeting.  Note, I'm not interested in mere
> comments that people want an arch to stay stable supported (which
> I've seen plenty of).  I'm interested in COMMITMENT to be
> stable-supportable (which I've seen none of).  The lack of the
> latter is what is going to cause a package to be dropped - I'd love
> to see every arch that exists stable-supported on Gentoo, along with
> world peace.  This is a volunteer distro - in general you get the
> features you pitch in to help deliver, and if you're depending on a
> minor arch you REALLY need to step up as there aren't many of you
> out there.  That said, I would like specific examples of cases where
> dropping a minor arch would have helped - the onus is on those
> wanting the status quo changed to present a case.

[Crossposting to -dev. Replies should go to -project if possible.]

Again, no reply. I suspect the outcome of today's vote will be that
stable keywords for the architectures in question (alpha, ia64, m68k,
s390, sh, sparc) should be dropped.

Arch teams, last chance to speak up.

Ulrich

Re: [gentoo-project] Minor arches (was: Call for agenda items - Council meeting 2013-09-10)

[Matt Turner]

 On Tue, Sep 17, 2013 at 6:04 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Sun, 15 Sep 2013, Rich Freeman wrote:
>
>> I didn't really get any response to this one way or another.  At the
>> last council meeting a majority of the votes were in favor of
>> delaying taking action, so this is back on the agenda.
>
>> I have yet to see either of the following on this list:
>> 1.  Specific examples of bugs where a minor arch is making a
>> maintainer's life difficult.  Please post if you have them.
>> 2.  Members of these arch teams posting here committing to either
>> stabilize new versions or unkeyword old versions in a timely manner.
>
>> The responses to either of these (or lack thereof) are likely to
>> influence my vote at the meeting.  Note, I'm not interested in mere
>> comments that people want an arch to stay stable supported (which
>> I've seen plenty of).  I'm interested in COMMITMENT to be
>> stable-supportable (which I've seen none of).  The lack of the
>> latter is what is going to cause a package to be dropped - I'd love
>> to see every arch that exists stable-supported on Gentoo, along with
>> world peace.  This is a volunteer distro - in general you get the
>> features you pitch in to help deliver, and if you're depending on a
>> minor arch you REALLY need to step up as there aren't many of you
>> out there.  That said, I would like specific examples of cases where
>> dropping a minor arch would have helped - the onus is on those
>> wanting the status quo changed to present a case.
>
> [Crossposting to -dev. Replies should go to -project if possible.]
>
> Again, no reply. I suspect the outcome of today's vote will be that
> stable keywords for the architectures in question (alpha, ia64, m68k,
> s390, sh, sparc) should be dropped.
>
> Arch teams, last chance to speak up.
>
> Ulrich
>

I've already spoken up as have others. I'm an alpha maintainer and I'm
against this. jmorgan is a sparc maintainer and he's against it.

I don't care about the others, and frankly understand the frustration
with long stable requests, but leave alpha out of it.

Re: [gentoo-project] Minor arches (was: Call for agenda items - Council meeting 2013-09-10)

[Agostino Sarubbo]

On Tuesday 17 September 2013 15:04:51 Ulrich Mueller wrote:
> Again, no reply. I suspect the outcome of today's vote will be that
> stable keywords for the architectures in question (alpha, ia64, m68k,
> s390, sh, sparc) should be dropped.
> 
> Arch teams, last chance to speak up.
> 
> Ulrich

The links to the current queue:
https://bugs.gentoo.org/buglist.cgi?keywords=STABLEREQ%2C%20&keywords_type=allwords&f1=cc&o1=equals&query_format=advanced&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&v1=alpha%40gentoo.org&product=Gentoo%20Linux&list_id=1996430
https://bugs.gentoo.org/buglist.cgi?keywords=STABLEREQ%2C%20&keywords_type=allwords&f1=cc&o1=equals&query_format=advanced&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&v1=ia64%40gentoo.org&product=Gentoo%20Linux&list_id=1996434
https://bugs.gentoo.org/buglist.cgi?keywords=STABLEREQ%2C%20&keywords_type=allwords&f1=cc&o1=equals&query_format=advanced&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&v1=sparc%40gentoo.org&product=Gentoo%20Linux&list_id=1996440

I'm working on them and we have:
22 bugs for alpha
17 bugs for ia64
49 bugs for sparc

If you consider that time ago the normal queue for amd64 was around 80 bugs, I 
really don't understand the request for all arches.

The request could be discussed for s390 and sh, which anyway have 46 and 85 
bugs.
-- 
Agostino Sarubbo
Gentoo Linux Developer

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Pacho Ramos]

El jue, 29-08-2013 a las 08:22 -0700, Jack Morgan escribió:
[...]
> This is a confusing. What is the real problem you are trying to solve
> here? Stable @system but not having to worry about keywording anything
> else.. like a desktop (gnome, KDE)?
> 

At least from a gnome perspective, we are having some important delays
with some arches:
- Pending keyword requests:
https://bugs.gentoo.org/show_bug.cgi?id=351931 -> sh and sparc
https://bugs.gentoo.org/show_bug.cgi?id=478254 -> alpha,arm, ia64, ppc*,
sparc
https://bugs.gentoo.org/show_bug.cgi?id=478256 -> the same
https://bugs.gentoo.org/show_bug.cgi?id=387959 -> sh, sparc
https://bugs.gentoo.org/show_bug.cgi?id=469722 -> s390 (this is probably
the worst case as they are then having a buggy old version)
https://bugs.gentoo.org/show_bug.cgi?id=469982 -> s390
https://bugs.gentoo.org/show_bug.cgi?id=471752 -> alpha, ia64, ppc*,
sparc
https://bugs.gentoo.org/show_bug.cgi?id=472510 -> s390
https://bugs.gentoo.org/show_bug.cgi?id=476710 -> alpha, arm, ia64,
ppc*, sh, sparc, x86
https://bugs.gentoo.org/show_bug.cgi?id=478082 -> alpha, sparc
https://bugs.gentoo.org/show_bug.cgi?id=466560 -> s390

In summary, s390 looks to be in worst state (as its missing keywording
affects even core packages like gtk+, pango...). But the situation is
also difficult for other arches like alpha and sparc because Agostino
cannot test them at runtime and, then, we think it's not safe to keyword
systemd on them without a runtime check, causing to lose Gnome 3.8
support for its "core" components.

- Stabilizations:
https://bugs.gentoo.org/show_bug.cgi?id=458984 -> m68k

If anyone could look at them, nice, but, from my point of view (not sure
what occurs outside gnome scope), at least m68k and s390 have important
problems to keyword/stabilize soon enough. And also noticed the
important problem of arches like alpha and sparc that are hard to test
at runtime :|

But this is only my impression, maybe some of this arches are more
active in other Gentoo areas.

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Tom Wijsman]

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

On Thu, 29 Aug 2013 19:17:32 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El jue, 29-08-2013 a las 08:22 -0700, Jack Morgan escribió:
> [...]
> > This is a confusing. What is the real problem you are trying to
> > solve here? Stable @system but not having to worry about keywording
> > anything else.. like a desktop (gnome, KDE)?
> > 
> 
> At least from a gnome perspective, we are having some important delays
> with some arches:
>
> ...
>
> But this is only my impression, maybe some of this arches are more
> active in other Gentoo areas.

Let's run it across the whole Portage tree; I'm searching for bugs with
STABLEREQ keyword, that are still open, have an empty "Depends On" field
and have the arch CC-ed:

alpha: 54 bugs.
arm: 28 bugs.
amd64: 61 bugs.
hppa: 2 bugs.
ia64: 61 bugs.
m68k: No bugs.
ppc64: 58 bugs.
ppc: 36 bugs.
s390: 47 bugs.
sh: 86 bugs.
sparc: 78 bugs.
x86: 75 bugs.

Surprisingly, nothing really stands out; but those are absolute
numbers, let's see what happens if we make them proportional. For this
I am going to base myself on http://www.akhuettel.de/gentoo-bugs/kw.php
where I simply take the amount of thousands and divide above numbers by
it, which gives us:

alpha: 54 / 10   = 5.4
arm:   28 / 10   = 2.8
amd64: 61 / 34   = 1.8
hppa:   2 / 9    = 0.2
ia64:  61 / 9.5  = 6.4
m68k:  91 / 2.4  = 37.9
ppc64: 58 / 12.5 = 4.6
ppc:   36 / 19   = 1.9
s390:  47 / 5.4  = 8.7
sh:    86 / 6    = 14.3
sparc: 78 / 12   = 6.5
x86:   75 / 34   = 2.2

So, what we get here now actually shows us how well the arch does
stabilization compared to the amount of ebuilds that the particular arch
has; of course, this doesn't take into account bugs that list resolved
"depends on" and also doesn't take into account when ebuilds are punted
although I don't really feel that those should matter.

People that want to see better statistics are free to improve the search
results to take into account bugs with solely resolved "depends on" bugs
as well as to exclude recent bugs if they feel like; as for the amount
of ebuilds you could opt to use the amount of packages.

So, lower numbers are better; so, let's sort them according to that.

hppa  0.2
ppc   1.9
amd64 2
x86   2.2
arm   2.8
alpha 5.4
ia64  6.4
ppc64 6.4
sparc 6.5
s390  8.7
sh    14.3
m68k  37.9

So, first we see hppa; I often see that stabilized quite fast if I CC
them, kudos to them! Nice to see the statistics here reflect this.

Then we have the major arches ppc, amd64, x86, arm; yup, seems right.
The difference between ppc, amd64 and x86 seems quite small even.

And then, we see all the arches that people here consider minor as a
big group follow up; there's a group around 6 (ia64, ppc64, sparc,
s390) and a group that's somewhat behind around 25 (sh and m68k).

These last arches are the ones listed, except for ppc64; there was the
"(maybe ppc and ppc64?)" question; well, I would say that ppc at least
doesn't seem like a minor arch to me. ppc64 looks to be among them.

So, based on these results I think we should somehow split it up and
turn it into two votes, kinda like this:

Vote 1: Do we drop stable keywords for m68k, sh and s390?

Rationality: These fall under the original reasoning of this thread.

Vote 2: Do we drop stable keywords for alpha, ia64, ppc64 and sparc?

Rationality: Do we (as Gentoo) want to focus on more major arches in a
way that we don't have minor arches block them? What do we want to
pursue? Broader support? Or rather making just the major arches perfect?

I think it would be nice to discuss this last bit as well as see the
Council clarify what we really want to pursue here. This isn't so much
a question about whether to take work away from people doing a bad job;
this is actually more a question of what we want to see people do.

Also, is dropping stable keywords really the right choice? Can we take
other measures perhaps? Make a canonical resource for arch testing?
Make the process easier to become one? ... (see prev ML thread for more)

We're talking too much about the problem (problematic arches); I think
we should talk more about possible solutions (reviving arches), and
perhaps we need to create even more resources (eg. an archmanual)
and easier and faster scripts and tools. Although CPU cycles are free...

(Please assume good faith; I don't want to call a particular arch or
what a particular arch does bad, I just want to see a sane solution)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Tom Wijsman]

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

On Thu, 29 Aug 2013 20:33:01 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> m68k: No bugs.

Addendum, this was a typo and has to be 91; I accidentally searched for
m86k the first time but ended up correcting this later on in the mail. 

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Andreas K. Huettel]

Am Donnerstag 29 August 2013, 20:33:01 schrieb Tom Wijsman:

> 
> Then we have the major arches ppc, amd64, x86, arm; yup, seems right.
> The difference between ppc, amd64 and x86 seems quite small even.
>

As the voice from history... this is the case mainly since Ago joined PPC. 
Before that, PPC was known to be lagging badly. (My impression, no hard data 
to back it up.) 

> 
> Vote 1: Do we drop stable keywords for m68k, sh and s390?
> 
> Rationality: These fall under the original reasoning of this thread.
> 
> Vote 2: Do we drop stable keywords for alpha, ia64, ppc64 and sparc?
> 
> Rationality: Do we (as Gentoo) want to focus on more major arches in a
> way that we don't have minor arches block them? What do we want to
> pursue? Broader support? Or rather making just the major arches perfect?
> 

Whenever this is discussed, we should probably take two things into account:

1) Is an arch "waxing or waning", meaning is the hardware still produced, and 
is the market share growing, stable, or deteriorating?

2) Is the hardware decently fast for compiling? I.e. are users likely to be 
interested in running Gentoo? (If I need a week to rebuild gcc...)

Cheers, A

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Thu, Aug 29, 2013 at 1:17 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> At least from a gnome perspective, we are having some important delays
> with some arches:
> - Pending keyword requests:
> https://bugs.gentoo.org/show_bug.cgi?id=351931 -> sh and sparc
> https://bugs.gentoo.org/show_bug.cgi?id=478254 -> alpha,arm, ia64, ppc*,
> sparc
> https://bugs.gentoo.org/show_bug.cgi?id=478256 -> the same
> https://bugs.gentoo.org/show_bug.cgi?id=387959 -> sh, sparc
> https://bugs.gentoo.org/show_bug.cgi?id=469722 -> s390 (this is probably
> the worst case as they are then having a buggy old version)
> https://bugs.gentoo.org/show_bug.cgi?id=469982 -> s390
> https://bugs.gentoo.org/show_bug.cgi?id=471752 -> alpha, ia64, ppc*,
> sparc
> https://bugs.gentoo.org/show_bug.cgi?id=472510 -> s390
> https://bugs.gentoo.org/show_bug.cgi?id=476710 -> alpha, arm, ia64,
> ppc*, sh, sparc, x86
> https://bugs.gentoo.org/show_bug.cgi?id=478082 -> alpha, sparc
> https://bugs.gentoo.org/show_bug.cgi?id=466560 -> s390
>

So, s390 and m68k seem to be the biggest problems in this thread in
general as far as specific examples go, but the list above has some
very stale bugs from a number of the other minor archs.

I really don't think this is a case of one-offs.  Maybe gnome is
especially problematic, but the problem seems to be larger than that.

As I see it we really only have two sustainable options:

1.  Drop stable keywords on these arches wholesale.
2.  Allow maintainers to be more aggressive about dropping stable
packages when bugs are not closed in a reasonable timeframe (say, 90
days).

I suspect that #1 may be inevitable for some of these archs, but I'm
certainly willing to try #2 first and see where that leaves us.  I
don't like the idea of maintainers having to maintain old versions of
things like gnome because arch teams put in some time in years past
but aren't interested in the newer version/etc.

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

Note that if upstream doesn't support an arch, then it falls to the
arch team (and not the maintainer) to support that arch if they want
it stable.

If the problem is limited to particular groups of packages then the
new policy would take care of itself - stable keywords would basically
get dropped until we're down to a set of packages that the arch team
can support.  If the problem is more widespread, then the new policy
will basically make stable unusable on that arch as system packages
get dropped, in which case we're basically back to dropping stable
keywords.

Again, this has nothing to do with picking and choosing arches to
support.  This is about defining the responsibility of arch teams if
they want to be considered stable.  The stable policy is basically a
contract between arch teams and maintainers, and both sides have to do
their part to make it work.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Michał Górny]

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

Dnia 2013-09-15, o godz. 11:03:28
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Thu, Aug 29, 2013 at 1:17 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> > At least from a gnome perspective, we are having some important delays
> > with some arches:
> > - Pending keyword requests:
> > https://bugs.gentoo.org/show_bug.cgi?id=351931 -> sh and sparc
> > https://bugs.gentoo.org/show_bug.cgi?id=478254 -> alpha,arm, ia64, ppc*,
> > sparc
> > https://bugs.gentoo.org/show_bug.cgi?id=478256 -> the same
> > https://bugs.gentoo.org/show_bug.cgi?id=387959 -> sh, sparc
> > https://bugs.gentoo.org/show_bug.cgi?id=469722 -> s390 (this is probably
> > the worst case as they are then having a buggy old version)
> > https://bugs.gentoo.org/show_bug.cgi?id=469982 -> s390
> > https://bugs.gentoo.org/show_bug.cgi?id=471752 -> alpha, ia64, ppc*,
> > sparc
> > https://bugs.gentoo.org/show_bug.cgi?id=472510 -> s390
> > https://bugs.gentoo.org/show_bug.cgi?id=476710 -> alpha, arm, ia64,
> > ppc*, sh, sparc, x86
> > https://bugs.gentoo.org/show_bug.cgi?id=478082 -> alpha, sparc
> > https://bugs.gentoo.org/show_bug.cgi?id=466560 -> s390
> >
> 
> So, s390 and m68k seem to be the biggest problems in this thread in
> general as far as specific examples go, but the list above has some
> very stale bugs from a number of the other minor archs.
> 
> I really don't think this is a case of one-offs.  Maybe gnome is
> especially problematic, but the problem seems to be larger than that.
> 
> As I see it we really only have two sustainable options:
> 
> 1.  Drop stable keywords on these arches wholesale.
> 2.  Allow maintainers to be more aggressive about dropping stable
> packages when bugs are not closed in a reasonable timeframe (say, 90
> days).
> 
> I suspect that #1 may be inevitable for some of these archs, but I'm
> certainly willing to try #2 first and see where that leaves us.  I
> don't like the idea of maintainers having to maintain old versions of
> things like gnome because arch teams put in some time in years past
> but aren't interested in the newer version/etc.

What about their reverse dependencies? Are we dropping them from stable
as well? I'm afraid this will quickly end up quite equivalent to
dropping stable completely, since most of the system won't be stable
anymore. It may also be close to dropping the support for arch
completely.

For example, m68k still didn't handle keywordreq for python-exec or
stablereq on new Python versions. Which means that in some time, we
will be dropping Python from stable m68k (is there a point for stable
m68k at all then?), and then -- due to inability to use new Python
eclasses -- dropping Python from ~m68k as well.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Pacho Ramos]

El dom, 15-09-2013 a las 11:03 -0400, Rich Freeman escribió:
[...]
> As I see it we really only have two sustainable options:
> 
> 1.  Drop stable keywords on these arches wholesale.
> 2.  Allow maintainers to be more aggressive about dropping stable
> packages when bugs are not closed in a reasonable timeframe (say, 90
> days).
> 
> I suspect that #1 may be inevitable for some of these archs, but I'm
> certainly willing to try #2 first and see where that leaves us.  I
> don't like the idea of maintainers having to maintain old versions of
> things like gnome because arch teams put in some time in years past
> but aren't interested in the newer version/etc.
> 
> So, how about this as a policy:
> If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
> pending STABLEREQ, for 90 days with archs CCed and otherwise ready to
> be stabilized, the maintainer can remove older stable versions of the
> package at their discretion.  A package is considered ready to be
> stabilized if it has been in the tree for 30 days, and has no known
> major flaws on arches that upstream considers supported.
> 
> Note that if upstream doesn't support an arch, then it falls to the
> arch team (and not the maintainer) to support that arch if they want
> it stable.
> 
> If the problem is limited to particular groups of packages then the
> new policy would take care of itself - stable keywords would basically
> get dropped until we're down to a set of packages that the arch team
> can support.  If the problem is more widespread, then the new policy
> will basically make stable unusable on that arch as system packages
> get dropped, in which case we're basically back to dropping stable
> keywords.
> 
> Again, this has nothing to do with picking and choosing arches to
> support.  This is about defining the responsibility of arch teams if
> they want to be considered stable.  The stable policy is basically a
> contract between arch teams and maintainers, and both sides have to do
> their part to make it work.
> 
> Rich
> 
> 

I guess an important problem is that, once we drop keywords in a
package, a cascade effect can appear. For example, if we drop stable
keywords of gtk+ and pango due pending keywording, we will need to also
drop a ton of packages. And for cases where we would need to drop the
keywording completely, the situation can be even more difficult. 

I remember long time ago HPPA did an important reduce of keywordings in
that arch (I remember they lost most gnome2 packages), not sure if maybe
other arches could need it too :/

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Sun, Sep 15, 2013 at 11:22 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> El dom, 15-09-2013 a las 11:03 -0400, Rich Freeman escribió:
>>
>> So, how about this as a policy:
>> If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
>> pending STABLEREQ, for 90 days with archs CCed and otherwise ready to
>> be stabilized, the maintainer can remove older stable versions of the
>> package at their discretion.  A package is considered ready to be
>> stabilized if it has been in the tree for 30 days, and has no known
>> major flaws on arches that upstream considers supported.
>>
>> Note that if upstream doesn't support an arch, then it falls to the
>> arch team (and not the maintainer) to support that arch if they want
>> it stable.
>>
> I guess an important problem is that, once we drop keywords in a
> package, a cascade effect can appear. For example, if we drop stable
> keywords of gtk+ and pango due pending keywording, we will need to also
> drop a ton of packages. And for cases where we would need to drop the
> keywording completely, the situation can be even more difficult.

Fully appreciate that.  Given the choice of removing ALL of the stable
keywords, and removing many of the keywords, the latter seems to be a
better choice, at least initially.

However, I do see that as a PITA.  If it becomes a trend, the stable
keywords should be dropped entirely.  Really, it should be the arch
teams themselves that step up and remove their own stable keywords.
For this reason I'm not sure I'd even want to require maintainers to
change any keywords when they remove the last stable version on an
arch - just let the reverse dependencies break and either the arch
team or users will have to clean up the mess (which nobody will see
unless they use that arch).

Ultimately, arch teams need to step up if they want to have stable keywords.

As far as the users go - more need to become developers if they want
to have stable keywords, or pay somebody else to do so on their
behalf.  That's just how things work in a volunteer-based distro.

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Daniel Campbell]

On 09/15/2013 02:03 PM, Rich Freeman wrote:
> As far as the users go - more need to become developers if they want
> to have stable keywords, or pay somebody else to do so on their
> behalf.  That's just how things work in a volunteer-based distro.

As a user, I've considered becoming a developer but the process is
rather contrived and multi-tiered. It doesn't seem like you're becoming
a developer through said process, but rather joining a fraternity.
There's lots of bureacracy involved that really turns prospective
developers off. I don't know how common it is, but if Gentoo has a lack
of developers, there must be a clear reason as to why. Clearly Gentoo
has a lot of avid users *and* developers, so if developers are needed,
perhaps the process to become a developer should be improved. Why else
would the distro be lacking devs if it has a bright and enthusiastic
userbase?

My two cents,

~Daniel

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Pacho Ramos]

El mar, 17-09-2013 a las 21:53 -0500, Daniel Campbell escribió:
> On 09/15/2013 02:03 PM, Rich Freeman wrote:
> > As far as the users go - more need to become developers if they want
> > to have stable keywords, or pay somebody else to do so on their
> > behalf.  That's just how things work in a volunteer-based distro.
> 
> As a user, I've considered becoming a developer but the process is
> rather contrived and multi-tiered. It doesn't seem like you're becoming
> a developer through said process, but rather joining a fraternity.
> There's lots of bureacracy involved that really turns prospective
> developers off. I don't know how common it is, but if Gentoo has a lack
> of developers, there must be a clear reason as to why. Clearly Gentoo
> has a lot of avid users *and* developers, so if developers are needed,
> perhaps the process to become a developer should be improved. Why else
> would the distro be lacking devs if it has a bright and enthusiastic
> userbase?
> 
> My two cents,
> 
> ~Daniel
> 

Could you please be a bit more specific? Maybe we could improve that :/

Is it a problem with quizzes and some of its questions? If I don't
misremember, there was some kind of recruitment tool in progress, but
not sure how ready it is

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Sergey Popov]

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

18.09.2013 06:53, Daniel Campbell пишет:
> As a user, I've considered becoming a developer but the process is
> rather contrived and multi-tiered. It doesn't seem like you're becoming
> a developer through said process, but rather joining a fraternity.
> There's lots of bureacracy involved that really turns prospective
> developers off. I don't know how common it is, but if Gentoo has a lack
> of developers, there must be a clear reason as to why. Clearly Gentoo
> has a lot of avid users *and* developers, so if developers are needed,
> perhaps the process to become a developer should be improved. Why else
> would the distro be lacking devs if it has a bright and enthusiastic
> userbase?
> 
> My two cents,
> 
> ~Daniel
> 

As a long standing user and no-so-longstanding(~1 year) developer i can
say this - the recruitment process seems daunting, but all that things
with quizes guarantee that new developer does not shoot in the knee in
his first day with commit access to portage tree.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Daunting developer process? (was Re: [gentoo-project] Call for agenda items - Council meeting) 2013-09-10

[Sven Vermeulen]

On Tue, Sep 17, 2013 at 09:53:22PM -0500, Daniel Campbell wrote:
> As a user, I've considered becoming a developer but the process is
> rather contrived and multi-tiered. It doesn't seem like you're becoming
> a developer through said process, but rather joining a fraternity.
> There's lots of bureacracy involved that really turns prospective
> developers off. I don't know how common it is, but if Gentoo has a lack
> of developers, there must be a clear reason as to why. Clearly Gentoo
> has a lot of avid users *and* developers, so if developers are needed,
> perhaps the process to become a developer should be improved. Why else
> would the distro be lacking devs if it has a bright and enthusiastic
> userbase?

The process looks daunting at first, but in my opinion it is not as "hard"
as it is often seen. Yes, we work with questions & answers to make sure
proper knowledge is in place. But these questions are not all that difficult
if you already have experience with ebuild creation & development (assuming
you're talking about the ebuild developer quizzes, not the staff quizzes).

Of course, if you have no experience with it and want to get developer
access, then immediately focusing on the quizzes is the wrong approach. Try
to help where possible with bug fixing and contributing ebuilds - you don't
need CVS (yeah, still CVS) access to do so.

An important part of joining the Gentoo crew is to work with others - work
with your mentor, interact with the recruiters, etc - because, as with every
free software project, we are all a bunch of individuals whose actions can
impact others.

Gentoo currently has 245 active developers. That is not a small amount.
Ubuntu is at 210, Debian has many more (I tried to parse
http://www.debian.org/devel/people and was over 2000).

Using a different approach to gain more developers might have more impact
than you imagine on the quality of the distribution as well as the progress
it makes. If the distribution would be 12 developers, it wouldn't be all
that hard to make a good roadmap and focus areas. Twelve people can easily
decide amongst each other what to do. But 200+ developers is a different
ballgame (hence the need for "bureaucratic" things like the Gentoo Council)
where decisions need to be weighted and where every individual can
contribute (or block) to the progress of the distribution.

Imagine what would happen if we had 500+ developers. 

Wkr,
	Sven Vermeulen

Re: Daunting developer process? (was Re: [gentoo-project] Call for agenda items - Council meeting) 2013-09-10

[Markos Chandras]

On 18 September 2013 09:02, Sven Vermeulen <swift@gentoo.org> wrote:
> On Tue, Sep 17, 2013 at 09:53:22PM -0500, Daniel Campbell wrote:
>> As a user, I've considered becoming a developer but the process is
>> rather contrived and multi-tiered. It doesn't seem like you're becoming
>> a developer through said process, but rather joining a fraternity.
>> There's lots of bureacracy involved that really turns prospective
>> developers off. I don't know how common it is, but if Gentoo has a lack
>> of developers, there must be a clear reason as to why. Clearly Gentoo
>> has a lot of avid users *and* developers, so if developers are needed,
>> perhaps the process to become a developer should be improved. Why else
>> would the distro be lacking devs if it has a bright and enthusiastic
>> userbase?
>
> The process looks daunting at first, but in my opinion it is not as "hard"
> as it is often seen. Yes, we work with questions & answers to make sure
> proper knowledge is in place. But these questions are not all that difficult
> if you already have experience with ebuild creation & development (assuming
> you're talking about the ebuild developer quizzes, not the staff quizzes).
>
> Of course, if you have no experience with it and want to get developer
> access, then immediately focusing on the quizzes is the wrong approach. Try
> to help where possible with bug fixing and contributing ebuilds - you don't
> need CVS (yeah, still CVS) access to do so.
>
> An important part of joining the Gentoo crew is to work with others - work
> with your mentor, interact with the recruiters, etc - because, as with every
> free software project, we are all a bunch of individuals whose actions can
> impact others.
>
> Gentoo currently has 245 active developers. That is not a small amount.
> Ubuntu is at 210, Debian has many more (I tried to parse
> http://www.debian.org/devel/people and was over 2000).
>
> Using a different approach to gain more developers might have more impact
> than you imagine on the quality of the distribution as well as the progress
> it makes. If the distribution would be 12 developers, it wouldn't be all
> that hard to make a good roadmap and focus areas. Twelve people can easily
> decide amongst each other what to do. But 200+ developers is a different
> ballgame (hence the need for "bureaucratic" things like the Gentoo Council)
> where decisions need to be weighted and where every individual can
> contribute (or block) to the progress of the distribution.
>
> Imagine what would happen if we had 500+ developers.
>
> Wkr,
>         Sven Vermeulen
>

We have been through the same discussion over and over again and it
usually starts by users
who think that the process is mostly non-sense and part of the 19th century.
What Sven said is mostly true. Most users tend to focus too much on the
"theoretical" part of the recruitment (aka the quizzes) but they don't
actually see beyond that.

The quizzes might be "hard" or "long" at first look, but *if* you have
been part of the community for
a not-so-long time, you will notice that you can probably answer all
the questions within 2 hours tops!
What this means is that, you can't just become a developer out of the
blue with the expectation to be an
easy process just because you understand what 'emerge' does and what
package.accept_keywords is for.

If this is how you think, then you clearly are not ready to become a developer.
However, if you try to make some real contributions to the project,
get involved with teams and the mailing lists,
you will notice that most of the questions make sense, and having them
in the quizzes is the correct thing.

Of course, I don't expect my reply to prevent similar threads in the
future but maybe someone could point "scared"
users to this thread and make them realize that they need to do their
homework before they go blame the process
without concrete evidences.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

[gentoo-project] Re: Daunting developer process? (was Re: Call for agenda items - Council meeting) 2013-09-10

[Steven J. Long]

On Wed, Sep 18, Sven Vermeulen wrote:
> Using a different approach to gain more developers might have more impact
> than you imagine on the quality of the distribution as well as the progress
> it makes. If the distribution would be 12 developers, it wouldn't be all
> that hard to make a good roadmap and focus areas. Twelve people can easily
> decide amongst each other what to do. But 200+ developers is a different
> ballgame (hence the need for "bureaucratic" things like the Gentoo Council)
> where decisions need to be weighted and where every individual can
> contribute (or block) to the progress of the distribution.
> 
> Imagine what would happen if we had 500+ developers. 

Thanks you for a wonderfully succinct explanation of the damage that would
be done if Gentoo developer status were awarded to people who did not 
nderstand how to develop the end-product, eg: out of deference to technical
knowledge in other domains.

Can I ask that you paste the whole text of your response into the Gentoo
docs site somewhere? This comes up so often, on the forums and on IRC, it
would help to have it where people will see it. Personally I'd paste it at
the top of the devmanual front-page, so giving someone the link to that also
ensures they are looking at it. Your call, ofc.

Regards,
steveL.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-project] Re: Daunting developer process? (was Re: Call for agenda items - Council meeting) 2013-09-10

[Tom Wijsman]

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

On Wed, 18 Sep 2013 13:18:28 +0100
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> On Wed, Sep 18, Sven Vermeulen wrote:
> > Using a different approach to gain more developers might have more
> > impact than you imagine on the quality of the distribution as well
> > as the progress it makes. If the distribution would be 12
> > developers, it wouldn't be all that hard to make a good roadmap and
> > focus areas. Twelve people can easily decide amongst each other
> > what to do. But 200+ developers is a different ballgame (hence the
> > need for "bureaucratic" things like the Gentoo Council) where
> > decisions need to be weighted and where every individual can
> > contribute (or block) to the progress of the distribution.
> > 
> > Imagine what would happen if we had 500+ developers. 
> 
> Thanks you for a wonderfully succinct explanation of the damage that
> would be done if Gentoo developer status were awarded to people who
> did not nderstand how to develop the end-product, eg: out of
> deference to technical knowledge in other domains.

Yes, the process that is in place is there to avoid people from rushing
in only to be met with an unhappy community because they made some
unintended change that doesn't meet earlier policy or consensus that
is in place to avoid such damaging changes in the first place; we've
had people ask for straight CVS access in the past (and even locked
forum discussions) for just applying one ore another fix, but you guess
how making a commit without knowing the context can lead to disasters.

> Can I ask that you paste the whole text of your response into the
> Gentoo docs site somewhere? This comes up so often, on the forums and
> on IRC, it would help to have it where people will see it. Personally
> I'd paste it at the top of the devmanual front-page, so giving
> someone the link to that also ensures they are looking at it. Your
> call, ofc.

At verbatim at the top of the devmanual doesn't really look neat out of
the context of this discussion, but I guess you didn't mean it to be
exact; looking at what we already have in place I see this in the
Developer Handbook [1]:

    The aim of this handbook is to outline Gentoo development policies,
    and make you, the developer, informed of policies, standards and
    procedures which Gentoo considers to be core values of our
    development system.

And people are warned up front in the Ebuild policy [2]:

    Be cautious about what you commit. Remember that your commits can
    potentially harm thousands of users. If your commits cause any
    breakage in the tree, they must be fixed in a timely fashion.

And in the Etiquette policy [3]:

    That doesn't mean that we expect you to follow this guide to the
    bullet point; nor do we expect you even agree with it - we do
    expect, however that all developers maintain reasonable standards
    of behaviour with our community - whether to other developers or
    users. However, you may be subject to sanctions or a suspension if
    a reasonable standard is not met.

But I agree with you that there doesn't seem to be the "why" part to
why people should read the Developer Handbook; but then one might
wonder if such "why" part needs to be there in the first place, because
if people aren't interested in reading (and thus following) any
policies, then how can we expect them to not harm the community?

If they question it, then I feel like it is fine to inform them why we
expect them to follow the process; but telling them up front that not
reading it causes harm feels like a negative connotation, which could
scare people from contributing in the first place.

For that reason, they actually do not detail the process too much; we
want people to join with a positive mood that they learned something,
not with "the process is lengthy and boring" or "wow, finally, meh".

Looking back at it, most of us can be glad the process is in place.

As for the Development Manual; I feel like we could refer [4] to the
Developer Handbook so people that don't know about it could find it,
but I don't think Developer Handbook information itself belongs there.

 [1]: Developer Handbook - Introduction
 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=1

 [2]: Developer Handbook - Ebuild policy
 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1

 [3]: Developer Handbook - Etiquette policy
 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=2

 [4]: GitHub Pull Request - Add a reference to Gentoo Developer Handbook
 https://github.com/gentoo/devmanual.gentoo.org/pull/9

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[heroxbd]

Hey Daniel,

Daniel Campbell <lists@sporkbox.us> writes:

> As a user, I've considered becoming a developer but the process is
> rather contrived and multi-tiered. 

Would you like to try again? Where did you get stuck last time?

> It doesn't seem like you're becoming a developer through said process,
> but rather joining a fraternity.  There's lots of bureacracy involved
> that really turns prospective developers off. 

As a young developer (less than 2 years), I feel the process
reasonable. The quiz, the bug report, how you communicate... I feel
they're educative rather than bureaucratic.

> I don't know how common it is, but if Gentoo has a lack of developers,
> there must be a clear reason as to why. 

The reason is that we need to give more encouragement to our users to
became a developer, IMHO.

> Clearly Gentoo has a lot of avid users *and* developers, so if
> developers are needed, perhaps the process to become a developer
> should be improved. Why else would the distro be lacking devs if it
> has a bright and enthusiastic userbase?

Right! Therefore I think every developer should keep a sharp eye on the
prospective developers he works with, and encourage her to join Gentoo
as a developer at a proper chance.

Cheers,
Benda

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Daniel Campbell]

On 09/18/2013 05:42 AM, heroxbd@gentoo.org wrote:
> Hey Daniel,
> 
> Daniel Campbell <lists@sporkbox.us> writes:
> 
>> As a user, I've considered becoming a developer but the process is
>> rather contrived and multi-tiered. 
> 
> Would you like to try again? Where did you get stuck last time?
> 

The organizational and social aspects of it pushed me away the most. I'm
completely okay with a test that ensures that you either know what
you're doing or are resourceful enough to figure it out when in doubt.
It's Gentoo as an organization that seems foreboding and intimidating.
One must wonder if they should bother applying, if they're good enough,
if a mistake would end the work they put in to become a developer, etc.

Additionally, I couldn't really come up with a solid goal to work on; an
answer to "why do you want to become a developer?" My computing
interests lie in problems that are already solved for the most part (IOW
I don't know how to find an unsolved problem). My favorite software
already has capable maintainers on Gentoo, as well. So if I found myself
as a developer, I don't know what I would work on. I'm interested in
writing better guides for things, making corrections, updating out-dated
stuff, and wouldn't mind adding new packages to portage, but that
strikes me as something general that all developers pretty much do already.

I've thought about giving it a try, but I don't want to waste people's
time if someone more useful applies. This conflicts with my desire to
learn and improve, because you can't learn everything alone. So I'm stuck.

Sorry for the long, personal answer. I would've responded sooner but I
wanted to give the question some thought.

>> It doesn't seem like you're becoming a developer through said process,
>> but rather joining a fraternity.  There's lots of bureacracy involved
>> that really turns prospective developers off. 
> 
> As a young developer (less than 2 years), I feel the process
> reasonable. The quiz, the bug report, how you communicate... I feel
> they're educative rather than bureaucratic.
> 
>> I don't know how common it is, but if Gentoo has a lack of developers,
>> there must be a clear reason as to why. 
> 
> The reason is that we need to give more encouragement to our users to
> became a developer, IMHO.
> 
>> Clearly Gentoo has a lot of avid users *and* developers, so if
>> developers are needed, perhaps the process to become a developer
>> should be improved. Why else would the distro be lacking devs if it
>> has a bright and enthusiastic userbase?
> 
> Right! Therefore I think every developer should keep a sharp eye on the
> prospective developers he works with, and encourage her to join Gentoo
> as a developer at a proper chance.
> 
> Cheers,
> Benda
> 

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Pacho Ramos]

El mié, 18-09-2013 a las 23:33 -0500, Daniel Campbell escribió:
[...]
> Additionally, I couldn't really come up with a solid goal to work on; an
> answer to "why do you want to become a developer?" My computing
> interests lie in problems that are already solved for the most part (IOW
> I don't know how to find an unsolved problem). My favorite software
> already has capable maintainers on Gentoo, as well. So if I found myself
> as a developer, I don't know what I would work on. I'm interested in
> writing better guides for things, making corrections, updating out-dated
> stuff, and wouldn't mind adding new packages to portage, but that
> strikes me as something general that all developers pretty much do already.

Maybe you could help in things like maintainer-needed alias -> that
requires to fix some random stuff from time to time, make bumps... Apart
of that, on what areas/teams are you interested?

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Daniel Campbell]

On 09/19/2013 01:07 AM, Pacho Ramos wrote:
> El mié, 18-09-2013 a las 23:33 -0500, Daniel Campbell escribió:
> [...]
>> Additionally, I couldn't really come up with a solid goal to work on; an
>> answer to "why do you want to become a developer?" My computing
>> interests lie in problems that are already solved for the most part (IOW
>> I don't know how to find an unsolved problem). My favorite software
>> already has capable maintainers on Gentoo, as well. So if I found myself
>> as a developer, I don't know what I would work on. I'm interested in
>> writing better guides for things, making corrections, updating out-dated
>> stuff, and wouldn't mind adding new packages to portage, but that
>> strikes me as something general that all developers pretty much do already.
> 
> Maybe you could help in things like maintainer-needed alias -> that
> requires to fix some random stuff from time to time, make bumps... Apart
> of that, on what areas/teams are you interested?
> 
> 

Helping out on packages that don't get much attention could be
gratifying. I don't think I'd mind that, depending on how difficult the
packages are to maintain. :p

I really don't know which teams or areas I'm interested in. I think my
current skills predispose me to documentation or tree cleaning. Sunrise
sounds interesting too, as does QA. I think I'd have to try my hand at
them to determine if I'd be useful to those projects.

Gaming is fairly important to me, too... I could help add or maintain
games that'll run on Gentoo. It's really a blank slate to me.

On that note, I spent early morning today completing the ebuild quiz.
I'm not sure if it's ready for review yet, or what I need to do to
submit it. Guess I'll have to look that up, too. :)

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Pacho Ramos]

El jue, 19-09-2013 a las 08:21 -0500, Daniel Campbell escribió:
> On 09/19/2013 01:07 AM, Pacho Ramos wrote:
> > El mié, 18-09-2013 a las 23:33 -0500, Daniel Campbell escribió:
> > [...]
> >> Additionally, I couldn't really come up with a solid goal to work on; an
> >> answer to "why do you want to become a developer?" My computing
> >> interests lie in problems that are already solved for the most part (IOW
> >> I don't know how to find an unsolved problem). My favorite software
> >> already has capable maintainers on Gentoo, as well. So if I found myself
> >> as a developer, I don't know what I would work on. I'm interested in
> >> writing better guides for things, making corrections, updating out-dated
> >> stuff, and wouldn't mind adding new packages to portage, but that
> >> strikes me as something general that all developers pretty much do already.
> > 
> > Maybe you could help in things like maintainer-needed alias -> that
> > requires to fix some random stuff from time to time, make bumps... Apart
> > of that, on what areas/teams are you interested?
> > 
> > 
> 
> Helping out on packages that don't get much attention could be
> gratifying. I don't think I'd mind that, depending on how difficult the
> packages are to maintain. :p

It depends on each package, when I had time to take care of
maintainer-needed bugs (not much currently :S), I simply reviewed the
opened bugs against them and tried to fix some ;)

[...]
> Gaming is fairly important to me, too... I could help add or maintain
> games that'll run on Gentoo. It's really a blank slate to me.
> 

Maybe could be an option, others are the things you use frequently :)

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Dirkjan Ochtman]

On Thu, Sep 19, 2013 at 6:33 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> The organizational and social aspects of it pushed me away the most. I'm
> completely okay with a test that ensures that you either know what
> you're doing or are resourceful enough to figure it out when in doubt.
> It's Gentoo as an organization that seems foreboding and intimidating.
> One must wonder if they should bother applying, if they're good enough,
> if a mistake would end the work they put in to become a developer, etc.

That seems worrying. Can you give more of an expression of the kind of
thing where you get this impression?

> Additionally, I couldn't really come up with a solid goal to work on; an
> answer to "why do you want to become a developer?" My computing
> interests lie in problems that are already solved for the most part (IOW
> I don't know how to find an unsolved problem). My favorite software
> already has capable maintainers on Gentoo, as well. So if I found myself
> as a developer, I don't know what I would work on. I'm interested in
> writing better guides for things, making corrections, updating out-dated
> stuff, and wouldn't mind adding new packages to portage, but that
> strikes me as something general that all developers pretty much do already.
>
> I've thought about giving it a try, but I don't want to waste people's
> time if someone more useful applies. This conflicts with my desire to
> learn and improve, because you can't learn everything alone. So I'm stuck.
>
> Sorry for the long, personal answer. I would've responded sooner but I
> wanted to give the question some thought.

Thank you for giving the long, personal answer! I think it's very
useful to hear. I also think that anyone willing to think about
something like this or who can explain it this way on this mailing
list should most definitely be a developer, because you're so
obviously motivated to make Gentoo even better than it already is.
AFAICT the documentation team is definitely understaffed, so helping
out there would be an obvious win. Just fixing bugs and updating
out-dated packages would also be very welcome. Please apply, I'm
personally happy to be your mentor if you do (find me on IRC or email
me personally if you're interested). Don't be afraid of "wasting" my
time, you can easily repay it by making Gentoo better.

Cheers,

Dirkjan

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Tom Wijsman]

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

On Wed, 18 Sep 2013 23:33:47 -0500
Daniel Campbell <lists@sporkbox.us> wrote:

> On 09/18/2013 05:42 AM, heroxbd@gentoo.org wrote:
> > Hey Daniel,
> > 
> > Daniel Campbell <lists@sporkbox.us> writes:
> > 
> >> As a user, I've considered becoming a developer but the process is
> >> rather contrived and multi-tiered. 
> > 
> > Would you like to try again? Where did you get stuck last time?
> > 
> 
> The organizational and social aspects of it pushed me away the most.
> I'm completely okay with a test that ensures that you either know what
> you're doing or are resourceful enough to figure it out when in doubt.
> It's Gentoo as an organization that seems foreboding and intimidating.
> One must wonder if they should bother applying, if they're good
> enough, if a mistake would end the work they put in to become a
> developer, etc.

It kind of depends on how you think about it; if I were to wrote the
a paragraph about the same matter, but in a different way it would be:

The organizational and social aspects is what would attract me the most.
I'm not okay with a test that just ensures that you know what you do or
are resourceful enough to figure things out when in doubt; no, I would
love Gentoo as an organization to help me obtain more experience on top
of that. One shouldn't bother about being good enough for applying, the
recruitment helps ensure that the most mistakes aren't made.

In other words, you shouldn't see the recruitment quiz and reviews as a
driver exam where you either pass or fail; no, we let you test drive on
a consolidated piece of the world and open the gates to the real world
once you have become acquainted and sharpened your driving skills.

If you then make a careful accidental mistake, no need to worry.

> Additionally, I couldn't really come up with a solid goal to work on;
> an answer to "why do you want to become a developer?" My computing
> interests lie in problems that are already solved for the most part
> (IOW I don't know how to find an unsolved problem). My favorite
> software already has capable maintainers on Gentoo, as well.

Yes, that's one of the reasons people apply; but with the amount of
developers for most software that's going to be true. Regardless of
that, a particular piece of software being already maintained doesn't
mean that you can't help maintain them; there's always something to do
in those areas so manpower is often welcome. Contacting the people to
see if there are things to do, whether you could join a herd (or
maintain a package) once you become a Gentoo Developer and more are
possible things you could do; don't assume that they will say "no". :) 

> So if I
> found myself as a developer, I don't know what I would work on. I'm
> interested in writing better guides for things, making corrections,
> updating out-dated stuff, and wouldn't mind adding new packages to
> portage, but that strikes me as something general that all developers
> pretty much do already.

Yes, that's the second reason; helping out people or giving back to the
community are things you could do, and if you want to do just that
there's certainly always something to do in that terrain.

> I've thought about giving it a try, but I don't want to waste people's
> time if someone more useful applies. This conflicts with my desire to
> learn and improve, because you can't learn everything alone. So I'm
> stuck.

We don't rank our developers; so, if you maintain a particular package
or are part of a particular herd you won't be removed from that any
time soon and I see no reason that it would be a waste of time.
Everything you do helps yourself as well as Gentoo Linux; even if you
don't think it does, it actually does; both gain experience.

> Sorry for the long, personal answer. I would've responded sooner but I
> wanted to give the question some thought.

No problem, you also clarify matters for other possible future recruits
so this could perhaps be used as a sub thread to point people with such
wonders to in the future. Or we could capture this into the Gentoo Wiki.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Daniel Campbell]

On 09/19/2013 07:37 AM, Tom Wijsman wrote:
> On Wed, 18 Sep 2013 23:33:47 -0500
> Daniel Campbell <lists@sporkbox.us> wrote:
> 
>> On 09/18/2013 05:42 AM, heroxbd@gentoo.org wrote:
>>> Hey Daniel,
>>>
>>> Daniel Campbell <lists@sporkbox.us> writes:
>>>
>>>> As a user, I've considered becoming a developer but the process is
>>>> rather contrived and multi-tiered. 
>>>
>>> Would you like to try again? Where did you get stuck last time?
>>>
>>
>> The organizational and social aspects of it pushed me away the most.
>> I'm completely okay with a test that ensures that you either know what
>> you're doing or are resourceful enough to figure it out when in doubt.
>> It's Gentoo as an organization that seems foreboding and intimidating.
>> One must wonder if they should bother applying, if they're good
>> enough, if a mistake would end the work they put in to become a
>> developer, etc.
> 
> It kind of depends on how you think about it; if I were to wrote the
> a paragraph about the same matter, but in a different way it would be:
> 
> The organizational and social aspects is what would attract me the most.
> I'm not okay with a test that just ensures that you know what you do or
> are resourceful enough to figure things out when in doubt; no, I would
> love Gentoo as an organization to help me obtain more experience on top
> of that. One shouldn't bother about being good enough for applying, the
> recruitment helps ensure that the most mistakes aren't made.
> 
> In other words, you shouldn't see the recruitment quiz and reviews as a
> driver exam where you either pass or fail; no, we let you test drive on
> a consolidated piece of the world and open the gates to the real world
> once you have become acquainted and sharpened your driving skills.
> 
> If you then make a careful accidental mistake, no need to worry.
> 

That's a bit reassuring. It's difficult to understand an organization
from the outside, so forgive me if I (or others) get the wrong idea.

>> Additionally, I couldn't really come up with a solid goal to work on;
>> an answer to "why do you want to become a developer?" My computing
>> interests lie in problems that are already solved for the most part
>> (IOW I don't know how to find an unsolved problem). My favorite
>> software already has capable maintainers on Gentoo, as well.
> 
> Yes, that's one of the reasons people apply; but with the amount of
> developers for most software that's going to be true. Regardless of
> that, a particular piece of software being already maintained doesn't
> mean that you can't help maintain them; there's always something to do
> in those areas so manpower is often welcome. Contacting the people to
> see if there are things to do, whether you could join a herd (or
> maintain a package) once you become a Gentoo Developer and more are
> possible things you could do; don't assume that they will say "no". :) 
> 
>> So if I
>> found myself as a developer, I don't know what I would work on. I'm
>> interested in writing better guides for things, making corrections,
>> updating out-dated stuff, and wouldn't mind adding new packages to
>> portage, but that strikes me as something general that all developers
>> pretty much do already.
> 
> Yes, that's the second reason; helping out people or giving back to the
> community are things you could do, and if you want to do just that
> there's certainly always something to do in that terrain.
> 
>> I've thought about giving it a try, but I don't want to waste people's
>> time if someone more useful applies. This conflicts with my desire to
>> learn and improve, because you can't learn everything alone. So I'm
>> stuck.
> 
> We don't rank our developers; so, if you maintain a particular package
> or are part of a particular herd you won't be removed from that any
> time soon and I see no reason that it would be a waste of time.
> Everything you do helps yourself as well as Gentoo Linux; even if you
> don't think it does, it actually does; both gain experience.
> 
>> Sorry for the long, personal answer. I would've responded sooner but I
>> wanted to give the question some thought.
> 
> No problem, you also clarify matters for other possible future recruits
> so this could perhaps be used as a sub thread to point people with such
> wonders to in the future. Or we could capture this into the Gentoo Wiki.
> 

Thanks for the clarification and insight. I don't mind if you use
content from this discussion on the wiki or other documentation to
better educate users. This list probably doesn't get a lot of user
exposure, so something meant for their eyes could change the mindset of
some users and motivate them to step up and lighten the load.

My apologies to Rich for derailing the thread. It's a habit I'm trying
to get rid of.

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Ciaran McCreesh]

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

On Sun, 15 Sep 2013 11:03:28 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> So, how about this as a policy:
> If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
> pending STABLEREQ, for 90 days with archs CCed and otherwise ready to
> be stabilized, the maintainer can remove older stable versions of the
> package at their discretion.  A package is considered ready to be
> stabilized if it has been in the tree for 30 days, and has no known
> major flaws on arches that upstream considers supported.

The danger of this approach is that it encourages arch teams to stable
even if they're not convinced something's been tested sufficiently.

-- 
Ciaran McCreesh

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Sun, Sep 15, 2013 at 3:08 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 15 Sep 2013 11:03:28 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>> So, how about this as a policy:
>> If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
>> pending STABLEREQ, for 90 days with archs CCed and otherwise ready to
>> be stabilized, the maintainer can remove older stable versions of the
>> package at their discretion.  A package is considered ready to be
>> stabilized if it has been in the tree for 30 days, and has no known
>> major flaws on arches that upstream considers supported.
>
> The danger of this approach is that it encourages arch teams to stable
> even if they're not convinced something's been tested sufficiently.

My understanding is that half the "stable" packages on the arches in
question are only compile-tested anyway.  If we do drop the keywords
then users will only have the choice of running packages that aren't
stable-tested at all.

I don't really see my proposal as an ideal one - merely a compromise
that seems better than the alternatives.  The only thing that will
actually improve the true quality of the minor arches is more
manpower.  If you're running s390/sparc/whatever then frankly there
aren't really many better options out there, so you might as well
pitch in and help scratch your own itch...

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[hasufell]

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

I want the council to make clear whether useflags that are:

* unsupported by the maintainer
* are known to break the build or application at runtime
* introduce security vulnerabilities

are allowed to remain unmasked in stable packages.


- --
reference bug: https://bugs.gentoo.org/show_bug.cgi?id=482112
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSHfE3AAoJEFpvPKfnPDWzrgAH/igNjf8IHgKf3EEo8eUiPBoo
DxJnWto6cRya/MzEbtlbLC6InTKlEeNGu1X3SH56UfvgJznhwUssf2cCp2/mZ6Sc
aNSm43KGogbZxistSEVyG1GGl/zxavUKQYW91N7X3C8xsOZw/s7gK0zL+KDdtILF
tMMPRcnDg3HII17osMdBHeVWeyX9NeZhoShQGf4hUpA++Qgaf3l/B+hqFU9LTMw9
3J+NBAOfTVtOLVjaRFU32UThv72ZfUdybAKrGFESFWredZbOjR+iSU9xFsXIIAQo
jzwj8anvhjRYfoBHrQcd+xlMMDzMBRMXsKcjEjWD7EUNFE6kWeCHxPP1Go972hc=
=4GIB
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Ulrich Mueller]

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

>>>>> On Wed, 28 Aug 2013, hasufell  wrote:

> I want the council to make clear whether useflags that are:

> * unsupported by the maintainer
> * are known to break the build or application at runtime
> * introduce security vulnerabilities

> are allowed to remain unmasked in stable packages.


> - --
> reference bug: https://bugs.gentoo.org/show_bug.cgi?id=482112

As far as I can see, this concerns a single package only. So please
try to resolve through project lead and QA team, as outlined in
GLEP 48. If you disagree with the QA team's resolution, _then_ you may
appeal to the council.

Not adding to next meeting's agenda.

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[hasufell]

On 08/28/2013 03:18 PM, Ulrich Mueller wrote:
>>>>>> On Wed, 28 Aug 2013, hasufell  wrote:
> 
>> I want the council to make clear whether useflags that are:
> 
>> * unsupported by the maintainer
>> * are known to break the build or application at runtime
>> * introduce security vulnerabilities
> 
>> are allowed to remain unmasked in stable packages.
> 
> 
>> - --
>> reference bug: https://bugs.gentoo.org/show_bug.cgi?id=482112
> 
> As far as I can see, this concerns a single package only. So please
> try to resolve through project lead and QA team, as outlined in
> GLEP 48. If you disagree with the QA team's resolution, _then_ you may
> appeal to the council.
> 
> Not adding to next meeting's agenda.
> 
> Ulrich
> 

No, it does not concern a single package only. This is about making a
clear policy. There are more examples of packages with broken useflags
such as app-editors/nano[debug] or other "vanilla" useflags for glibc
and so on which are all in STABLE branch.

This was already discussed in #gentoo-qa and it seems there is no clear
consensus about the issue. That's where the council has to make a call.

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Ulrich Mueller]

>>>>> On Wed, 28 Aug 2013, hasufell  wrote:

> No, it does not concern a single package only. This is about making
> a clear policy. There are more examples of packages with broken
> useflags such as app-editors/nano[debug] or other "vanilla" useflags
> for glibc and so on which are all in STABLE branch.

> This was already discussed in #gentoo-qa and it seems there is no
> clear consensus about the issue. That's where the council has to
> make a call.

As I said, get a resolution from QA first, before escalating to the
council. The procedure for this is clearly outlined in GLEP 48.

Ulrich

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Patrick Lauer]

On 08/29/2013 01:02 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 28 Aug 2013, hasufell  wrote:
> 
>> No, it does not concern a single package only. This is about making
>> a clear policy. There are more examples of packages with broken
>> useflags such as app-editors/nano[debug] or other "vanilla" useflags
>> for glibc and so on which are all in STABLE branch.
> 
>> This was already discussed in #gentoo-qa and it seems there is no
>> clear consensus about the issue. That's where the council has to
>> make a call.
> 
> As I said, get a resolution from QA first, before escalating to the
> council. The procedure for this is clearly outlined in GLEP 48.
> 
QA policy has always been "if it doesn't compile either fix it or mask it"

I don't even see why this needs discussion.

Do not expose users to breakage, OR ELSE (or else someone will fix it
for you)

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Rich Freeman]

On Wed, Aug 28, 2013 at 10:09 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 08/29/2013 01:02 AM, Ulrich Mueller wrote:
>>>>>>> On Wed, 28 Aug 2013, hasufell  wrote:
>>
>>> No, it does not concern a single package only. This is about making
>>> a clear policy. There are more examples of packages with broken
>>> useflags such as app-editors/nano[debug] or other "vanilla" useflags
>>> for glibc and so on which are all in STABLE branch.
>>
>>> This was already discussed in #gentoo-qa and it seems there is no
>>> clear consensus about the issue. That's where the council has to
>>> make a call.
>>
>> As I said, get a resolution from QA first, before escalating to the
>> council. The procedure for this is clearly outlined in GLEP 48.
>>
> QA policy has always been "if it doesn't compile either fix it or mask it"
>
> I don't even see why this needs discussion.
>
> Do not expose users to breakage, OR ELSE (or else someone will fix it
> for you)

Agree, but if this was discussed in #gentoo-qa and there was no clear
consensus then I suspect that there is more to the issue than meets
the eye.  From what was written in the bug comments this seems like a
no-brainer at first glance.

I think that existing policy and common sense should cover this.
However, if there is some nuance that needs consideration by all means
bring it up.

What are QA's feelings on the matter?

Rich

Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[hasufell]

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

On 08/29/2013 01:21 PM, Rich Freeman wrote:
> On Wed, Aug 28, 2013 at 10:09 PM, Patrick Lauer
> <patrick@gentoo.org> wrote:
>> On 08/29/2013 01:02 AM, Ulrich Mueller wrote:
>>>>>>>> On Wed, 28 Aug 2013, hasufell  wrote:
>>> 
>>>> No, it does not concern a single package only. This is about
>>>> making a clear policy. There are more examples of packages
>>>> with broken useflags such as app-editors/nano[debug] or other
>>>> "vanilla" useflags for glibc and so on which are all in
>>>> STABLE branch.
>>> 
>>>> This was already discussed in #gentoo-qa and it seems there
>>>> is no clear consensus about the issue. That's where the
>>>> council has to make a call.
>>> 
>>> As I said, get a resolution from QA first, before escalating to
>>> the council. The procedure for this is clearly outlined in GLEP
>>> 48.
>>> 
>> QA policy has always been "if it doesn't compile either fix it or
>> mask it"
>> 
>> I don't even see why this needs discussion.
>> 
>> Do not expose users to breakage, OR ELSE (or else someone will
>> fix it for you)
> 
> Agree, but if this was discussed in #gentoo-qa and there was no
> clear consensus then I suspect that there is more to the issue than
> meets the eye.  From what was written in the bug comments this
> seems like a no-brainer at first glance.
> 
> I think that existing policy and common sense should cover this. 
> However, if there is some nuance that needs consideration by all
> means bring it up.
> 
> What are QA's feelings on the matter?
> 
> Rich
> 

The QA lead didn't respond yet, but I tried to raise his attention.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSH06VAAoJEFpvPKfnPDWzu6kH/ioge0WrLmOZoSzRJgusErRQ
cbgcKeGCe2BTIJsoC2KfDO6oBHaCdYVkwJBiVFIFaCBk0DchqOjBL0UgmEnwxSYp
/8GF29aNuYTETz553vJ6BP7NDLedm9m8t/unTPAPv9JeyD0gg8Gdi4hFfg0y3TOz
4HlTd9rQ3KUYjg8U9RNOUN1pLIFtSsV603Vn3GErtsMeeR6vcvDydQg4GfxeSF6T
gYQpfkasEAOAb+DjBeB9eryptr4tFjx6Hb+GjPIdC5H6gn8HhhIPYjNYpIrx8QMA
CQSWWeefYW4jJkNs/etnjDaNSyI/KLRhIfa0KJ+gy8YgGB795y6kbhijiuw1ypE=
=noh0
-----END PGP SIGNATURE-----

[gentoo-project] Re: Call for agenda items - Council meeting 2013-09-10

[Ulrich Mueller]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 47 bytes --]

Forwarding a message from <heroxbd@gmail.com>.

[-- Attachment #2: forwarded message --]
[-- Type: message/rfc822, Size: 847 bytes --]

From: heroxbd@gmail.com
To: ulm@gentoo.org
Subject: Re: Call for agenda items - Council meeting 2013-09-10
Date: Thu, 29 Aug 2013 00:46:08 +0900
Message-ID: <8638pp51iz.fsf@moguhome00.in.awa.tohoku.ac.jp>

Dear Ulrich,

I cannot send emails to gentoo-project list, as in bug 483046. I hereby
reply this to you. Feel free to help me forward it to gentoo-project.


I'd like to ask the council to review the GLEP draft on RAP posted in
gentoo-dev before:

    http://article.gmane.org/gmane.linux.gentoo.devel/87466

with updated version (mostly rephrasing and typo-fixing) at,

    http://git.heroxbd.z.tuna.tsinghua.edu.cn/?p=doc.git;a=blob;f=glep-gap.rst

I have not got any acknowledgement from the GLEP team.

I'd like to ask the council to reinitiate a GLEP team and recover our
GLEP process.

Benda