[gentoo-dev] Monthly Gentoo Council Reminder for March

[gentoo-dev] Monthly Gentoo Council Reminder for March

[Mike Frysinger]

This is your monthly friendly reminder !  Same bat time (typically
the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
(#gentoo-council @ irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Raúl Porcel]

I want to propose to the council to talk about the amd64 arch team and 
its big bug list [1] considering they are the most staffed arch team.

They have some bugs that are more than a month old and they are the last 
arch. Same for security bugs, and i think amd64 is an important arch and 
has a lot of users, and ATs. x86 doesn't have any AT active and we only 
have less than 10 bugs, amd64 has 144 bugs, and i'm talking about bugs 
with STABLEREQ keywords, just look at [1].

So it would be cool if they accepted help from other devs who don't have 
  an amd64 system but have access to one and can test stuff. Cla is 
willing to help.

There's even a bug that is a blocker...


[1]: http://tinyurl.com/3dms4y
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Richard Freeman]

Raúl Porcel wrote:
> 
> So it would be cool if they accepted help from other devs who don't have 
>  an amd64 system but have access to one and can test stuff. Cla is 
> willing to help.
> 

I think this may be more a question of what our policy should be 
regarding level of testing/stability accepted.  I'm sure manpower is a 
factor as well (number of devs isn't necessarily directly proportional 
to number of hours spent by those devs per week on gentoo).

I don't keyword a package stable unless I've done at least a moderate 
amount of testing on the package to ensure that it works.  If a package 
looks simple but obscure I might go ahead and install it and play with 
it, but I'd probably never keyword an emacs package stable, since I 
don't ever use emacs and I won't pretend that all there is to it is 
installing it and typing "hello world" and figuring out how to quit.

Also, the more critical a package is the less likely I am to keyword it 
without care - I'm not going to keyword apache stable unless I've 
installed it and put several of my php/cgi-perl apps through a fair 
number of chores since I know that people who run apache generally care 
that it works.

If there are folks out there who can test on amd64 systems then I'm sure 
that the amd64 team would look forward to their help (just contact 
kingtaco about it) - either by arch testing or perhaps by just 
keywording as appropriate.  However, we do need to be careful about just 
going on a hunt to close bugs - "if it builds then it's stable" isn't 
really a policy I think we want to follow.  As an amd64 user as well as 
a dev I know that I'd rather be a little further behind on package foo 
(with the ability to accept ~amd64 on it if I wanted to) than to have 
packages breaking every other week because somebody keyworded them just 
because it compiled and didn't have any glaring faults.

I think we also need better coordination across gentoo regarding when 
packages should be stabilized.  I've seen amd64 CC'ed on stablereq bugs 
filed by end users, and arch teams keywording them left and right, and 
there is no sign that the package maintainer wants the package 
stabilized.  I know that I'd be annoyed if arch teams stabilized a 
package that I maintained and I didn't intend for it to become stable 
for whatever reason.  At the very least maintainers should be contacted 
before packages go stable - and they should probably document their 
intent in STABLEREQ bugs before everybody goes crazy closing them out.

I think that if we have the right policies then we'll be where we want 
to be.  Personally, it doesn't concern me a great deal that there are 
tons of bugs open on an arch in and of itself (although blockers and 
security bugs are a different matter).  I'd rather that then keyword 
something stable anytime one person (usually not the maintainer) asks us 
to.  And users who feel like they're being held up should feel free to 
ping a dev to talk about it - and comments by users and maintainers in 
bugs indicating how stable a package really is make people like me more 
warm and fuzzy about keywording it without as much personal testing.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Christian Faulhammer]

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

Hi,

Richard Freeman <rich0@gentoo.org>:

> Raúl Porcel wrote:
> > 
> > So it would be cool if they accepted help from other devs who don't
> > have an amd64 system but have access to one and can test stuff. Cla
> > is willing to help.
[...]
> I don't keyword a package stable unless I've done at least a moderate 
> amount of testing on the package to ensure that it works.  If a
> package looks simple but obscure I might go ahead and install it and
> play with it, but I'd probably never keyword an emacs package stable,
> since I don't ever use emacs and I won't pretend that all there is to
> it is installing it and typing "hello world" and figuring out how to
> quit.

 Hah, got you.  Emacs team has a collection of test plans, that are
understandable and have a step-by-step guide to the package.  You may
not have noticed because at the moment, Emacs teams handles nearly all
stabilisation requests itself on amd64.
 Yes, testing is crucial, but it eases your pain if you have an arch
tester going over it beforehand and amd64 is well equipped with that.
 
> If there are folks out there who can test on amd64 systems then I'm
> sure that the amd64 team would look forward to their help (just
> contact kingtaco about it) - either by arch testing or perhaps by
> just keywording as appropriate.  However, we do need to be careful
> about just going on a hunt to close bugs - "if it builds then it's
> stable" isn't really a policy I think we want to follow.  As an amd64
> user as well as a dev I know that I'd rather be a little further
> behind on package foo (with the ability to accept ~amd64 on it if I
> wanted to) than to have packages breaking every other week because
> somebody keyworded them just because it compiled and didn't have any
> glaring faults.

 There are dozens of bugs out there for amd64, that are no
stabilisation requests but contain a patch or simple requests that
could be handled in a fast way....problem is, nobody does.  Don't get
Raul or myself wrong, we are not here to accuse someone or do a mud
fight.  We care and are worried about the state of amd64, but do not
want to lower the work invested by some members of the team, so don't
take anything personal or try to justify by all means.
 As a matter of fact amd64 has some broken packages in the stable tree
where bugs exist and noone seems to care.

> I think we also need better coordination across gentoo regarding when 
> packages should be stabilized.  I've seen amd64 CC'ed on stablereq
> bugs filed by end users, and arch teams keywording them left and
> right, and there is no sign that the package maintainer wants the
> package stabilized.  I know that I'd be annoyed if arch teams
> stabilized a package that I maintained and I didn't intend for it to
> become stable for whatever reason.  At the very least maintainers
> should be contacted before packages go stable - and they should
> probably document their intent in STABLEREQ bugs before everybody
> goes crazy closing them out.

 This happens seldomly...and normally stabilisations are assigned to
the maintainer which should react and cc arches.  Only
maintainer-wanted is directly cced with arches by bug wranglers.  So
such problems occur if developers/trusted users create the stabilisation
bug.

> I think that if we have the right policies then we'll be where we
> want to be.  Personally, it doesn't concern me a great deal that
> there are tons of bugs open on an arch in and of itself (although
> blockers and security bugs are a different matter).  I'd rather that
> then keyword something stable anytime one person (usually not the
> maintainer) asks us to.  And users who feel like they're being held
> up should feel free to ping a dev to talk about it - and comments by
> users and maintainers in bugs indicating how stable a package really
> is make people like me more warm and fuzzy about keywording it
> without as much personal testing.

 Again, this is not a question of not testing but a question of getting
more work done (by more people).  Sometimes I do amd64 bugs although I
am not on the team, my only test system is a remote machine with
hardened kernel (miranda), but I do test the packages I mark stable.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

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

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Raúl Porcel]

Christian Faulhammer wrote:
[snip]

I agree 100%, thanks for explaining it better than me :P

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Peter Weller]

On Saturday 01 March 2008 10:55:06 Raúl Porcel wrote:
> So it would be cool if they accepted help from other devs who don't have
>   an amd64 system but have access to one and can test stuff. Cla is
> willing to help.

Oh, I'd be more than happy to accept help from developers like that. It's just 
a case of what the "big bosses" think of it. Plus there's the fact that some 
other arches operate on a "it compiles, mark it stable" policy, and we don't 
want developers to bring that attitude to the amd64 team.
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Raúl Porcel]

Peter Weller wrote:
> 
> Oh, I'd be more than happy to accept help from developers like that. It's just 
> a case of what the "big bosses" think of it. Plus there's the fact that some 
> other arches operate on a "it compiles, mark it stable" policy, and we don't 
> want developers to bring that attitude to the amd64 team.

Hope you're not referring to any of my arches because that's not true :) 
In fact, if i did that, i wouldn't crash the alpha dev box so often, 
right Tobias?

And that just leaves arm,hppa,mips,ppc,ppc64,s390,sh :P
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Richard Freeman]

Raúl Porcel wrote:
> Peter Weller wrote:
>>
>> Oh, I'd be more than happy to accept help from developers like that.
>> It's just a case of what the "big bosses" think of it. Plus there's
>> the fact that some other arches operate on a "it compiles, mark it
>> stable" policy, and we don't want developers to bring that attitude to
>> the amd64 team.
> 
> Hope you're not referring to any of my arches because that's not true :)
> In fact, if i did that, i wouldn't crash the alpha dev box so often,
> right Tobias?
> 

I dunno - I just hit bug 211021 today while trying to clean out old
bugs.  Already stable on one arch and not a word from the maintainer.

I do agree with many of the posts in this thread by others - a big issue
is manpower.  However, I did want to mention that stabling packages
without input from maintainers seems to be a moderately-common practice.
 I'm sure the arch team leaders would welcome help if it were offered,
but it is more important that packages keyworded stable actually work
than for the latest-and-greatest package to be marked stable.
Interested users can volunteer to be ATs as well - in my past experience
as an AT when I keyworded a bug STABLE I could expect to see it
committed by a dev within a few hours.

While amd64 is a lot more mainstream than it used to be you can't just
assume that upstream wouldn't have released something if it didn't work
perfectly on amd64.

Somebody had commented that there are cases where there are
already-stable packages with bugs in them that are causing problems.
Feel free to ping one of us, or start a discussion on the -amd64 mailing
list, or email the amd64@ alias if necessary if something in particular
is causing major headaches.  Simply posting a comment in bug 37 out of
250 probably won't get much attention.  I'm sure all the amd64 devs want
to do what they can to help out those with more obscure packages.  There
are a LOT of packages marked stable on amd64 though, and while it has
improved greatly upstream still doesn't support it as well as it does
x86 (though I'm sure we won't get much sympathy from most of the other
archs in this regard :)  ).

No disputing that there is a problem - we just want to be careful that
the solution isn't worse than the problem...
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Christian Faulhammer]

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

Hi,

Richard Freeman <rich0@gentoo.org>:
> > Hope you're not referring to any of my arches because that's not
> > true :) In fact, if i did that, i wouldn't crash the alpha dev box
> > so often, right Tobias?
> I dunno - I just hit bug 211021 today while trying to clean out old
> bugs.  Already stable on one arch and not a word from the maintainer.

 As I was the one ccing arches, I should explain here...humpback has
not reacted on tor bugs for a long time, not even security ones.  So I
did bumps and minor fixes for some time now, including stabilisation
requests.  My only failure here was, that I did not add myself to
metadata.xml.
 My policy is to ask for stabilisation --> no reaction for one week
(if it is urgent), I call arches.

> While amd64 is a lot more mainstream than it used to be you can't just
> assume that upstream wouldn't have released something if it didn't
> work perfectly on amd64.

 Here you are right, and I must admit I sometimes only compile-test. I
test everything I can, for special hardware I ask around in the team,
but if there is no one I have no other choice.
 
> No disputing that there is a problem - we just want to be careful that
> the solution isn't worse than the problem...

 What we propose is proper testing and keywording by anyone
around...not just team members.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

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

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Richard Freeman]

Christian Faulhammer wrote:
> 
>  What we propose is proper testing and keywording by anyone
> around...not just team members.
> 

Thanks for the info - inactive maintainers are obviously a problem.
Maybe the proper approach is for a more "Free-for-all" system like you
suggest, with arch teams focusing on more arch-specific aspects of
gentoo (such as the 32-bit libs for amd64, etc), and with arch teams
having a QA oversight role for their arch.  Perhaps arch teams should
publish clear (and reasonably simple) policies they would like to see
followed with their archs, and then devs could feel free to follow them
on their own initiative.  Accountability would obviously matter, but we
don't want to chop off hands for first offenses, either.

The Gentoo dev community is fairly closed - it isn't like just anybody
can go keywording packages left and right.

However, we do need to make sure that QA is followed.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Steve Dibb]

Christian Faulhammer wrote:

>  What we propose is proper testing and keywording by anyone
> around...not just team members.

I agree... our main problem is manpower -- people actually working on 
the stable bugs.  I've tried to do it myself a few times, but each time 
it just burns me out to the point where I don't want to (and won't) work 
on anything Gentoo-related for a time.

I've mostly resigned myself to working on just security bugs, but even 
those are so common that we need people looking at them all the time as 
well.

Anyway, I'm all for a policy of if you have an amd64 box, and you're on 
a team / herd that wants to move forward with stable plans, just consult 
the amd64 team and then go ahead with it.  Anything to spread the 
workload so that people don't get fed up with the bottlenecks.

Steve
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[George Shapovalov]

Sunday, 2. March 2008, Steve Dibb Ви написали:
> Christian Faulhammer wrote:
> >  What we propose is proper testing and keywording by anyone
> > around...not just team members.
>
> I agree... our main problem is manpower -- people actually working on
> the stable bugs.  I've tried to do it myself a few times, but each time
> it just burns me out to the point where I don't want to (and won't) work
> on anything Gentoo-related for a time.
So, may be we should expand the number of "stability classes"? (something akin 
to my origina proposal, parst of which has been implemented, but looks like 
there is yet another usefull issue or two that did not make it yet :) (bug 
#1523, though probably not worth studying a this point as it mostly contains 
old stuff by now)).

Right now with packages being only "in testing" and "stable" we basically 
cover the audiences with stances "original dev says it works - it's fine for 
me" and "I want it rigorously tested". There should be plenty of people, who 
would be happy with an intermediate level of control. May be we should add an 
intermediate category with a somewhat automated workflow? So that the 
evolution of packages in the tree would follow such pattern (plus, of course, 
there are overlays for even less stable stuff):

1. as the package gets released it goes into the "testing", as it does now

2. After say 2-4 wekks (take your pick) without issues and possibly going 
trhough some compile-farm (automatically scheduled at the end of this period 
if no open bugs (normal or more severe) are detected) the package is marked 
as belonging to the "tested" category. This is where many users would set 
their running stability level and, in a way, participate in testing things 
for the next level.

If, any time after entering the "tested" state, package gets a bug assigned 
against it (again, normal or more severe) we start a countdown of, perhaps a 
few days, to let developers take care of the bug and if it does not get 
resolved within this time frame the package goes back to "testing". The 
decision to mask it or pull it off the tree completely remains with the 
respective devs, as it is now.
Some packages can be marked as "critical" to make them go back to "testing" 
immediately upon getting an open bug, should such effect be desired (might be 
usefull for some security-sensitive system packages, or may be not, due to 
possible breakage this may introduce. Still we are having such downgrade 
situations already from time to time).

3. "completely stable" profile, to which packages only go when explicitly 
requested and processed by stabilization team, as they are now. We should 
probably impose the requirement, that stabilization can only be requested for 
packages in the "tested" category.

The good thing about this approach is that it only requires an initial 
investment of organizing and automating things but does not add any regular 
work to the devs. In fact, if the "tested" category becomes popular enough, 
it can cut the work for stable testers, may be even by something like a 
factor of 10 eventually (due to less requests for explicit stabilizaion being 
issued)..

George
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Richard Freeman]

George Shapovalov wrote:
> The good thing about this approach is that it only requires an initial 
> investment of organizing and automating things but does not add any regular 
> work to the devs. In fact, if the "tested" category becomes popular enough, 
> it can cut the work for stable testers, may be even by something like a 
> factor of 10 eventually (due to less requests for explicit stabilizaion being 
> issued)..
> 

We might also aim to make it easy for users to mix-and-match levels of
stability by package.  I know it is possible already, but perhaps it
could be improved, or pre-canned lists of packages that users might
typically want bleeding-edge vs stable could be compiled.

I think there are a large number of users who wouldn't mind less
stability on packages that won't prevent booting or network-access or
general use of their system.  If some nice-to-have utility breaks I
don't mind reverting it, but if baselayout goes haywire I could spend
hours just getting my system to boot.

I like your idea though.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Jan Kundrát]

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

Richard Freeman wrote:
> We might also aim to make it easy for users to mix-and-match levels of
> stability by package.  I know it is possible already, but perhaps it
> could be improved, or pre-canned lists of packages that users might
> typically want bleeding-edge vs stable could be compiled.

Tusnam said it better than I would, so I'll just post a link -- 
http://tsunam.org/2008/01/29/arch/

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


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

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[George Shapovalov]

Sunday, 2. March 2008, Richard Freeman Ви написали:
> George Shapovalov wrote:
> > The good thing about this approach is that it only requires an initial
> > investment of organizing and automating things but does not add any
> > regular work to the devs. In fact, if the "tested" category becomes
> > popular enough, it can cut the work for stable testers, may be even by
> > something like a factor of 10 eventually (due to less requests for
> > explicit stabilizaion being issued)..
>
> We might also aim to make it easy for users to mix-and-match levels of
> stability by package.  I know it is possible already, but perhaps it
> could be improved, or pre-canned lists of packages that users might
> typically want bleeding-edge vs stable could be compiled.
Well, we already have "system set" and it is defined in profile. With users 
being able to define and use their own profiles all that is left to do is to 
add an ability by portage to use different stability settings for system and 
out-of-system packages, as the most trivial approach. Of course more complex 
combinations are possible, but would require a proper discussion.

> I think there are a large number of users who wouldn't mind less
> stability on packages that won't prevent booting or network-access or
> general use of their system.  If some nice-to-have utility breaks I
> don't mind reverting it, but if baselayout goes haywire I could spend
> hours just getting my system to boot.
Exactly. I did not mention this in order not to overcomplicate my previous 
message, but this is one of the things I had in ming for a long time. Besides

> I like your idea though.
Thanks! Although it is somewhat strange to hear "idea" when it has been 
an "old news" :) (at least for me), just check the timing of that bug I 
mentioned above. I merely adapted one of the not-yet-implemented issues 
discussed there to the present situation.

Oh, btw, these two issues (extra stability levels and separate stability 
rankings for groups of packages) are independant enough to make it possible 
to implement them separately.

George
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Santiago M. Mola]

On Sat, Mar 1, 2008 at 7:45 PM, Christian Faulhammer <opfer@gentoo.org> wrote:
>
>   What we propose is proper testing and keywording by anyone
>  around...not just team members.
>

Writing test plans like emacs team does really helps too. I waste too
much time figuring out how to test properly some packages, and I'm
sure me and other ATs miss a lot of important use cases.

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Christian Faulhammer]

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

Hi,

"Santiago M. Mola" <coldwind@gentoo.org>:

> On Sat, Mar 1, 2008 at 7:45 PM, Christian Faulhammer
> <opfer@gentoo.org> wrote:
> >
> >   What we propose is proper testing and keywording by anyone
> >  around...not just team members.
>
> Writing test plans like emacs team does really helps too. I waste too
> much time figuring out how to test properly some packages, and I'm
> sure me and other ATs miss a lot of important use cases.

 Maybe this could be centralised?  User interaction is really simple
here, so this could be wikified.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Raúl Porcel]

Richard Freeman wrote:
> Raúl Porcel wrote:
>> Peter Weller wrote:
>>> Oh, I'd be more than happy to accept help from developers like that.
>>> It's just a case of what the "big bosses" think of it. Plus there's
>>> the fact that some other arches operate on a "it compiles, mark it
>>> stable" policy, and we don't want developers to bring that attitude to
>>> the amd64 team.
>> Hope you're not referring to any of my arches because that's not true :)
>> In fact, if i did that, i wouldn't crash the alpha dev box so often,
>> right Tobias?
>>
> 
> I dunno - I just hit bug 211021 today while trying to clean out old
> bugs.  Already stable on one arch and not a word from the maintainer.
> 
> I do agree with many of the posts in this thread by others - a big issue
> is manpower.  However, I did want to mention that stabling packages
> without input from maintainers seems to be a moderately-common practice.

I've never seen that, unless the maintainer doesn't respond, like in 
this case, humpback has been ignoring his bugs for a long time, like 
other devs(unfortunately). Maybe the council should talk about that: 
devs ignoring his bugs for months, but i don't know how would they 
enforce that.

What i've seen is some bugs where the arches were cc'ed by users or by a 
developer, but in this case, someone of the arch team that knows that 
the dev is active, just uncc's all the arches until the maintainer 
responds, but in this case, humpback didn't say anything about the 
previous tor stabilization request for months. So you should be glad 
someone active like Christian, took over the maintenance and he is 
responsible if something goes wrong with the stabilization.

>  I'm sure the arch team leaders would welcome help if it were offered,
> but it is more important that packages keyworded stable actually work
> than for the latest-and-greatest package to be marked stable.
> Interested users can volunteer to be ATs as well - in my past experience
> as an AT when I keyworded a bug STABLE I could expect to see it
> committed by a dev within a few hours.

IIRC you are from the blubb era, i'm i right? Blubb did a really god job 
with amd64, and in fact amd64 started 'slacking' since blubb left. 
Unfortunately that doesn't work anymore, in a lot of bugs i've seen an 
AT of yours posting his results, when i was going to do my arches. So i 
was more faster even that i have no ATs.

And look at x86, we don't have any ATs, god, we even had some that moved 
to amd64! drac, mlangc, etc etc.
For example, bug 205242. Look, its mlangc! :P
> 
> While amd64 is a lot more mainstream than it used to be you can't just
> assume that upstream wouldn't have released something if it didn't work
> perfectly on amd64.
> 

Indeed, but on x86 we don't assume it either :) I don't understand how 
you having so many users, have manpower problems, you have two channels 
on IRC, x86 only has one and nobody says anything.
It's just a though, i'm not blaming anyone.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Ed W]

At one time there were some apps which reported back "usage" from 
people's systems and showed package versions in use?  Now, whilst this 
in itself is not an indication of package quality or bug-freeness.  
Perhaps it would be an interesting datastream to assist in deciding 
whether to mark a package stable or not?

An incremental improvement to such a plan might be to consider how to 
split the data into high quality devs and testers running stuff stuff, 
keen users and dev boxes (which might be crashing and are of low quality).

Sure it's a fairly low quality data source, but it might give a bit of 
confidence to take a punt unmasking a package if you can see that others 
are using it "actively"?

Just my 2p

Ed W
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Richard Freeman]

Raúl Porcel wrote:
> 
> IIRC you are from the blubb era, i'm i right? Blubb did a really god job
> with amd64, and in fact amd64 started 'slacking' since blubb left.
> Unfortunately that doesn't work anymore, in a lot of bugs i've seen an
> AT of yours posting his results, when i was going to do my arches. So i
> was more faster even that i have no ATs.
> 

Yup - blubb is certainly missed.  I can't point any fingers myself - I
try to find and stabilize packages as I'm able to, but I can only spend
so much time on gentoo.  Every little bit helps though, even if I'm not
high on the commits/day rankings.

There are amd64 ATs out there - which brings up the other thread
floating around.  We need better ways to flag bugs that have been
touched by an AT - for all I know there are a dozen open bugs that an AT
has tested, but if there aren't any keywords or anything else I can
query for, I can't get them stabilized.

> 
> Indeed, but on x86 we don't assume it either :) I don't understand how
> you having so many users, have manpower problems, you have two channels
> on IRC, x86 only has one and nobody says anything.
> It's just a though, i'm not blaming anyone.
> 

My observation is that there are heavy-lifters who do a disproportionate
share of the work.  I'm certainly not one of them, and I really do
appreciate these folks.  If a heavy-lifter gives attention to something,
it will shine.  However, Gentoo is a volunteer-driven organization, and
you can't order heavy-lifters to work on something in particular - it is
their passion for what they choose to work on that makes them so
effective.  I guess what we need is processes that enable lots of small
contributors to make a big difference - the bazzar approach.

Another reply on this thread pointed out that it would be nice to be
able to tell what packages people are using - if we could tell what is
being used it would help guide stabilization without sacrificing testing
(our users would be de-facto ATs without realizing it).  The power of a
thousand people doing very little can add up - many users would gladly
sign up to have their packages monitored if it would help the gentoo cause.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Peter Weller]

On Saturday 01 March 2008 10:55:06 Raúl Porcel wrote:
[..snip..]

There are also a number of problems with people on the team who are there 
soley so that they don't have to ask the team to mark a package stable for 
them - they can just go and stable it themselves. OK, this may help the amd64 
team in a minor way, but it would be much more preferable if they actually 
did any work *outside* of this.

Now, some of you may have noticed a certain level of inactivity from me 
lately, but rest assured that now that I have my new Core 2 Duo laptop more 
or less up and running, I'll be able to do more amd64 stuff.

welp
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Peter Volkov]

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


В Сбт, 01/03/2008 в 14:39 +0000, Peter Weller пишет:
> There are also a number of problems with people on the team who are there 
> soley so that they don't have to ask the team to mark a package stable for 
> them - they can just go and stable it themselves.

It'll be even better if we prohibit such things by telling that
maintainer is not allowed to stabilize his/her packages. That said, 1. I
know that some packages will never be stabilized without such practice
but we could have list of such packages somewhere; 2. some archs do not
have enough developer to enforce this policy but x86 and amd64 are not
among them.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Anant Narayanan]

Hi,

> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know !  Simply reply to this e-mail for the whole
> Gentoo dev list to see.

If it's not too late for this month's meeting, I'd like to discuss the  
possibility of including a new "post" in our developer base - the  
package maintainer.

a) The requirements to become a package maintainer for Gentoo may be  
lesser than that of the full-fledged developer. This serves a couple  
of purposes:
	- Users might become more motivated to becoming a maintainer for  
Gentoo, since it would require less time and effort from their end
	- Might reduce the number of orphaned packages we have in the tree

b) Some existing developers might want to switch to this post, if they  
feel that package maintenance is all they really want to do with  
Gentoo. This has the advantage of requiring lesser time from their  
side, while not feeling the pressure of being "responsible". We  
already have arch-testers, so this will fit in nicely with our current  
development model.

c) The actual developer post may be taken up by existing developers  
who make wide-ranging or significant changes to Gentoo, as a whole.  
Examples include: package manager development, eclasses,  
documentation; basically anything that would require a GLEP or commit  
access to the whole tree - you get the idea.

Some of you may argue that we already have proxy-maintainers. That's a  
great idea, all I'm asking for is for us to formalize the position.  
Giving a proxy-maintainer an official acknowledgement will definitely  
attract more users to contribute. Meanwhile, developers can do  
innovative things that they really like without having to maintain  
packages just because of a formality. Giving package maintainers  
commit access to parts of the tree might turn out to be tricky though,  
this needs discussion with infra.

I'd really like for us to think through this proposal - I strongly  
believe that this will improve the quality of Gentoo development as a  
whole, and reduce the number of open bugs and their turnaround times.

Cheers,
Anant

P.S. As some of you may have already guessed, this proposal is based  
on Debian's approval of a similar position in their developer  
hierarchy last year: http://www.us.debian.org/vote/2007/vote_003

P.P.S. Maybe this is more suited for -project, but everyone knows that  
nobody reads that list :-p
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Jean-Noël Rivasseau]

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

I totally second this proposal.

I think this would be especially great for small or rarely used packages. I
can think of at least a dozen packages that I'd love to see in Portage, but
they are not in the tree. Allowing for people that are not developers to
maintain easy or not crucial packages is a good thing. It would not require
much effort for these people (since some packages are updated like once a
year), and even if the ebuilds are of low quality, that would not be a big
problem (we could mark those ebuilds specially so that if we developers have
some time to spare, we can review them).

The only problem I see, like Anant mentionned, is that we would need to
restrict commit access to parts of the tree. Not sure if that is possible.

Elvanör

On Wed, Mar 5, 2008 at 6:11 PM, Anant Narayanan <anant@gentoo.org> wrote:

> Hi,
>
> > If you have something you'd wish for us to chat about, maybe even
> > vote on, let us know !  Simply reply to this e-mail for the whole
> > Gentoo dev list to see.
>
> If it's not too late for this month's meeting, I'd like to discuss the
> possibility of including a new "post" in our developer base - the
> package maintainer.
>
> a) The requirements to become a package maintainer for Gentoo may be
> lesser than that of the full-fledged developer. This serves a couple
> of purposes:
>        - Users might become more motivated to becoming a maintainer for
> Gentoo, since it would require less time and effort from their end
>        - Might reduce the number of orphaned packages we have in the tree
>
> b) Some existing developers might want to switch to this post, if they
> feel that package maintenance is all they really want to do with
> Gentoo. This has the advantage of requiring lesser time from their
> side, while not feeling the pressure of being "responsible". We
> already have arch-testers, so this will fit in nicely with our current
> development model.
>
> c) The actual developer post may be taken up by existing developers
> who make wide-ranging or significant changes to Gentoo, as a whole.
> Examples include: package manager development, eclasses,
> documentation; basically anything that would require a GLEP or commit
> access to the whole tree - you get the idea.
>
> Some of you may argue that we already have proxy-maintainers. That's a
> great idea, all I'm asking for is for us to formalize the position.
> Giving a proxy-maintainer an official acknowledgement will definitely
> attract more users to contribute. Meanwhile, developers can do
> innovative things that they really like without having to maintain
> packages just because of a formality. Giving package maintainers
> commit access to parts of the tree might turn out to be tricky though,
> this needs discussion with infra.
>
> I'd really like for us to think through this proposal - I strongly
> believe that this will improve the quality of Gentoo development as a
> whole, and reduce the number of open bugs and their turnaround times.
>
> Cheers,
> Anant
>
> P.S. As some of you may have already guessed, this proposal is based
> on Debian's approval of a similar position in their developer
> hierarchy last year: http://www.us.debian.org/vote/2007/vote_003
>
> P.P.S. Maybe this is more suited for -project, but everyone knows that
> nobody reads that list :-p
> --
> gentoo-dev@lists.gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 4045 bytes --]

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Marius Mauch]

On Wed, 5 Mar 2008 22:41:58 +0530
Anant Narayanan <anant@gentoo.org> wrote:

> Hi,
> 
> > If you have something you'd wish for us to chat about, maybe even
> > vote on, let us know !  Simply reply to this e-mail for the whole
> > Gentoo dev list to see.
> 
> If it's not too late for this month's meeting, I'd like to discuss
> the possibility of including a new "post" in our developer base -
> the package maintainer.
> 
> a) The requirements to become a package maintainer for Gentoo may be  
> lesser than that of the full-fledged developer.

Please elaborate on how a "full.fledged developer" would differ from a
"package maintainer" technically. What requirements and/or
priviledges do you think could be reduced?

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Anant Narayanan]

> Please elaborate on how a "full.fledged developer" would differ from a
> "package maintainer" technically. What requirements and/or
> priviledges do you think could be reduced?

I haven't thought that through fully (in hopes of a few good  
suggestions!), but off the top of my head, maintainers don't need to  
complete the staff quiz. On the technical side, about the only thing  
they really require is a sound knowledge of bash, the do's and don'ts  
of ebuilds, and knowledge of how to use eclasses. Perhaps we can  
create a separate quiz for maintainers, which stresses on versioning,  
handling bump requests, keeping ebuilds clean etc, and nothing more.  
I'm willing to help form the quiz, but I certainly can't do it alone.

As for the privileges, maintainers wouldn't need an email account,  
commit access to portions not concerning their package(s), voice on  
#gentoo-dev... Essentially, we need to keep limit the privileges to  
whatever infra can provide within reasonable limits - I expect the  
number of maintainers to be far greater than the developer count.

On another note, we may introduce a rule that no package may be marked  
stable unless a "full-fledged developer" or QA member has approved it  
(along with the usual arch-tester stamp). This might help in ensuring  
the quality of our stable tree.

--
Anant
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Denis Dupeyron]

On Wed, Mar 5, 2008 at 7:10 PM, Anant Narayanan <anant@gentoo.org> wrote:
>  maintainers don't need to complete the staff quiz.

The staff quiz is focused on our general procedures and how to behave
and interact with other devs. It is a great opportunity for the
recruiter to get to know who he (no "she"s in recruiters, applications
welcome) is talking to. It's at this time that I have the most
interesting discussions with the recruit and learn the most on the
individual (s)he is. We had enough issues in the past with technically
good people who just couldn't behave that I think skipping this phase
is really not a good idea. Because, believe it or not, the recruitment
process in general and the review in particular are not only about
checking yes/no boxes about the recruit's answers to obscure quizzes.
Plus, practically the staff quiz takes very little time. With the old
argument being that if you can't spend that little time on the staff
quiz then chances are you won't be a dev for long, and thus not worth
investing time in.

> On the technical side, about the only thing
>  they really require is a sound knowledge of bash, the do's and don'ts
>  of ebuilds, and knowledge of how to use eclasses.

This is currently what the ebuild quiz is trying to be. I don't
understand what difference you want to make between a full dev and a
package maintainer when both will have to write the same kind of
ebuilds, face the same kind of issues and have to come up with the
same kind of solutions. And in in the end create the same risk of
instability to the tree, only in a more fragmented, thus less
controllable way (due to more clueless people for the same job).

>  As for the privileges, maintainers wouldn't need an email account,
>  commit access to portions not concerning their package(s),

Meaning that they'll be allowed to break only a certain portion of the
tree. That's OK with me, as long as it's not the portion I use. I
believe some people depend on gentoo. I don't see any reason to risk
making their life miserable.

I hope you're not going to take any of the above personally. My
opinion is we have proxy maintenance and overlays like sunrise in
place already. If they're not working properly I suggest we fix them.
There's no point breaking something in the hope you'll fix something
else that doesn't work. Go to the root of the problem instead.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Thomas Anderson]

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

On Wednesday 05 March 2008 12:45:31 Marius Mauch wrote:
> On Wed, 5 Mar 2008 22:41:58 +0530
>
> Anant Narayanan <anant@gentoo.org> wrote:
> > Hi,
> >
> > > If you have something you'd wish for us to chat about, maybe even
> > > vote on, let us know !  Simply reply to this e-mail for the whole
> > > Gentoo dev list to see.
> >
> > If it's not too late for this month's meeting, I'd like to discuss
> > the possibility of including a new "post" in our developer base -
> > the package maintainer.
> >
> > a) The requirements to become a package maintainer for Gentoo may be
> > lesser than that of the full-fledged developer.
>
> Please elaborate on how a "full.fledged developer" would differ from a
> "package maintainer" technically. What requirements and/or
> priviledges do you think could be reduced?
>
> Marius

Perhaps there could be some honor code system at least, where the package 
maintainer would be restricted to their area of maintainership. 

but +1 from me, I'd be very interested in the position, considering I already 
proxy maintain a package.

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Petteri Räty]

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

Thomas Anderson kirjoitti:
>> Please elaborate on how a "full.fledged developer" would differ from a
>> "package maintainer" technically. What requirements and/or
>> priviledges do you think could be reduced?
>>
>> Marius
> 
> Perhaps there could be some honor code system at least, where the package 
> maintainer would be restricted to their area of maintainership. 
> 

This is the current situation.

Regards,
Petteri


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Thomas Anderson]

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

On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote:
> Thomas Anderson kirjoitti:
> >> Please elaborate on how a "full.fledged developer" would differ from a
> >> "package maintainer" technically. What requirements and/or
> >> priviledges do you think could be reduced?
> >>
> >> Marius
> >
> > Perhaps there could be some honor code system at least, where the package
> > maintainer would be restricted to their area of maintainership.
>
> This is the current situation.
>
> Regards,
> Petteri

Exactly, only the "package maintainers" wouldn't have everything that a full 
dev would have...

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Doug Goldstein]

Thomas Anderson wrote:
> On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote:
>   
>> Thomas Anderson kirjoitti:
>>     
>>>> Please elaborate on how a "full.fledged developer" would differ from a
>>>> "package maintainer" technically. What requirements and/or
>>>> priviledges do you think could be reduced?
>>>>
>>>> Marius
>>>>         
>>> Perhaps there could be some honor code system at least, where the package
>>> maintainer would be restricted to their area of maintainership.
>>>       
>> This is the current situation.
>>
>> Regards,
>> Petteri
>>     
>
> Exactly, only the "package maintainers" wouldn't have everything that a full 
> dev would have...
>   
What exactly wouldn't they get? What would differ them from Arch Testers?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Thomas Anderson]

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

On Wednesday 05 March 2008 14:59:55 Doug Goldstein wrote:
> Thomas Anderson wrote:
> > On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote:
> >> Thomas Anderson kirjoitti:
> >>>> Please elaborate on how a "full.fledged developer" would differ from a
> >>>> "package maintainer" technically. What requirements and/or
> >>>> priviledges do you think could be reduced?
> >>>>
> >>>> Marius
> >>>
> >>> Perhaps there could be some honor code system at least, where the
> >>> package maintainer would be restricted to their area of maintainership.
> >>
> >> This is the current situation.
> >>
> >> Regards,
> >> Petteri
> >
> > Exactly, only the "package maintainers" wouldn't have everything that a
> > full dev would have...
>
> What exactly wouldn't they get? What would differ them from Arch Testers?

Arch Testers don't have tree access. This proposal gives the package 
maintainer the ability to commit their changes.

-- 
"Taylor and Anderson, Metropolitan prosecutors. Commit a crime? See you in 
court"

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Petteri Räty]

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

Thomas Anderson kirjoitti:
> 
> Arch Testers don't have tree access. This proposal gives the package 
> maintainer the ability to commit their changes.
> 

How would you ensure ebuild quality for these package maintainers?

Regards,
Petteri


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Thomas Anderson]

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

On Wednesday 05 March 2008 16:05:09 Petteri Räty wrote:
> Thomas Anderson kirjoitti:
> > Arch Testers don't have tree access. This proposal gives the package
> > maintainer the ability to commit their changes.
>
> How would you ensure ebuild quality for these package maintainers?
>
> Regards,
> Petteri

Maybe a small review board of 3-4 people to make sure that all new packages 
meet the requirements in the devmanual? Just an idea, maybe not the best.

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Petteri Räty]

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

Thomas Anderson kirjoitti:
> On Wednesday 05 March 2008 16:05:09 Petteri Räty wrote:
>> Thomas Anderson kirjoitti:
>>> Arch Testers don't have tree access. This proposal gives the package
>>> maintainer the ability to commit their changes.
>> How would you ensure ebuild quality for these package maintainers?
>>
>> Regards,
>> Petteri
> 
> Maybe a small review board of 3-4 people to make sure that all new packages 
> meet the requirements in the devmanual? Just an idea, maybe not the best.
 >

I don't think this would be an improvement over proxy maintenance.

Regards,
Petteri


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Anant Narayanan]

On 06-Mar-08, at 2:35 AM, Petteri Räty wrote:
> Thomas Anderson kirjoitti:
>> Arch Testers don't have tree access. This proposal gives the  
>> package maintainer the ability to commit their changes.
>
> How would you ensure ebuild quality for these package maintainers?

Maintainers will also go through a recruitment process, although a  
much shorter one which focusses only on ebuild maintenance -  
maintainers will not have the karma to introduce new ebuilds into the  
tree. The idea is to make the recruitment process as easy and quick as  
possible, while ensuring that the person involved has the requisite  
skills.

Also, packages may not be marked stable until a full-fledged-developer/ 
QA-member has approved of it. Packages being broken in the testing  
tree are not uncommon, and we are usually notified quickly enough to  
fix it.

--
Anant--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Alec Warner]

On 3/5/08, Anant Narayanan <anant@gentoo.org> wrote:
> On 06-Mar-08, at 2:35 AM, Petteri Räty wrote:
>  > Thomas Anderson kirjoitti:
>  >> Arch Testers don't have tree access. This proposal gives the
>  >> package maintainer the ability to commit their changes.
>  >
>  > How would you ensure ebuild quality for these package maintainers?
>
>
> Maintainers will also go through a recruitment process, although a
>  much shorter one which focusses only on ebuild maintenance -
>  maintainers will not have the karma to introduce new ebuilds into the
>  tree. The idea is to make the recruitment process as easy and quick as
>  possible, while ensuring that the person involved has the requisite
>  skills.

Maybe break this down for me again please:

What are the technical differences between a 'Package Maintainer' and
a 'Developer'?

I guess technical is the wrong word.  Lets back up.  What problem are
you trying to solve?

In your original mail; you stated that:

a) The requirements to become a package maintainer for Gentoo may be
lesser than that of the full-fledged developer. This serves a couple
of purposes:
       - Users might become more motivated to becoming a maintainer for
Gentoo, since it would require less time and effort from their end
       - Might reduce the number of orphaned packages we have in the tree

So your goals are:

Have more maintained packages in the tree.
Get more people (users) involved in making Gentoo better.

And you want to accomplish this by:

Creating a position that has less stringent requirements to encourage
interested folks to contribute.

Your point B) also mentions removing pressure from existing developers
by having some move to this new position to be less 'reponsible'.

Can you explain how this 'Package Maintainer' is 'less responsible'
than a full fledged developer?  Can you also explain in more detail
how the position of 'Package Maintainer' is also easier to obtain than
the position of 'Developer'?

You also stated:

"Meanwhile, developers can do innovative things that they really like
without having to maintain packages just because of a formality."

I'm a bit new here; but since when was it required for a developer to
maintain any packages?

I care a lot less about how to implement this idea technically (cvs
acls or lack of Gentoo.org e-mail address) and more so on what this
will actually gain us; and how we should go about designing this
position to accomplish the goals I think you want it to accomplish.

>
>  Also, packages may not be marked stable until a full-fledged-developer/
>  QA-member has approved of it. Packages being broken in the testing
>  tree are not uncommon, and we are usually notified quickly enough to
>  fix it.
>
>  --
>
> Anant--
>
> gentoo-dev@lists.gentoo.org mailing list
>
>
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] proxy-maintaner improvement (was: Monthly Gentoo Council Reminder for March)

[Peter Volkov]

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

В Чтв, 06/03/2008 в 09:08 +0530, Anant Narayanan пишет:
> The idea is to make the recruitment process as easy and quick as  
> possible, while ensuring that the person involved has the requisite  
> skills.

Could you explain, how our recruitment process is long and hard? Also
how could you ensure that the person involved has the requisite skills
without asking him some questions (read quizes)? If potential developer
does not have either time or knowledge to answer our quizes he/she'll be
unable to maintain packages on a daily/weekly basis:
 * if candidate knows nothing about ebuilds he/she have to spend some
time and learn what they are, or how do you suppose it's possible to
maintain packages without such knowledge? We ~40 questions in both
quizes. Doing about 1 question a day (no so hard I suppose) it's
possible to finish quizes less then in 2 months.
 * if you know how to write ebuilds, it's possible to finish both quizes
in one day, not to hard/long I suppose too.

We already have alternatives: proxy-maintainer and sunrise overlay.


That said, I agree that proxy-maintainers should be improved. I'll try
to gather ideas from this thread and may be add some new. So:

* proxy-maintainers work with developers through bugzilla (as we have
them now), but after they finish ebuild quiz and recruiters approve it
they could:

 - get access in cvs to maintained packages. In this case:

1. they should have mentors which are subscribed to all proxy-maintainer
commits, and the mentor is responsible for all the things
proxy-maintainer commits
2. proxy-maintainer couldn't request initial package stabilization, only
mentor/dev from herd/team is allowed to do that
3. they should have IRC cloak, forums mark, voice in @gentoo-dev,
subscription to -core & -dev-announce.
4. they should be announced in -dev as ordinary

Also proxy-maintainers should be mentioned somewhere in the /doc/ area
of our web-site.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Doug Goldstein]

Thomas Anderson wrote:
> On Wednesday 05 March 2008 14:59:55 Doug Goldstein wrote:
>   
>> Thomas Anderson wrote:
>>     
>>> On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote:
>>>       
>>>> Thomas Anderson kirjoitti:
>>>>         
>>>>>> Please elaborate on how a "full.fledged developer" would differ from a
>>>>>> "package maintainer" technically. What requirements and/or
>>>>>> priviledges do you think could be reduced?
>>>>>>
>>>>>> Marius
>>>>>>             
>>>>> Perhaps there could be some honor code system at least, where the
>>>>> package maintainer would be restricted to their area of maintainership.
>>>>>           
>>>> This is the current situation.
>>>>
>>>> Regards,
>>>> Petteri
>>>>         
>>> Exactly, only the "package maintainers" wouldn't have everything that a
>>> full dev would have...
>>>       
>> What exactly wouldn't they get? What would differ them from Arch Testers?
>>     
>
> Arch Testers don't have tree access. This proposal gives the package 
> maintainer the ability to commit their changes.
>
>   
So what you're looking for is committer ACLs. Gentoo's CVS currently 
does not use any form of ACLs to restrict access. This proposal would 
have to be discussed with the infra team to consider the feasibility to 
add ACLs to the tree.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Robin H. Johnson]

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

On Wed, Mar 05, 2008 at 04:07:48PM -0500, Doug Goldstein wrote:
>> Arch Testers don't have tree access. This proposal gives the package 
>> maintainer the ability to commit their changes.
> So what you're looking for is committer ACLs. Gentoo's CVS currently does 
> not use any form of ACLs to restrict access. This proposal would have to be 
> discussed with the infra team to consider the feasibility to add ACLs to 
> the tree.
As the CVS admin, I've considered them for a while, esp to help with
some of the access to parts of docs. The BSDs make very heavy use of
them successfully (and indeed wrote several of the CVS ACL systems).

But just on the having time side, I'd ask for a month or two to fully
implement them. I've got enough projects in progress right now without
adding another.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Thomas Anderson]

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

On Wednesday 05 March 2008 14:59:55 Doug Goldstein wrote:
> Thomas Anderson wrote:
> > On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote:
> >> Thomas Anderson kirjoitti:
> >>>> Please elaborate on how a "full.fledged developer" would differ from a
> >>>> "package maintainer" technically. What requirements and/or
> >>>> priviledges do you think could be reduced?
> >>>>
> >>>> Marius
> >>>
> >>> Perhaps there could be some honor code system at least, where the
> >>> package maintainer would be restricted to their area of maintainership.
> >>
> >> This is the current situation.
> >>
> >> Regards,
> >> Petteri
> >
> > Exactly, only the "package maintainers" wouldn't have everything that a
> > full dev would have...
>
> What exactly wouldn't they get? What would differ them from Arch Testers?

Arch Testers don't have tree access. This proposal gives the package 
maintainer the ability to commit their changes.

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Donnie Berkholz]

On 22:41 Wed 05 Mar     , Anant Narayanan wrote:
> If it's not too late for this month's meeting, I'd like to discuss the 
> possibility of including a new "post" in our developer base - the package 
> maintainer.

...

> I'd really like for us to think through this proposal - I strongly believe 
> that this will improve the quality of Gentoo development as a whole, and 
> reduce the number of open bugs and their turnaround times.

Could you talk to some Debian people about how it's working out for 
them? (Or find a webpage that does this already.) I know they started 
it, but I'm not sure of the good and bad things that resulted.

What I'm looking for is a list of potential costs & benefits.

One thing I do like about this idea is that it reintroduces more of a 
meritocracy.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Santiago M. Mola]

On Wed, Mar 5, 2008 at 6:11 PM, Anant Narayanan <anant@gentoo.org> wrote:
>  Some of you may argue that we already have proxy-maintainers. That's a
>  great idea, all I'm asking for is for us to formalize the position.
>  Giving a proxy-maintainer an official acknowledgement will definitely
>  attract more users to contribute.

IMO the problem with proxy-maintainers is that most users don't know
such a thing exists. I bet some users could proxy-maintain a lot of
orphaned packages if we potentiate proxy-maint.

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Zhang Le]

On 21:07 Wed 05 Mar     , Santiago M. Mola wrote:
> On Wed, Mar 5, 2008 at 6:11 PM, Anant Narayanan <anant@gentoo.org> wrote:
> >  Some of you may argue that we already have proxy-maintainers. That's a
> >  great idea, all I'm asking for is for us to formalize the position.
> >  Giving a proxy-maintainer an official acknowledgement will definitely
> >  attract more users to contribute.
> 
> IMO the problem with proxy-maintainers is that most users don't know
> such a thing exists. I bet some users could proxy-maintain a lot of
> orphaned packages if we potentiate proxy-maint.

++

IMO giving proxy-maintainer due credit and publicity, meaning make it a formal
position, could solve the very problem Anant's proposal intended to solve.

Zhang Le
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Markus Ullmann]

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

Zhang Le schrieb:
> IMO giving proxy-maintainer due credit and publicity, meaning make it a formal
> position, could solve the very problem Anant's proposal intended to solve.

we had that in the past already yet it didn't solve one problem at hand:
users getting distacted and devs getting nervous b/c the process is
a) undocumented and
b) a bit complex as you have to keep $repo and gentoo-x86 in sync

So giving both (devs and users) an automated way of working with that 
would help a lot IMHO.

like the user submits using
echangelog "My cool change"
repoman submit

then the dev gets a diff or whatever against current state and then just 
does

repoman accept or
repoman reject <yourreasonhere>

note: just brainstorm idea but we definitely could use some scripts for 
this kind of work.

Greetz
-Jokey


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

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Petteri Räty]

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

Markus Ullmann kirjoitti:
> 
> So giving both (devs and users) an automated way of working with that 
> would help a lot IMHO.
> 
> like the user submits using
> echangelog "My cool change"
> repoman submit
> 
> then the dev gets a diff or whatever against current state and then just 
> does
> 
> repoman accept or
> repoman reject <yourreasonhere>
> 
> note: just brainstorm idea but we definitely could use some scripts for 
> this kind of work.
> 

There was a GSoC project/idea last year for this but I don't know if 
anything came of it.

Regards,
Petteri


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

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Jorge Manuel B. S. Vicetto]

Markus Ullmann wrote:
> we had that in the past already yet it didn't solve one problem at hand:
> users getting distacted and devs getting nervous b/c the process is
> a) undocumented and
> b) a bit complex as you have to keep $repo and gentoo-x86 in sync
>
> So giving both (devs and users) an automated way of working with that 
> would help a lot IMHO.
>
> like the user submits using
> echangelog "My cool change"
> repoman submit
>
> then the dev gets a diff or whatever against current state and then 
> just does
>
> repoman accept or
> repoman reject <yourreasonhere>
>

Markus,

you're talking about git.

> note: just brainstorm idea but we definitely could use some scripts 
> for this kind of work.
>
> Greetz
> -Jokey
>

-- 
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / SPARC / KDE

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Josh Saddler]

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

Anant Narayanan wrote:
> [stuff]

So basically, what you're looking for is something like Arch Linux's
Trusted User (TU) concept[1].

That works for Arch, because they have 5 repositories (including a
community repo), but I'm not sure how well that would fit Gentoo, where
there's just one.

We'd need some pretty extensive ACLs to make your proposal work, so
you'd need to talk to infra about that.



[1] http://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Roy Marples]

On Wednesday 05 March 2008 17:11:58 Anant Narayanan wrote:
> If it's not too late for this month's meeting, I'd like to discuss the
> possibility of including a new "post" in our developer base - the
> package maintainer.
>
> a) The requirements to become a package maintainer for Gentoo may be
> lesser than that of the full-fledged developer. This serves a couple
> of purposes:
> 	- Users might become more motivated to becoming a maintainer for
> Gentoo, since it would require less time and effort from their end
> 	- Might reduce the number of orphaned packages we have in the tree

Adding user repos to layman isn't good enough?
Plus, there's always sunrise.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Sébastien Fabbro]

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

On Wed, 5 Mar 2008, Anant Narayanan <anant@gentoo.org> wrote:
> 
> If it's not too late for this month's meeting, I'd like to discuss
> the possibility of including a new "post" in our developer base -
> the package maintainer.
> 

The idea is interesting. We have been thinking about something similar
in the sci team. We are already maintaining some packages we don't know
how to test. We also don't particularly like the idea of getting
scientific results based on untested software.

The overlays are not a solution. Packages in the overlays do not
go through keywording or stabilisation processes, do not get all the
publicity, and don't have bug support as advanced as the ones in the
main tree.

In all the sci* herds, we have more than 180 requests for new
packages only in bugzilla. Our active team is small and overloaded with
already more than 430 packages to maintain. Many other teams are facing
the same issue. We have contacted some talented ebuild submitters who
neither want to spend the time nor feel the responsibility of a full
dev. A formal proxy-maintainer could really help in our sometimes blind
maintaining duties.

--
Sébastien

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Ioannis Aslanidis]

For what I have been reading through, it seems that satisfying this
particular necessity for some herds would cause a problem to other
herds that are currently fine with the overlays or even with
proxy-maintenance. Perhaps a dual solution would fit better the needs
of everyone and improve the overall efficiency. There is no need to do
a change to worse where not applicable. Let the herds decide upon
their needs.

Just my 2 cents.

On Thu, Mar 6, 2008 at 10:02 AM, Sébastien Fabbro <bicatali@gentoo.org> wrote:
> On Wed, 5 Mar 2008, Anant Narayanan <anant@gentoo.org> wrote:
>  >
>  > If it's not too late for this month's meeting, I'd like to discuss
>  > the possibility of including a new "post" in our developer base -
>  > the package maintainer.
>  >
>
>  The idea is interesting. We have been thinking about something similar
>  in the sci team. We are already maintaining some packages we don't know
>  how to test. We also don't particularly like the idea of getting
>  scientific results based on untested software.
>
>  The overlays are not a solution. Packages in the overlays do not
>  go through keywording or stabilisation processes, do not get all the
>  publicity, and don't have bug support as advanced as the ones in the
>  main tree.
>


-- 
Ioannis Aslanidis

<deathwing00[at]gentoo.org> 0x47F370A0

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Marius Mauch]

On Thu, 6 Mar 2008 09:02:09 +0000
Sébastien Fabbro <bicatali@gentoo.org> wrote:

> We have contacted some talented ebuild submitters who neither want to
> spend the time nor feel the responsibility of a full dev.

Maybe we should try to solve that problem instead of making our
hierarchy even more complex.
What exact time constraints and responsibilities are people afraid of?
Are those concerns real or just myths?

> A formal proxy-maintainer could really help in our sometimes blind
> maintaining duties.

What would be the difference between a "formal proxy-maintainer" and
how we handle it currently?

Marius
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Natanael Copa]

On Fri, 2008-03-07 at 19:48 +0100, Marius Mauch wrote:

> What exact time constraints and responsibilities are people afraid of?
> Are those concerns real or just myths?

As someone who just sent in the quiz, yes its real concerns. What scared
me off mostly is the gentoo politics. The entire process to become a
"gentoo developer" is a scare off. Took me weeks to complete the quiz. I
want to help, yes, but I do have a life.

> > A formal proxy-maintainer could really help in our sometimes blind
> > maintaining duties.
> 
> What would be the difference between a "formal proxy-maintainer" and
> how we handle it currently?

It's documented? I hardly know it was possible. I have heard the term
proxy maintainer a few time and offerend to become one without beeing
100% what it was. I talked about to become a dev only to be able to
maintain a handful ebuilds but was even recommended to not do that due
to QA issues. That kind of turned me off [1].

At the same time I go the offer to maintain a package in FreeBSD. I said
yes because it was very simple. So I have been a freebsd ports
maintainer for years, while it took me years to actually take the step
to fill in the quiz, even if i run gentoo on desktop and run my own
distro based on Gentoo.

I'd probably not do the quiz again but I'd be more than happy to
maintain a few packages.

> Marius

-nc

[1]http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg15926.html

PS. The entire thread is kind of interesting to read.


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Alec Warner]

On 3/9/08, Natanael Copa <natanael.copa@gmail.com> wrote:
>
>  On Fri, 2008-03-07 at 19:48 +0100, Marius Mauch wrote:
>
>  > What exact time constraints and responsibilities are people afraid of?
>  > Are those concerns real or just myths?
>
>
> As someone who just sent in the quiz, yes its real concerns. What scared
>  me off mostly is the gentoo politics. The entire process to become a
>  "gentoo developer" is a scare off. Took me weeks to complete the quiz. I
>  want to help, yes, but I do have a life.

If you have other methods to avoid contributors who suck; I'd like to hear them.

We have had problems where people sign up in the past and then never
do anything and it wastes our time trying to teach them how the tree
works.  We would rather spend that time helping out developers who
like, actually do work.

>
>
>  > > A formal proxy-maintainer could really help in our sometimes blind
>  > > maintaining duties.
>  >
>  > What would be the difference between a "formal proxy-maintainer" and
>  > how we handle it currently?
>
>
> It's documented? I hardly know it was possible. I have heard the term
>  proxy maintainer a few time and offerend to become one without beeing
>  100% what it was. I talked about to become a dev only to be able to
>  maintain a handful ebuilds but was even recommended to not do that due
>  to QA issues. That kind of turned me off [1].

Granted, that e-mail was from October 2006 ;)

>
>  At the same time I go the offer to maintain a package in FreeBSD. I said
>  yes because it was very simple. So I have been a freebsd ports
>  maintainer for years, while it took me years to actually take the step
>  to fill in the quiz, even if i run gentoo on desktop and run my own
>  distro based on Gentoo.

I can certainly invision cvs ACLs if people are worried about that
sort of thing; but it doesn't mitigate the fact that maintainers need
to know what they are doing.

Did freeBSD not care if you knew what you were doing?  What happens if
you totally screw up your package?  What happens if you do something
malicious?

>
>  I'd probably not do the quiz again but I'd be more than happy to
>  maintain a few packages.
>
>  > Marius
>
>  -nc
>
>  [1]http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg15926.html
>
>  PS. The entire thread is kind of interesting to read.
>
>
>
>  --
>  gentoo-dev@lists.gentoo.org mailing list
>
>
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Roy Marples]

On Monday 10 March 2008 05:21:51 Alec Warner wrote:
> Did freeBSD not care if you knew what you were doing?  What happens if
> you totally screw up your package?  What happens if you do something
> malicious?

Gentoo has a cvs-commit mailing list, so everyone knows if they care enough.

I suggest you remove those rose tinted specs of yours unless you are 
suggesting that a Gentoo dev has never committed a broken ebuild or eclass :) 
Devs make mistakes, only less than other people by virtue of spending more 
time working on similar stuff.

Lastly, taking a quiz is no measure of being malicious or not. You would have 
to interact with the person to know if they are capable for that.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Denis Dupeyron]

On Mon, Mar 10, 2008 at 9:29 AM, Roy Marples <roy@marples.name> wrote:
>  Lastly, taking a quiz is no measure of being malicious or not.

As I wrote elsewhere, the recruitment process is more than just the quizzes.

> You would have
>  to interact with the person to know if they are capable for that.

Which is exactly what happens during that other important part of the
recruitment process, i.e. the review. It gives no guaranty of the
future dev not being malicious, but we at least get a good idea and
can refuse him/her if we feel it's necessary. This has happened once
since I've been a recruiter, after lengthy discussions and
investigations.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Natanael Copa]

On Sun, 2008-03-09 at 21:21 -0800, Alec Warner wrote:
> On 3/9/08, Natanael Copa <natanael.copa@gmail.com> wrote:
> >
> >  On Fri, 2008-03-07 at 19:48 +0100, Marius Mauch wrote:
> >
> >  > What exact time constraints and responsibilities are people afraid of?
> >  > Are those concerns real or just myths?
> >
> >
> > As someone who just sent in the quiz, yes its real concerns. What scared
> >  me off mostly is the gentoo politics. The entire process to become a
> >  "gentoo developer" is a scare off. Took me weeks to complete the quiz. I
> >  want to help, yes, but I do have a life.
> 
> If you have other methods to avoid contributors who suck; I'd like to hear them.

I don't have any silver bullets, sorry.

> I can certainly invision cvs ACLs if people are worried about that
> sort of thing; but it doesn't mitigate the fact that maintainers need
> to know what they are doing.

ACL's... yuck... git might be an idea though. "signed-off-by", kernel
style. Don't have enough experience with gentoo managemet to know if git
fit's the management style. (probably not, since its not used already)

> Did freeBSD not care if you knew what you were doing?  What happens if
> you totally screw up your package?  What happens if you do something
> malicious?

I'm a "maintainer" not a "committer". I don't have commit access.

-nc

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Peter Volkov]

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

В Пнд, 10/03/2008 в 06:12 +0100, Natanael Copa пишет:
> Took me weeks to complete the quiz. I want to help, yes, but I do have
> a life.

What were the problems? Do you think that knowledge of answers to the
questions asked in quiz are not required to do actual work on ebuilds in
the tree? What were that questions?

> It's documented?

It is mentioned in some places on website but no, it's not documented as
I see.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Alec Warner]

On 3/10/08, Peter Volkov <pva@gentoo.org> wrote:
> В Пнд, 10/03/2008 в 06:12 +0100, Natanael Copa пишет:
>
> > Took me weeks to complete the quiz. I want to help, yes, but I do have
>  > a life.
>
>
> What were the problems? Do you think that knowledge of answers to the
>  questions asked in quiz are not required to do actual work on ebuilds in
>  the tree? What were that questions?
>
>  > It's documented?
>
>  It is mentioned in some places on website but no, it's not documented as
>  I see.

It is one of many of my dead projects ;)

http://dev.gentoo.org/~antarus/projects/proxy-maint/

>
>  --
>
> Peter.
>
>
│ИМ╒┤^╬X╛╤х\x1e·з(╒╦&j)b·	b╡

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Peter Volkov]

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

В Пнд, 10/03/2008 в 04:13 -0800, Alec Warner пишет:
> On 3/10/08, Peter Volkov <pva@gentoo.org> wrote:
> > В Пнд, 10/03/2008 в 06:12 +0100, Natanael Copa пишет:
> >  > It's documented?
> >
> >  It is mentioned in some places on website but no, it's not documented as
> >  I see.
> 
> It is one of many of my dead projects ;)
> 
> http://dev.gentoo.org/~antarus/projects/proxy-maint/

This is outside www.gentoo.org :P

And it's not clear how to became proxy-maintainer. Also current list of
proxy-maintainers could be grep'ed from metadata.xml. e.g. for shorewall
proxy-maintainer is listed in maintainer tag, just have not @gentoo.org
e-mail. But may be we should introduce some attribute (proxy-maintainer)
to mark position explicitly. And all current developers are commiters...

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Monthly Gentoo Council Reminder for March

[Ryan Hill]

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

Anant Narayanan wrote:

> P.P.S. Maybe this is more suited for -project, but everyone knows that 
> nobody reads that list :-p

Only because nobody posts there.  Knock it off. ;P


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Jeroen Roovers]

On 01 Mar 2008 05:30:01
Mike Frysinger <vapier@gentoo.org> wrote:

> This is your monthly friendly reminder !  Same bat time (typically
> the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
> (#gentoo-council @ irc.freenode.net) !
> 
> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know !  Simply reply to this e-mail for the whole
> Gentoo dev list to see.

The list of architectures that Gentoo supports is one of its greatest
assets. It is important that Gentoo makes available an as large as
possible set of packages to as many platforms as is sanely doable. For
this purpose we have a testing and stabilisation system that depends on
architecture keywords being propagated from one version to the next. I
would like to stress to all package maintainers that dropping keywords,
i.e. removing any architecture's keyword entirely, instead of replacing
"arch" with "~arch", _hurts_ the Gentoo Project.

Dropping a keyword should be done in exactly three cases:
1) When newly added dependencies for a version have not been keyworded.
2) When there is evidence that the new version contains architecture
porting regressions, i.e. upstream knows or strongly suspects that a
specific version no longer supports a specific architecture.
3) When a precompiled version is not available for a specific
architecture.

When a keyword is being dropped for one of the three reasons stated
above, the relevant arch team should be notified by way of a bug,
assigned to the package maintainer, and the arch team should be CC'd,
explaining what should be done to validate readding the dropped
keyword. Of course, if any dependencies can be keyworded in advance of
adding the ebuild for which keywords would need to be dropped, as long
as the arch teams respond in due time by keywording the new
dependencies, dropping the keywords can be prevented entirely and fewer
developers will get less work on their hands, but this does require
better planning, and possibly holding off committing the new ebuild for
a week (or two).

When keywords have been dropped invalidly, a bug should be reported and
assigned to the package maintainer. Arch teams should not be burdened
with this task but may be CC'd on the bug to notify them of the
situation. It should be clear to all ebuild developers that maintaining
keywords is not the domain of the arch teams: Like the rest of any
ebuild, it is the maintainer's responsibility to ensure keywords are
soundly propagated from one version to the next, and the maintainer's
responsibility to correct when a keyword has been dropped.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Petteri Räty]

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

Jeroen Roovers kirjoitti:
> On 01 Mar 2008 05:30:01
> Mike Frysinger <vapier@gentoo.org> wrote:
> 
>> This is your monthly friendly reminder !  Same bat time (typically
>> the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
>> (#gentoo-council @ irc.freenode.net) !
>>
>> If you have something you'd wish for us to chat about, maybe even
>> vote on, let us know !  Simply reply to this e-mail for the whole
>> Gentoo dev list to see.
> 
> The list of architectures that Gentoo supports is one of its greatest
> assets. It is important that Gentoo makes available an as large as
> possible set of packages to as many platforms as is sanely doable. For
> this purpose we have a testing and stabilisation system that depends on
> architecture keywords being propagated from one version to the next. I
> would like to stress to all package maintainers that dropping keywords,
> i.e. removing any architecture's keyword entirely, instead of replacing
> "arch" with "~arch", _hurts_ the Gentoo Project.
> 

I couldn't find in your post what you want the council to discuss?

Regards,
Petteri


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Jeroen Roovers]

On Thu, 06 Mar 2008 22:41:12 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:

> Jeroen Roovers kirjoitti:
> > On 01 Mar 2008 05:30:01
> > Mike Frysinger <vapier@gentoo.org> wrote:
> > 
> >> This is your monthly friendly reminder !  Same bat time (typically
> >> the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
> >> (#gentoo-council @ irc.freenode.net) !
> >>
> >> If you have something you'd wish for us to chat about, maybe even
> >> vote on, let us know !  Simply reply to this e-mail for the whole
> >> Gentoo dev list to see.
> > 
> > The list of architectures that Gentoo supports is one of its
> > greatest assets. It is important that Gentoo makes available an as
> > large as possible set of packages to as many platforms as is sanely
> > doable. For this purpose we have a testing and stabilisation system
> > that depends on architecture keywords being propagated from one
> > version to the next. I would like to stress to all package
> > maintainers that dropping keywords, i.e. removing any
> > architecture's keyword entirely, instead of replacing "arch" with
> > "~arch", _hurts_ the Gentoo Project.
> > 
> 
> I couldn't find in your post what you want the council to discuss?

One current and pressing issue. Neatly explained, a solution thought
through and well layed out. As a Council you'd only need to lay down
the law.
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Petteri Räty]

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

Jeroen Roovers kirjoitti:
> On Thu, 06 Mar 2008 22:41:12 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
> 
>> Jeroen Roovers kirjoitti:
>>> On 01 Mar 2008 05:30:01
>>> Mike Frysinger <vapier@gentoo.org> wrote:
>>>
>>>> This is your monthly friendly reminder !  Same bat time (typically
>>>> the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
>>>> (#gentoo-council @ irc.freenode.net) !
>>>>
>>>> If you have something you'd wish for us to chat about, maybe even
>>>> vote on, let us know !  Simply reply to this e-mail for the whole
>>>> Gentoo dev list to see.
>>> The list of architectures that Gentoo supports is one of its
>>> greatest assets. It is important that Gentoo makes available an as
>>> large as possible set of packages to as many platforms as is sanely
>>> doable. For this purpose we have a testing and stabilisation system
>>> that depends on architecture keywords being propagated from one
>>> version to the next. I would like to stress to all package
>>> maintainers that dropping keywords, i.e. removing any
>>> architecture's keyword entirely, instead of replacing "arch" with
>>> "~arch", _hurts_ the Gentoo Project.
>>>
>> I couldn't find in your post what you want the council to discuss?
> 
> One current and pressing issue. Neatly explained, a solution thought
> through and well layed out. As a Council you'd only need to lay down
> the law.

Isn't what you wrote the existing policy?

Regards,
Petteri


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Ulrich Mueller]

>>>>> On Fri, 07 Mar 2008, Petteri Räty wrote:
>>> Jeroen Roovers kirjoitti:
>>>> The list of architectures that Gentoo supports is one of its
>>>> greatest assets. It is important that Gentoo makes available
>>>> an as large as possible set of packages to as many platforms
>>>> as is sanely doable. For this purpose we have a testing and
>>>> stabilisation system that depends on architecture keywords
>>>> being propagated from one version to the next. I would like
>>>> to stress to all package maintainers that dropping keywords,
>>>> i.e. removing any architecture's keyword entirely, instead of
>>>> replacing "arch" with "~arch", _hurts_ the Gentoo Project.

> Isn't what you wrote the existing policy?

If it is, then the last question of the end-quiz should be changed:

| 19. You are bumping foomatic's ebuild from version 1.5 to version
|     2.0. This new version is a massive rewrite which introduces
|     huge changes to the build system, the required libraries
|     and how the code works. What will you do for KEYWORDS here?

My answer to it (about one year ago) wasn't in agreement with Jeroen's
above statement, but my mentor and my recruiter were satisfied with it
at the time.

Ulrich
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[George Shapovalov]

Friday, 7. March 2008, Ulrich Mueller Ви написали:
> > Isn't what you wrote the existing policy?
>
> If it is, then the last question of the end-quiz should be changed:
> | 19. You are bumping foomatic's ebuild from version 1.5 to version
> |     2.0. This new version is a massive rewrite which introduces
> |     huge changes to the build system, the required libraries
> |     and how the code works. What will you do for KEYWORDS here?
But there are different situations, and there are two questions in the quiz to 
reflect that (IIRC the other one is one or two questions before this #19). 
And, I believe, these were added after the issue was brought up by arch 
testers here quite some time ago. Rhat is, there is a difference between a 
trivial bump and a major update. E.g., you don't expect trouble from some 
minor bug fix but things may not work anymore or require major adjustments 
when some big backend changes are made or build system is changed (like 
recently it became popular to replace autotools with CMake).

George
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

[Petteri Räty]

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

Ulrich Mueller kirjoitti:
> 
>> Isn't what you wrote the existing policy?
> 
> If it is, then the last question of the end-quiz should be changed:
> 
> | 19. You are bumping foomatic's ebuild from version 1.5 to version
> |     2.0. This new version is a massive rewrite which introduces
> |     huge changes to the build system, the required libraries
> |     and how the code works. What will you do for KEYWORDS here?
> 
> My answer to it (about one year ago) wasn't in agreement with Jeroen's
> above statement, but my mentor and my recruiter were satisfied with it
> at the time.
> 
> Ulrich

How is the question wrong? You are just stating the recruiters didn't 
think the answer was what it was supposed to be.

Regards,
Petteri


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

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Alec Warner]

[+gentoo-dev]

I'm just going to jump randomly in here.

Also, moving this back to -dev as it is not a private matter.

The bread and butter of this is what:

A. KDE team drops arch keywords for KDE 4, since KDE4 is new.

B. Jer re-keywords KDE4 on HPPA but doesn't try installing the
software to make sure it works.

C. Jer misses keywords because the KDE team did not provide a distinct
list of packages and Jer was relying on repoman to notify him when he
broke the deptree for HPPA.  Repoman has a bug/feature that caused it
to behave in an unexpected manner.

So I think most people think A. is an acceptable practice.  For all
intents and purposes KDE4 is new software.  Does anyone disagree with
this?

I think C is both Jer's and the KDE teams fault.  How difficult is it
really to produce a distinct package list KDE team?  You could always
refuse to keyword without such a list.

I think B is the real argument here.  Typically when commiting
packages you are supposed to install them and at least (in the case of
KDE) log into KDE and make sure it at least works.

Jer, did you do this?  If not; do you understand why the other
developers are upset?  Really I think they just want you to test
things you are keywording.

-Alec
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Wulf C. Krueger]

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

> A. KDE team drops arch keywords for KDE 4, since KDE4 is new.

Basically, yes.

> C. Jer misses keywords because the KDE team did not provide a distinct
> list of packages

Because we didn't even ask for re-keywording. :-)

KDE 4.0.x leaves much to be desired which is why it's p.masked (which  
is, btw, another place a list could be found :) ).

> I think C is both Jer's and the KDE teams fault.  How difficult is it
> really to produce a distinct package list KDE team?

It isn't hard. We have it on kde.gentoo.org and in p.mask. :-)

See above, though: We didn't even ask for re-keywording in the first  
place. When we do (or ask for stabilisation), we always provide lists.

-- 
Best regards, Wulf


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

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Alec Warner]

On 3/10/08, Wulf C. Krueger <philantrop@gentoo.org> wrote:
> > A. KDE team drops arch keywords for KDE 4, since KDE4 is new.
>
>
> Basically, yes.
>
>
>  > C. Jer misses keywords because the KDE team did not provide a distinct
>  > list of packages
>
>
> Because we didn't even ask for re-keywording. :-)

According to Rej you dropped the hppa keyword without informing him.

The current policy states that you should file a bug in this case.  Did you?

If there is no documentation for the dropped keyword then Rej could
easily conclude that the dropped keyword was a mistake and fix it.

Also who detected the brokenness and who fixed it?

-Alec
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Wulf C. Krueger]

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

>>  > C. Jer misses keywords because the KDE team did not provide a distinct
>>  > list of packages
>> Because we didn't even ask for re-keywording. :-)
> According to Rej you dropped the hppa keyword without informing him.

That is correct.

> The current policy states that you should file a bug in this case.  Did you?

No, we didn't because the whole thing is p.masked for a reason. It,  
KDE 4.0.1, is broken crap that should not yet be re-keyworded.

We will file a bug for 4.0.2 at the earliest.

> If there is no documentation for the dropped keyword then Rej could
> easily conclude that the dropped keyword was a mistake and fix it.

When you find 208 (!) packages

1. that have all keywords but ~amd64 and ~x86 dropped,
2. which are package.masked with prominent notice,
3. the maintainers of which are available,

do you assume that was a mistake and randomly keyword stuff or do you  
ask the maintainers? :-)

> Also who detected the brokenness and who fixed it?

Nothing was broken before the failed re-keywording attempt.

-- 
Best regards, Wulf

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

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Ryan Hill]

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

Jeroen Roovers wrote:
> On Mon, 10 Mar 2008 16:26:19 +0100
> "Wulf C. Krueger" <philantrop@gentoo.org> wrote:
> 
>> No, we didn't because the whole thing is p.masked for a reason. It,  
>> KDE 4.0.1, is broken crap that should not yet be re-keyworded.
> 
> OK then. and I am not going to cross-post this to -dev@, btw: why the
> hell did you decide to put broken crap in the tree? It should never have
> left your repository, it seems.

It's package masked and unkeyworded, which is a big hint that it's under 
development.

> If you still wonder why I started rekeywording for HPPA, then let this
> be the final answer. It was no fault of mine - I did it on purpose. No
> keywording error - I was going to finish all the dependencies if you
> hadn't asked me not to (because by then you were claiming KDE team
> "reserves" the "right" to drop keywords at will and without notifying
> arch teams, as opposed to current policy. The repoman bug / missing
> feature left a few stones unturned, sadly, but I was going to do all of
> KDE 4.

You're still not getting this.  The KDE team did not _want_ these ebuilds 
keyworded.  That's why they _weren't_ keyworded.  That's why there was no bug 
filed, saying "hey we dropped these keywords" because they _did not want_ you to 
add them back yet.  When the ebuilds were of sufficient quality that they could 
be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded.

Maintainers have every right to drop keywords if they think changes to their 
package are drastic enough to require re-evaluation by an architecture team. 
It's how we keep big fat calamity from befalling our users.  Yes, they need to 
inform the arch teams to re-add their keywords.  No that request does not need 
to come immediately if they're not ready for it.

A simple rule to go by:  Dropped keywords on package.masked packages are not 
dropped keywords.  If that package comes out of package.mask and still lacks 
your keyword and no bug is filed, then yes, then you have a legitimate beef.

This is simply the way things work from my point of view as a maintainer and a 
arch dev for a oft keyword-dropped arch.


-- 
fonts, gcc-porting,                               by design, by neglect
mips, treecleaner,                        for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


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

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Alec Warner]

On 3/10/08, Ryan Hill <dirtyepic@gentoo.org> wrote:
> Jeroen Roovers wrote:
>  > On Mon, 10 Mar 2008 16:26:19 +0100
>  > "Wulf C. Krueger" <philantrop@gentoo.org> wrote:
>  >
>  >> No, we didn't because the whole thing is p.masked for a reason. It,
>  >> KDE 4.0.1, is broken crap that should not yet be re-keyworded.
>  >
>  > OK then. and I am not going to cross-post this to -dev@, btw: why the
>  > hell did you decide to put broken crap in the tree? It should never have
>  > left your repository, it seems.
>
>
> It's package masked and unkeyworded, which is a big hint that it's under
>  development.

So Jer should just implicitly know not to keyword it?  Why not make it
explicit?  That is all I am really asking for here.

>
>
>  > If you still wonder why I started rekeywording for HPPA, then let this
>  > be the final answer. It was no fault of mine - I did it on purpose. No
>  > keywording error - I was going to finish all the dependencies if you
>  > hadn't asked me not to (because by then you were claiming KDE team
>  > "reserves" the "right" to drop keywords at will and without notifying
>  > arch teams, as opposed to current policy. The repoman bug / missing
>  > feature left a few stones unturned, sadly, but I was going to do all of
>  > KDE 4.
>
>
> You're still not getting this.  The KDE team did not _want_ these ebuilds
>  keyworded.  That's why they _weren't_ keyworded.  That's why there was no bug
>  filed, saying "hey we dropped these keywords" because they _did not want_ you to
>  add them back yet.  When the ebuilds were of sufficient quality that they could
>  be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded.

Right, but you did not make your want known, so how is Jer to know?

>
>  Maintainers have every right to drop keywords if they think changes to their
>  package are drastic enough to require re-evaluation by an architecture team.
>  It's how we keep big fat calamity from befalling our users.  Yes, they need to
>  inform the arch teams to re-add their keywords.  No that request does not need
>  to come immediately if they're not ready for it.
>
>  A simple rule to go by:  Dropped keywords on package.masked packages are not
>  dropped keywords.  If that package comes out of package.mask and still lacks
>  your keyword and no bug is filed, then yes, then you have a legitimate beef.
>
>  This is simply the way things work from my point of view as a maintainer and a
>  arch dev for a oft keyword-dropped arch.

RIght but if everyone is not following the same rules you
get...well...this exact situation.  The whole point of this discussion
is not to assign blame, it is to figure out what we should change so
this doesn't happen again as it obviously upset lots of folks.

-Alec

>
>
>
>  --
>  fonts, gcc-porting,                               by design, by neglect
>  mips, treecleaner,                        for a fact or just for effect
>  wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
>
>
>
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Richard Freeman]

Alec Warner wrote:
> On 3/10/08, Ryan Hill <dirtyepic@gentoo.org> wrote:
>> You're still not getting this.  The KDE team did not _want_ these ebuilds
>>  keyworded.  That's why they _weren't_ keyworded.  That's why there was no bug
>>  filed, saying "hey we dropped these keywords" because they _did not want_ you to
>>  add them back yet.  When the ebuilds were of sufficient quality that they could
>>  be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded.
> 
> Right, but you did not make your want known, so how is Jer to know?
> 

I don't really want to get into the specifics of this situation but
wanted to raise a question of policy.

My understanding is that arch teams shouldn't keyword anything without
the OK of the maintainer - usually in the form of a STABLEREQ bug.  When
I get stable requests from users I don't act on them until I hear from
the maintainer for this reason.

I know that at one point there was discussion of having a ~maint/maint
keywords that would be used just to indicate the intent of the
maintainer for each package.  Then all the usual keyword-comparison
tools could be used to detect packages that are ready for keywording.

I would be pretty annoyed as a maintainer if I started getting a deluge
of bug reports and complaints from end users who didn't intend to run
broken software if somebody unmasked or keyworded something that I
didn't intend anybody to be using aside from a few brave souls willing
to risk everything to try out some new software.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-core] Keywords policy

[Ferris McCormick]

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

(Probably off topic?  I think Richard said something he didn't intend.)

On Tue, 2008-03-11 at 11:24 -0400, Richard Freeman wrote:
> Alec Warner wrote:
> > On 3/10/08, Ryan Hill <dirtyepic@gentoo.org> wrote:
> >> You're still not getting this.  The KDE team did not _want_ these ebuilds
> >>  keyworded.  That's why they _weren't_ keyworded.  That's why there was no bug
> >>  filed, saying "hey we dropped these keywords" because they _did not want_ you to
> >>  add them back yet.  When the ebuilds were of sufficient quality that they could
> >>  be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded.
> > 
> > Right, but you did not make your want known, so how is Jer to know?
> > 
> 
> I don't really want to get into the specifics of this situation but
> wanted to raise a question of policy.
> 
> My understanding is that arch teams shouldn't keyword anything without
> the OK of the maintainer - usually in the form of a STABLEREQ bug.  When
> I get stable requests from users I don't act on them until I hear from
> the maintainer for this reason.
> 

Um, not really --- this is too broad.  Some packages are not keyworded
because no one has ever tried them.  We occasionally get keyword
requests of the form "Please add ~sparc keyword to .... because I've
been using it and it works fine" in response to which we do add the
keyword if it does work.  No maintainer action involved, because the
maintainer apparently doesn't know if the package works on sparc or not
anyway.  A STABLEREQ is a different matter, masked packages are a
different matter, but not just keywording.

--- snip ---

Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees)

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

Re: [gentoo-dev] Re: [gentoo-core] Keywords policy

[Richard Freeman]

Ferris McCormick wrote:
> 
> Um, not really --- this is too broad.  Some packages are not keyworded
> because no one has ever tried them.  We occasionally get keyword
> requests of the form "Please add ~sparc keyword to .... because I've
> been using it and it works fine" in response to which we do add the
> keyword if it does work.  No maintainer action involved, because the
> maintainer apparently doesn't know if the package works on sparc or not
> anyway.  A STABLEREQ is a different matter, masked packages are a
> different matter, but not just keywording.
> 

If the package were already keyworded ~arch on a few other archs I
wouldn't hesitate to add ~amd64 if it worked on amd64.  However, if a
package were ~arch on several archs I would not keyword it stable amd64
without the maintainer's input (or at least lack of response in the case
of an inactive maintainer).  I don't think maintainers need to be bugged
all the time, but they should be asked about making an ebuild stable for
the first time, or unmasking/etc.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Ryan Hill]

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

Alec Warner wrote:
> On 3/10/08, Ryan Hill <dirtyepic@gentoo.org> wrote:
>> Jeroen Roovers wrote:
>>  > On Mon, 10 Mar 2008 16:26:19 +0100
>>  > "Wulf C. Krueger" <philantrop@gentoo.org> wrote:
>>  >
>>  >> No, we didn't because the whole thing is p.masked for a reason. It,
>>  >> KDE 4.0.1, is broken crap that should not yet be re-keyworded.
>>  >
>>  > OK then. and I am not going to cross-post this to -dev@, btw: why the
>>  > hell did you decide to put broken crap in the tree? It should never have
>>  > left your repository, it seems.
>>
>> It's package masked and unkeyworded, which is a big hint that it's under
>>  development.
> 
> So Jer should just implicitly know not to keyword it?  Why not make it
> explicit?  That is all I am really asking for here.

How much more explicit can you make it than dropping every arch's keywords and 
putting it in package mask?  The problem here is that Jeroen decided that this 
was a violation of the keyword policy and blindly added his keywords back.  Fair 
enough, everyone makes a mistake from time to time.  But after more than a few 
people have tried to explain why this was a mistake, he still refuses to admit 
it and claims the keywords were dropped illegally.  I'm just pointing out that 
this is not the case, and never has been.  If a maintainer package masks an 
ebuild, you don't mess with it without talking to them.  This is coming straight 
from the handbook.

>>  > If you still wonder why I started rekeywording for HPPA, then let this
>>  > be the final answer. It was no fault of mine - I did it on purpose. No
>>  > keywording error - I was going to finish all the dependencies if you
>>  > hadn't asked me not to (because by then you were claiming KDE team
>>  > "reserves" the "right" to drop keywords at will and without notifying
>>  > arch teams, as opposed to current policy. The repoman bug / missing
>>  > feature left a few stones unturned, sadly, but I was going to do all of
>>  > KDE 4.
>>
>> You're still not getting this.  The KDE team did not _want_ these ebuilds
>>  keyworded.  That's why they _weren't_ keyworded.  That's why there was no bug
>>  filed, saying "hey we dropped these keywords" because they _did not want_ you to
>>  add them back yet.  When the ebuilds were of sufficient quality that they could
>>  be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded.
> 
> Right, but you did not make your want known, so how is Jer to know?

>>  Maintainers have every right to drop keywords if they think changes to their
>>  package are drastic enough to require re-evaluation by an architecture team.
>>  It's how we keep big fat calamity from befalling our users.  Yes, they need to
>>  inform the arch teams to re-add their keywords.  No that request does not need
>>  to come immediately if they're not ready for it.
>>
>>  A simple rule to go by:  Dropped keywords on package.masked packages are not
>>  dropped keywords.  If that package comes out of package.mask and still lacks
>>  your keyword and no bug is filed, then yes, then you have a legitimate beef.
>>
>>  This is simply the way things work from my point of view as a maintainer and a
>>  arch dev for a oft keyword-dropped arch.
> 
> RIght but if everyone is not following the same rules you
> get...well...this exact situation.  The whole point of this discussion
> is not to assign blame, it is to figure out what we should change so
> this doesn't happen again as it obviously upset lots of folks.

As far as I know this is policy.  It has worked so far, but if something needs 
to change then so be it.


-- 
fonts, gcc-porting,                               by design, by neglect
mips, treecleaner,                        for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


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

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Ryan Hill]

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

Jeroen Roovers wrote:
> On Tue, 11 Mar 2008 04:49:38 +0100
> Jeroen Roovers <jer@gentoo.org> wrote:
> 
>> On Mon, 10 Mar 2008 16:26:19 +0100
>> "Wulf C. Krueger" <philantrop@gentoo.org> wrote:
>>
>>> No, we didn't because the whole thing is p.masked for a reason.
>>> It, KDE 4.0.1, is broken crap that should not yet be re-keyworded.
>> OK then. and I am not going to cross-post this to -dev@, btw: why the
>> hell did you decide to put broken crap in the tree? It should never
>> have left your repository, it seems.
> 
> The follow-up question, by the way, is even better, or it's answer
> should be: if the description of KDE teams keyword dropping policy on
> bug #209418 is anything to go by, the keywords for x86 and amd64 should
> have been dropped as well, or testing passed miraculously for these
> arches despite KDE 4.0.1 being broken crap.

These would be the architectures they have access to and are using to do the 
development work on these ebuilds, getting them to the point where ready for 
evaluation by those on other architectures.  Just like when you add a new 
ebuild, you add it with the keywords for architectures you personally have 
verified to work.


-- 
fonts, gcc-porting,                               by design, by neglect
mips, treecleaner,                        for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


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

[gentoo-dev] Re: [gentoo-core] Keywords policy

[Peter Volkov]

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

В Втр, 11/03/2008 в 06:36 +0100, Jeroen Roovers пишет:
> On Mon, 10 Mar 2008 23:04:54 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> 
> > Just like when you add a new ebuild, you add it with the keywords for
> > architectures you personally have verified to work.
> 
> It seems you're confusing packages and ebuilds now.

Jeroen, there are two different things that were already told in this
tread, but I'll try to repeat in different words, in hope to make them
clearer.

1. keywords were dropped on purpose: kde-4 is a major rewrite and it is
supposed to be thoroughly tested by arch team before becoming ~arch.
This fits our current policy.

2. you can not expect anything about the hardmasked ebuild/package[1]:
don't expect that it'll work, don't expect maintainers to tell you
anything (fill you bug) about it. We have such packages in the tree
because some brave users[2] and maintainers want to test them before
they'll enter ~arch. But for users we have policy to prohibit bugs for
hardmasked packages because if you want to report anything back you are
supposed to follow Gentoo and upstream development and if you follow,
you'll know what reports are allowed and that this policy is not quite
true :). If you'd followed kde development you'd were aware about
changes and you tested packages together with kde developers and ebuilds
entered tree with ~hppa. You don't follow kde development than it's
better not to touch hardmasked kde packages.

So if you want to see another policy it's possible to write that arch
teams should not bother to work with hardmasked ebuilds and that's it.
But I do not think we need such policy as hardmasked means hidden far
from users...


[1] yes, the are the same in this context
[2] developers who are not maintainers are users too

With best wishes,
-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]