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

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

[Duncan]

Ciaran McCreesh <ciaranm@ciaranm.org> posted
20070405092817.79df34d3@snowflake, excerpted below, on  Thu, 05 Apr 2007
09:28:17 +0100:

> On Wed, 4 Apr 2007 01:51:56 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
>>  - PMS:
>> 	- status update from spb
>> 	- moving it to Gentoo svn
>> 	- schedule for getting remaining issues settled
> 
> Same question as last time this came up:
> 
> Can you name any other projects where the Council has become involved in
> scheduling issues?

If I may... take this as at least certain members of the council agreeing 
with you that certain package management issues are holding up Gentoo 
(note, I did NOT say portage, per se, but package management issues in 
general, I'm deliberately leaving it at that general level).  Logically, 
an agreement on some sort of current base package spec, PMS, is, I 
believe most will agree, the next big step in resolving that issue.

Viewed from that angle, the repeated emphasis on a time-line of sorts 
(regardless of the word used to communicate the idea), let's say for 
argument's sake (since I don't know others, but am not at a level to know 
for sure) uniquely, only underscores the importance the council (or 
certain members thereof, anyway) is now attaching to the issue.

Or are you now arguing that movement on package management is /not/ 
holding back Gentoo, now?

BTW, from my read of the portage-dev list, there are several things there 
on hold for EAPI-1, as well, and while a full definition of EAPI-0 isn't 
absolutely necessary before moving on EAPI-1, if it's possible time-wise, 
it's the most logical and convenient way, so that too is holding on the 
definition of EAPI-0, meaning all three projects appear to be awaiting it 
in some form or another, thus making it even /more/ critical timewise, 
regardless of how things turn out package-manager-wise down the pike.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

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

[Steve Long]

Ciaran McCreesh wrote:
> Unfortunately, what the GLEP doesn't do is prevent the Council from
> having secret meetings and refusing to discuss not only the content of
> those meetings but even the topic. Perhaps a requirement that any
> Council meeting logs be made public would be useful, with a waiver
> that the Council can have a secret meeting if it officially announces
> that it is doing so?
> 
This is getting silly; a secret meeting which is officially announced?

You cannot stop people from talking amongst themselves. It doesn't work and
it's counter-productive. Consulting a PR in recent times was a smart move,
and not one that can be done in the public glare, akin to a discussion with
an attorney. I for one am glad the Council did it, and gladder still that
it was in confidence.

I have no interest in knowing all the ins and outs, so long as there are
people there who _will_ sort out issues which have to be dealt with. In my
estimation, there are a good set of dedicated individuals who truly care
about gentoo. I might not agree with everything they do or say; so what?
They provide the best distro out there, and contrary to your allegations,
for a user it's better and more stable than ever.

Comparing binary package managers to a source-based one is facile imo. RH or
Ubuntu can do what they want: the competition for gentoo is basically
sourcemage. There are loads of gentoo users who have never had to reinstall
in several years of use. That simply doesn't happen with the `competition'
which you cite.

It seems like gentoo is going from a cottage-industry to a medium-size
organisation. People can work for the same organisation, sharing the same
general ideals, but with completely different approaches; they just work on
different teams. imo that's a good thing, so long as all acknowledge that
there is a _collective_ goal, which no individual could achieve, and agreed
standards of behaviour are upheld.


-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 5 Apr 2007 10:37:28 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Ciaran McCreesh <ciaranm@ciaranm.org> posted
> 20070405092817.79df34d3@snowflake, excerpted below, on  Thu, 05 Apr
> 2007 09:28:17 +0100:
> 
> > On Wed, 4 Apr 2007 01:51:56 -0400
> > Mike Frysinger <vapier@gentoo.org> wrote:
> >>  - PMS:
> >> 	- status update from spb
> >> 	- moving it to Gentoo svn
> >> 	- schedule for getting remaining issues settled
> > 
> > Same question as last time this came up:
> > 
> > Can you name any other projects where the Council has become
> > involved in scheduling issues?
> 
> If I may... take this as at least certain members of the council
> agreeing with you that certain package management issues are holding
> up Gentoo (note, I did NOT say portage, per se, but package
> management issues in general, I'm deliberately leaving it at that
> general level).
<snip>
> Or are you now arguing that movement on package management is /not/ 
> holding back Gentoo, now?

I want a consistent answer, and to know why the Council considers PMS
to be more important time-wise than, as far as I can see, any other
project ever.

-- 
Ciaran McCreesh


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

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

[Steve Long]

Ciaran McCreesh wrote:

> On Thu, 05 Apr 2007 12:24:06 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
>> Well, from what I can gather, he only *thinks* he knows what was going
>> on and he's filled in the blanks himself with whatever ideas he's come
>> up with on his own.  If he really does have the logs, he wouldn't be
>> spouting off at the mouth since he would know that there's nothing
>> damning in there, at all.
> 
> I know that you and kingtaco threatened to remove a fellow Council
> member's access if he didn't go along with you on whatever it was you
> were discussing. If there's nothing damning in there, why would you do
> such a thing?
> 
>From what I have read so far, it wasn't a question of someone being
pressured to "go along with.. whatever it was <they> were discussing" but
rather to keep a confidence. Mr Gianelloni is right: if other parties
cannot have confidential discussions with Gentoo, it will damage the
distribution. As such, it is imo incumbent upon council members to keep
such matters (whatever they might be) private.

He has already stipulated that "all decisions we made were 100% public"
and "We do have to have all of our decisions made public, obviously."

That's transparent enough for me at least. I don't want to be privy to every
discussion, and I certainly don't want to know about say aspects of other
people's private lives which might affect their work, or even that company
X is having confidential talks with gentoo, which might come to nothing. I
just want to enjoy the software and the community, and these frankly
paranoid ramblings make the dev list much less fun.


-- 
gentoo-dev@gentoo.org mailing list

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

[Torsten Veller]

* Mike Doty <kingtaco@gentoo.org>:
> apparent decline of QA in our packages.

Why do you want this to be a council topic if it wasn't even a topic
here or on gentoo-qa@ ?
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Thu, 2007-04-05 at 19:06 +0100, Steve Long wrote:
> He has already stipulated that "all decisions we made were 100% public"
> and "We do have to have all of our decisions made public, obviously."

Exactly.

Everything that was decided was done so in public and quite plainly.  If
certain people have a problem with that, I'm honestly so fed up with
this conspiracy bullshit that I've decided to just let those people
think whatever it is that they feel like.  I don't have the time nor the
energy to combat such ignorance and outright lies.  What I do with my
Council hat on, I do with the best intentions of Gentoo at heart.  If
the developer community feels I'm not doing that job to the best of my
ability, they can vote my ass out next election.  Gentoo is *not* a
government.  It doesn't have checks and balances, and it really doesn't
need them.  The Council is elected for exactly this sort of thing.  We
are elected to represent the interests of Gentoo as a whole.  Pissing
off a very minority of the developer pool because we decided to actually
make a decision is something I am fully ready to live with and accept
the consequences for doing.  I'm sticking with my principles and simply
ignoring the continued noise on this subject.

If anyone feels like talking to me about it, they can contact me
privately so we can have a secret conspiracy discussion that nobody else
knows about.  Oh noes!  Cabal!  *roll eyes*

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Danny van Dyk]

Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty:
> Torsten Veller wrote:
> > * Mike Doty <kingtaco@gentoo.org>:
> >> apparent decline of QA in our packages.
> >
> > Why do you want this to be a council topic if it wasn't even a
> > topic here or on gentoo-qa@ ?
>
> Because our QA sucks and noone is doing a damn thing about it.
I disagree. The QA team is doing a lot of work.

* Mr_Bones still runs QA checks on the whole tree daily and people are
  still scared if he pops up and pastes his repoman/pquery output.

* Tove still looks out for anything obviously wrong, and he's quite good
  at constantly buggering people about it.

* Other people including myself run different (selected) kinds of QA
  checks on a case by case basis and usually fix the affected parts of
  the tree, and sometimes nobody but the maintainers notice that.

* You don't need to be a member of the "QA project/team" to do QA. I say
  this here, but i think that should be self-evident.

* Antarus and spb are preparing to take actions against at least one
  persistent QA offender, and devrel told them how to do it properly.

* QA team, one of its subprojects to be precise, has recently published
  the draft for Package Manager Specifications.

* The work of our QA team is mostly under the hood (and i don't mean
  sekrit by that!), and that's how it should be done imho. Naturally
  this can mean that people think they aren't working at all if they
  don't see flamewars and/or big announcements/blog entries on how they
  fixed QA problem X. I prefer a silent QA team personally.

* There is at least one outstanding QA issue that i know of which is
  related to Portage and can't be fixed w/o slot deps properly.
  Read: KDE's problems with ranged deps and the way it currently
  breaks the vdb's RDEPEND entries, especially regarding qt and kdelibs.

* There is a _lot_ of minor QA stuff on bugs.g.o, and everybody (not
  only QA team members) are invited to work on it. The only prerequisite
  for helping with it is: "Know what you do. If you don't, learn it."

* QA _starts_ by such minor things as whitespace problems or proper
  ChangeLog entries, so there is enough work for everybody out there to
  help with!

If anybody is interested, i can provide you (this is all gentoo ebuild 
devs*) either with lists of QA problems in the tree to fix, or with 
tools that enable you to search for one particular (kind of) QA 
violation in the whole tree, whatever your prefer.

Danny

*I'm only adressing gentoo devs here as patches against the whole tree 
don't make sense. The tree changes to fast for it.
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

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

On Thu, Apr 05, 2007 at 10:40:55PM +0200, Danny van Dyk wrote:
> Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty:
> > Torsten Veller wrote:
> > > * Mike Doty <kingtaco@gentoo.org>:
> > >> apparent decline of QA in our packages.
> > >
> > > Why do you want this to be a council topic if it wasn't even a
> > > topic here or on gentoo-qa@ ?
> >
> > Because our QA sucks and noone is doing a damn thing about it.
> I disagree. The QA team is doing a lot of work.
> 
> * Mr_Bones still runs QA checks on the whole tree daily and people are
>   still scared if he pops up and pastes his repoman/pquery output.

Last I knew, bones wasn't part of the QA team anymore.  Historically 
he's operated as the scary guy who didn't need a team to spank your 
ass anyways.  (that's a joke about him, not the QA team also).

pcheck btw, not pquery (former does quality checks, latter is for 
metadata lookup).  And you claim you can recommend to people which 
tools to use :-)


> * You don't need to be a member of the "QA project/team" to do QA. I say
>   this here, but i think that should be self-evident.

Agreed, although worth keeping in mind the question specifically was 
what the QA _team_ was up to; thus would try to address that instead 
of pointing out non-qa team folk do things.  Simple example- I still 
do a bit of QA, doesn't mean it's even remotely quantifiable as QA 
team work (which is what he was asking) :)

Don't particularly want to get sucked into yet another "QA team are 
lazy slackers" discussion, just pointing out bits above.  Advice wise, 
take it or leave.


Meanwhile onto the real meat of the email...

> * There is at least one outstanding QA issue that i know of which is
>   related to Portage and can't be fixed w/o slot deps properly.
>   Read: KDE's problems with ranged deps and the way it currently
>   breaks the vdb's RDEPEND entries, especially regarding qt and kdelibs.

Elaborating a bit, this actually is only a problem for pkgcore and 
paludis; portage isn't affected since it prefers to try pulling the
metadata from $PORTDIR; reasoning is that way screw ups in the 
metadata that are now locked in the vdb can be worked around via it.  
You can trigger the same issue in portage via wiping pretty much 
everything in PORTDIR (switching the tree, or just a literal rm of 
everything but profiles crap), but that's fairly corner case.

Don't much like the behavior myself, but updates/* would need 
expansion to address the (massively long term) reasoning for portages 
behavior.  Upshot, running from vdb only instead of the dual lookup 
would speed up portages resolution via less IO/parsing...

Either way, the kde/qt issue was known from the get go- since slot 
deps weren't available when they started down this path, they should 
have used new style virtuals instead.  Yes it's ugly, backwards 
compatibility usually isn't utterly pretty- upshot of it however is 
that the upgrade node is just a new style virtual, no real cost for 
the operation.

Breaking EAPI=0 via pushing slot deps in isn't much of an option in 
my opinion; usual "needs to have been on release media for at least 6 
months" would apply here at the very least.  The problem is that 2.1.2 
is the first portage version to have slot deps- that is a fairly 
recent stabling, so there still would be a good chunk of time to wait 
*if* the daft old method of just shoving stuff in and watching things 
break was took.

Meanwhile, worth remembering during the interim while slot deps aren't 
usable, new style virtual does address it (even if it's a gross trick) 
:)

~harring

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

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

[Brian Harring]

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

On Fri, Apr 06, 2007 at 12:16:18AM +0200, Danny van Dyk wrote:
> > > * There is at least one outstanding QA issue that i know of which
> > > is related to Portage and can't be fixed w/o slot deps properly.
> > > Read: KDE's problems with ranged deps and the way it currently
> > > breaks the vdb's RDEPEND entries, especially regarding qt and
> > > kdelibs.
> >
> > Elaborating a bit, this actually is only a problem for pkgcore and
> > paludis; portage isn't affected since it prefers to try pulling the
> > metadata from $PORTDIR; reasoning is that way screw ups in the
> > metadata that are now locked in the vdb can be worked around via it.
> AFAIK zmedico spoke about moving portage to use vdb metadata instead. 
> Before this could happen we needed a fix for it.

Suspect zac could confirm that's it's about weekly now for me nagging 
him about gutting that ;)


> > You can trigger the same issue in portage via wiping pretty much
> > everything in PORTDIR (switching the tree, or just a literal rm of
> > everything but profiles crap), but that's fairly corner case.
> >
> > Don't much like the behavior myself, but updates/* would need
> > expansion to address the (massively long term) reasoning for portages
> > behavior.  Upshot, running from vdb only instead of the dual lookup
> > would speed up portages resolution via less IO/parsing...
> >
> > Either way, the kde/qt issue was known from the get go- since slot
> > deps weren't available when they started down this path, they should
> > have used new style virtuals instead.  Yes it's ugly, backwards
> > compatibility usually isn't utterly pretty- upshot of it however is
> > that the upgrade node is just a new style virtual, no real cost for
> > the operation.
> >
> > Breaking EAPI=0 via pushing slot deps in isn't much of an option in
> > my opinion; usual "needs to have been on release media for at least 6
> We can push for an EAPI=1 == (EAPI=0 + slot deps)...

Can, yep, although that was originally blocked by "EAPI=0 must be 
defined", which folks seem to have backed off on.

One issue with adding EAPI=1 having just slot deps is that it skips 
out on some long term changes intended- default src_install for 
example, hell, making the default phase functions into an eclass 
equivalent template.  Clarifying, instead of
src_compile() {
	default src compile crap
}

would do
base_src_compile() {
	default src compile crap
}

That way if you just need to tweak one thing, you can still use the 
default src_compile- basically same trick EXPORT_FUNCTIONS does.

Either way, EAPI=1 *should* have a bit more then just slot deps in my 
opinion; very least it needs discussion to discern what folks want.


> > months" would apply here at the very least.  The problem is that
> > 2.1.2 is the first portage version to have slot deps- that is a
> > fairly recent stabling, so there still would be a good chunk of time
> > to wait *if* the daft old method of just shoving stuff in and
> > watching things break was took.
>
> What breakage specifically? Portage versions that don't support EAPI?

Breakage there I'm referring to trying to is a set of folks 
trying to shove it into EAPI=0.


> > Meanwhile, worth remembering during the interim while slot deps
> > aren't usable, new style virtual does address it (even if it's a
> > gross trick)
>
> I prefer we solve this problem instead of hacking around it once more.

Even with EAPI=1 route, still going to require some time to actually 
address it- have to define EAPI=1, make sure portage supports it 
fully, make sure it's stable for all arches, etc.  That's a several 
month proceess, best case, 30 days if somehow everyone agrees to 
eapi=1 today, zac implements it tonight, and releases it tomorrow 
morning (with no bugs).

So... again- it's not pretty, but it's not an issue that's going to be 
solved tomorrow, so it's not a bad idea to take a look at ways to work 
around it.  Very least, if the new style virtual route was taken, 
switching over to slot deps (when available) would be easy- update the 
virtual, then start pruning the tree for anything depending on the 
virtual.

~harring

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

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

[Danny van Dyk]

Am Donnerstag, 5. April 2007 23:24 schrieb Brian Harring:
> On Thu, Apr 05, 2007 at 10:40:55PM +0200, Danny van Dyk wrote:
> > Am Donnerstag, 5. April 2007 20:20 schrieb Mike Doty:
> > > Torsten Veller wrote:
> > > > * Mike Doty <kingtaco@gentoo.org>:
> > > >> apparent decline of QA in our packages.
> > > >
> > > > Why do you want this to be a council topic if it wasn't even a
> > > > topic here or on gentoo-qa@ ?
> > >
> > > Because our QA sucks and noone is doing a damn thing about it.
> >
> > I disagree. The QA team is doing a lot of work.
> >
> > * Mr_Bones still runs QA checks on the whole tree daily and people
> > are still scared if he pops up and pastes his repoman/pquery
> > output.
>
> Last I knew, bones wasn't part of the QA team anymore.  Historically
See my comments regard QA team membership and doing QA work. Having a QA 
team doesn't magically improve the quality of the tree.

> he's operated as the scary guy who didn't need a team to spank your
> ass anyways.  (that's a joke about him, not the QA team also).
>
> pcheck btw, not pquery (former does quality checks, latter is for
> metadata lookup).  And you claim you can recommend to people which
> tools to use :-)
I never claimed i'd recommend your set of tools. This doesn't mean they 
are inferior, it's just that i can't recommend what i don't use and 
know.

> > * You don't need to be a member of the "QA project/team" to do QA.
> > I say this here, but i think that should be self-evident.
>
> Agreed, although worth keeping in mind the question specifically was
> what the QA _team_ was up to; thus would try to address that instead
> of pointing out non-qa team folk do things.  Simple example- I still
> do a bit of QA, doesn't mean it's even remotely quantifiable as QA
> team work (which is what he was asking) :)
>
> Don't particularly want to get sucked into yet another "QA team are
> lazy slackers" discussion, just pointing out bits above.  Advice
> wise, take it or leave.
Heh...

> Meanwhile onto the real meat of the email...
>
> > * There is at least one outstanding QA issue that i know of which
> > is related to Portage and can't be fixed w/o slot deps properly.
> > Read: KDE's problems with ranged deps and the way it currently
> > breaks the vdb's RDEPEND entries, especially regarding qt and
> > kdelibs.
>
> Elaborating a bit, this actually is only a problem for pkgcore and
> paludis; portage isn't affected since it prefers to try pulling the
> metadata from $PORTDIR; reasoning is that way screw ups in the
> metadata that are now locked in the vdb can be worked around via it.
AFAIK zmedico spoke about moving portage to use vdb metadata instead. 
Before this could happen we needed a fix for it.

> You can trigger the same issue in portage via wiping pretty much
> everything in PORTDIR (switching the tree, or just a literal rm of
> everything but profiles crap), but that's fairly corner case.
>
> Don't much like the behavior myself, but updates/* would need
> expansion to address the (massively long term) reasoning for portages
> behavior.  Upshot, running from vdb only instead of the dual lookup
> would speed up portages resolution via less IO/parsing...
>
> Either way, the kde/qt issue was known from the get go- since slot
> deps weren't available when they started down this path, they should
> have used new style virtuals instead.  Yes it's ugly, backwards
> compatibility usually isn't utterly pretty- upshot of it however is
> that the upgrade node is just a new style virtual, no real cost for
> the operation.
>
> Breaking EAPI=0 via pushing slot deps in isn't much of an option in
> my opinion; usual "needs to have been on release media for at least 6
We can push for an EAPI=1 == (EAPI=0 + slot deps)...

> months" would apply here at the very least.  The problem is that
> 2.1.2 is the first portage version to have slot deps- that is a
> fairly recent stabling, so there still would be a good chunk of time
> to wait *if* the daft old method of just shoving stuff in and
> watching things break was took.
What breakage specifically? Portage versions that don't support EAPI?
>
> Meanwhile, worth remembering during the interim while slot deps
> aren't usable, new style virtual does address it (even if it's a
> gross trick)
I prefer we solve this problem instead of hacking around it once more.

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

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

[Vlastimil Babka]

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

Brian Harring wrote:
>>> Breaking EAPI=0 via pushing slot deps in isn't much of an option in
>>> my opinion; usual "needs to have been on release media for at least 6
>> We can push for an EAPI=1 == (EAPI=0 + slot deps)...
>
> Can, yep, although that was originally blocked by "EAPI=0 must be 
> defined", which folks seem to have backed off on.

Not sure if slot deps themselves could even replace version ranges hacks
without also solving bug 4315 (native version ranges) in all cases. IMHO
it should be possible at least to specify slot+usual version limit, to
make it worth EAPI bump.

> One issue with adding EAPI=1 having just slot deps is that it skips 
> out on some long term changes intended- default src_install for 

So what, longer term changes could wait for EAPI=2. Why not make
experience with EAPI bumping with something smaller for a start, instead
of trying to make one big bump that will bring all changes we can think
of now, but will be implemented only in 2010...

Now it may look like I contradict myself saying to bump ASAP but not
without solving bug 4315 first. But I see slot deps without limits only
half of a feature.
- --
Vlastimil Babka (Caster)
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGFXsstbrAj05h3oQRAid6AJ4lJldHuRwA0rHdr+CwGlth6zgG5wCgixJO
7PWG4j0nMOqdyR57bMW+r3E=
=Cnya
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Vlastimil Babka]

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

Danny van Dyk wrote:
>> Not sure if slot deps themselves could even replace version ranges
>> hacks without also solving bug 4315 (native version ranges) in all
>> cases. IMHO it should be possible at least to specify slot+usual
>> version limit, to make it worth EAPI bump.
> 
> Please have a look at the slot dep format proposal. AFAIK none of the 
> P{aludis,kgcore,ortage} devs disagreed on that.

Sorry, I thought it was only about what's already implemented in portage
and that's AFAIK only =cat/package:slot . Fine then.
- --
Vlastimil Babka (Caster)
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGFX9QtbrAj05h3oQRAsPnAJ45IEwpsKQywZstG/hNgeRZVhoc6wCfcn3n
YG1bvuQg9z0BzLiTqFEtQKE=
=gEao
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

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

On Fri, Apr 06, 2007 at 12:41:50AM +0200, Vlastimil Babka wrote:
> Brian Harring wrote:
> >>> Breaking EAPI=0 via pushing slot deps in isn't much of an option in
> >>> my opinion; usual "needs to have been on release media for at least 6
> >> We can push for an EAPI=1 == (EAPI=0 + slot deps)...
> >
> > Can, yep, although that was originally blocked by "EAPI=0 must be 
> > defined", which folks seem to have backed off on.
> 
> Not sure if slot deps themselves could even replace version ranges hacks
> without also solving bug 4315 (native version ranges) in all cases. IMHO
> it should be possible at least to specify slot+usual version limit, to
> make it worth EAPI bump.
> 
> > One issue with adding EAPI=1 having just slot deps is that it skips 
> > out on some long term changes intended- default src_install for 
> 
> So what, longer term changes could wait for EAPI=2. Why not make
> experience with EAPI bumping with something smaller for a start, instead
> of trying to make one big bump that will bring all changes we can think
> of now, but will be implemented only in 2010...

A 101 small little bumps results in a general pain in the ass for 
ebuild devs; if a change is ready to go for EAPI=1 (whether 
implemented now, or bloody simple), and folks *agree to it*, then it 
should go in.

I'm not advocating waiting for every little thing to be shoved in.  
That said, there are lots of minor tweaks that have been desired, but 
haven't been implementable since they would break backwards 
compatibility and no versioning scheme existed.

I've got a list floating around somewhere of the specifics, but top of 
the head-

1) killing DEPEND/RDEPEND autosetting once and for all
2) shift the default phase funcs into a fake eclass; basically the 
base_src_compile example in the previous email.
3) default src_install (currently is empty)
4) *potentially* chunking up src_compile into src_configure and 
src_compile.
5) slightly addressed via #2, a 'prepare phase' for patching and other 
crap.  Not a huge fan, but it's also not something I'm pushing.
6) drop useq/hasq
7) whatever api additions required to remove the need for raw vdb 
access by ebuilds (contents, IUSE, and USE seem to be the primary ones 
atm till use deps are available).
8) potential, although it requires work- glep33.  I'd probably be 
willing to do the portage modifications for that one; upshot of it is 
that it allows breaking eclass api as needed, further reorganizes 
their on disk layout so signing/manifests can sanely be integrated.

So... #8 is slightly large admittedly.  Rest are pretty damn minor, 
bit of discussion required, but minimal real work to code it- stuff 
like that, no reason *not* to slide it into eapi=1.


> Now it may look like I contradict myself saying to bump ASAP but not
> without solving bug 4315 first. But I see slot deps without limits only
> half of a feature.

So far, the syntax I've seen for 4315 has made me want to club baby 
seals, hit the hash pipe, and make a run for the presidency...

Offhand, majority of the tree issues can be addressed via slot deps- 
the remaining chunks that can't, can be addressed via a slightly 
smarter resolver combined with folks using blockers- simple example, 
need >=1.3 < 2.0 for a non-slotted package, use ">=1.3 !>2.0".  Can 
invert it to "<2.0 !<1.3" if you prefer, although the latter is 
slightly preferable on the offchance the package some day becomes 
slotted.

Granted, it's not perfect- point is it's actually doable now without 
format changes.

Other question there is how many ebuilds in the tree actually *need* 
this, beyond just slot deps.

Either way, folks ought to chime in...
~harring

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

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

[Danny van Dyk]

Am Freitag, 6. April 2007 00:41 schrieb Vlastimil Babka:
> Brian Harring wrote:
> >>> Breaking EAPI=0 via pushing slot deps in isn't much of an option
> >>> in my opinion; usual "needs to have been on release media for at
> >>> least 6
> >>
> >> We can push for an EAPI=1 == (EAPI=0 + slot deps)...
> >
> > Can, yep, although that was originally blocked by "EAPI=0 must be
> > defined", which folks seem to have backed off on.
>
> Not sure if slot deps themselves could even replace version ranges
> hacks without also solving bug 4315 (native version ranges) in all
> cases. IMHO it should be possible at least to specify slot+usual
> version limit, to make it worth EAPI bump.

Please have a look at the slot dep format proposal. AFAIK none of the 
P{aludis,kgcore,ortage} devs disagreed on that.
>
> > One issue with adding EAPI=1 having just slot deps is that it skips
> > out on some long term changes intended- default src_install for
>
> So what, longer term changes could wait for EAPI=2. Why not make
> experience with EAPI bumping with something smaller for a start,
> instead of trying to make one big bump that will bring all changes we
> can think of now, but will be implemented only in 2010...
I agree fully. Nobody said we can't finetune the EAPI steps/bumps.

> Now it may look like I contradict myself saying to bump ASAP but not
> without solving bug 4315 first. But I see slot deps without limits
> only half of a feature.
Nobody but talked about that.

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

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

[Danny van Dyk]

Am Freitag, 6. April 2007 00:11 schrieb Brian Harring:
> > > You can trigger the same issue in portage via wiping pretty much
> > > everything in PORTDIR (switching the tree, or just a literal rm
> > > of everything but profiles crap), but that's fairly corner case.
> > >
> > > Don't much like the behavior myself, but updates/* would need
> > > expansion to address the (massively long term) reasoning for
> > > portages behavior.  Upshot, running from vdb only instead of the
> > > dual lookup would speed up portages resolution via less
> > > IO/parsing...
> > >
> > > Either way, the kde/qt issue was known from the get go- since
> > > slot deps weren't available when they started down this path,
> > > they should have used new style virtuals instead.  Yes it's ugly,
> > > backwards compatibility usually isn't utterly pretty- upshot of
> > > it however is that the upgrade node is just a new style virtual,
> > > no real cost for the operation.
> > >
> > > Breaking EAPI=0 via pushing slot deps in isn't much of an option
> > > in my opinion; usual "needs to have been on release media for at
> > > least 6
> >
> > We can push for an EAPI=1 == (EAPI=0 + slot deps)...
>
> Can, yep, although that was originally blocked by "EAPI=0 must be
> defined", which folks seem to have backed off on.
EAPI=0 will be defined by PMS once accepted by the council

> One issue with adding EAPI=1 having just slot deps is that it skips
> out on some long term changes intended- default src_install for
> example, hell, making the default phase functions into an eclass
> equivalent template.  Clarifying, instead of
> src_compile() {
> 	default src compile crap
> }
>
> would do
> base_src_compile() {
> 	default src compile crap
> }
>
> That way if you just need to tweak one thing, you can still use the
> default src_compile- basically same trick EXPORT_FUNCTIONS does.
What has that to do with slot deps? You can incremently define EAPI=2 
and include it there.

> Either way, EAPI=1 *should* have a bit more then just slot deps in my
> opinion; very least it needs discussion to discern what folks want.
Is there any technical reason why EAPI=1 should be a major step that 
includes all we want to get in/get rid off?

> > > months" would apply here at the very least.  The problem is that
> > > 2.1.2 is the first portage version to have slot deps- that is a
> > > fairly recent stabling, so there still would be a good chunk of
> > > time to wait *if* the daft old method of just shoving stuff in
> > > and watching things break was took.
> >
> > What breakage specifically? Portage versions that don't support
> > EAPI?
>
> Breakage there I'm referring to trying to is a set of folks
> trying to shove it into EAPI=0.
I was not talking about that at all. And yes, i know how you are 
refering to. And yes, it's up to the council to decide that.
And yes, there is a bug[1] covering it.

> > > Meanwhile, worth remembering during the interim while slot deps
> > > aren't usable, new style virtual does address it (even if it's a
> > > gross trick)
> >
> > I prefer we solve this problem instead of hacking around it once
> > more.
>
> Even with EAPI=1 route, still going to require some time to actually
> address it- have to define EAPI=1, make sure portage supports it
> fully, make sure it's stable for all arches, etc.  That's a several
> month proceess, best case, 30 days if somehow everyone agrees to
> eapi=1 today, zac implements it tonight, and releases it tomorrow
> morning (with no bugs).
Very well. I'd like to target this for KDE people to use it for kde-4.

> So... again- it's not pretty, but it's not an issue that's going to
> be solved tomorrow, so it's not a bad idea to take a look at ways to
> work around it.  Very least, if the new style virtual route was
> taken, switching over to slot deps (when available) would be easy-
> update the virtual, then start pruning the tree for anything
> depending on the virtual.
And what about the vdb RDEPENDs on said virtual? That the whole point, 
sanitize the vdb metadata.

Danny

[1] https://bugs.gentoo.org/show_bug.cgi?id=170161
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

Danny van Dyk wrote:
  > If anybody is interested, i can provide you (this is all gentoo ebuild
> devs*) either with lists of QA problems in the tree to fix, or with 
> tools that enable you to search for one particular (kind of) QA 
> violation in the whole tree, whatever your prefer.
>
It might be an idea if the QA team would post a QA issue of the week. It 
is my opinion that many QA issues come about because the developers just 
don't know it is wrong. The same mistakes get repeated again and again. 
To (anonymized) publish a QA issue of the week might help educate 
developers and help them to prevent doing the thing wrong again. It 
might also set a general QA awareness.

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

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

[Torsten Veller]

* Ned Ludd <solar@gentoo.org>:
> On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote:
> > another one i had mentioned earlier:
> >  - a time frame on moving gentoo-core to public archives ... two years ?
> 
> I object and hope this is never done.

Me too.

What is the motivation for this change?
-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

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

On Thursday 12 April 2007, Torsten Veller wrote:
> * Ned Ludd <solar@gentoo.org>:
> > On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote:
> > > another one i had mentioned earlier:
> > >  - a time frame on moving gentoo-core to public archives ... two years
> > > ?
> >
> > I object and hope this is never done.
>
> Me too.
>
> What is the motivation for this change?

seems logical to me ... opening up more stuff
-mike

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

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

[Jim Ramsay]

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

Torsten Veller wrote:
> * Ned Ludd <solar@gentoo.org>:
> > On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote:
> > > another one i had mentioned earlier:
> > >  - a time frame on moving gentoo-core to public archives ... two
> > > years ?
> > 
> > I object and hope this is never done.
> 
> Me too.
> 
> What is the motivation for this change?

I believe the original motivation was due is the fact that there is
currently no official archive of -core whatsoever, which is probably not
a good thing.

There have been some discussions on -core about this, but I believe the
2 proposed solutions are:

- Create a private archive to which only developers have access.

- Create a public archive, but delay it by ${time_period}.

I personally prefer the first option here, but others think full public
transparency would be nice, and after ${time_period} most of the info
on -core isn't nearly as 'sensitive' as it is when first posted.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

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

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

[Ciaran McCreesh]

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

On Thu, 12 Apr 2007 09:54:23 -0600
Jim Ramsay <lack@gentoo.org> wrote:
> I personally prefer the first option here, but others think full
> public transparency would be nice, and after ${time_period} most of
> the info on -core isn't nearly as 'sensitive' as it is when first
> posted.

If something's supposed to be transparent, it shouldn't be on -core.
And, conversely, if something's on -core, it's not supposed to be
transparent. Opening up -core just makes it harder to handle those rare
cases where things really are required to be restricted.

There's also the issue of whether this can legitimately be made
retroactive. As Ned already pointed out, some developers only posted
things to -core because they believed that it was not public.

Instead, why not look into reducing the amount of traffic on -core?

-- 
Ciaran McCreesh


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

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

[Jim Ramsay]

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

Ciaran McCreesh wrote:
> If something's supposed to be transparent, it shouldn't be on -core.
> And, conversely, if something's on -core, it's not supposed to be
> transparent. Opening up -core just makes it harder to handle those
> rare cases where things really are required to be restricted.

I agree - this is precisely the reason why I personally prefer a private
archive of -core.

> There's also the issue of whether this can legitimately be made
> retroactive. As Ned already pointed out, some developers only posted
> things to -core because they believed that it was not public.

I'm fairly sure the consensus is that this would not be retroactive.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

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

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

[Chris Gianelloni]

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

On Thu, 2007-04-12 at 17:04 +0100, Ciaran McCreesh wrote:
> Instead, why not look into reducing the amount of traffic on -core?

Actually, the amount of traffic on -core these days has been pretty
minimal.  In some weeks, the only messages setn are my GWN proofreading
requests.  Sure, there are still some things that are sent to -core that
don't need to be, but the volume has come way down from the worst prior
levels.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Richard Freeman]

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

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

Chris Gianelloni wrote:
> On Thu, 2007-04-12 at 17:04 +0100, Ciaran McCreesh wrote:
>> Instead, why not look into reducing the amount of traffic on -core?
> 
> Actually, the amount of traffic on -core these days has been pretty
> minimal.  In some weeks, the only messages setn are my GWN proofreading
> requests...

Is there some reason these need to be posted on -core?  If -core is only
for sensitive matters that shouldn't be made public then why post stuff
there that is going to be put on the gentoo front page?

There are a lot of people involved gentoo who aren't devs that still
have a vested interest in what is going on and who help out in various
ways.  Obviously not everybody needs to know everything, but ideally if
something isn't otherwise fairly sensitive it probably should be out in
the open.  Actually, I'm not really sure what kinds of things are
insensitive enough to be broadcasted to hundreds of devs, but too
sensitive to broadcast to thousands of users.  Maybe in cases where a
security bug is going to have some wide-spread effect on the entire
distro that needs to be coordinated or something like that.  If it some
kind of personal issue it probably shouldn't even go on -core...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGIh0xG4/rWKZmVWkRAqYKAKCEo3IiBsZni3gdUE7faBBofzCKcwCgqTtG
lG0FRyRXJG8pwkLYTBM5tmA=
=hggA
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

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

[Duncan]

Richard Freeman <rich@thefreemanclan.net> posted
46221D31.4080101@thefreemanclan.net, excerpted below, on  Sun, 15 Apr 2007
08:40:17 -0400:

> Chris Gianelloni wrote:
>> On Thu, 2007-04-12 at 17:04 +0100, Ciaran McCreesh wrote:
>>> Instead, why not look into reducing the amount of traffic on -core?
>> 
>> Actually, the amount of traffic on -core these days has been pretty
>> minimal.  In some weeks, the only messages setn are my GWN proofreading
>> requests...
> 
> Is there some reason these need to be posted on -core?  If -core is only
> for sensitive matters that shouldn't be made public then why post stuff
> there that is going to be put on the gentoo front page?

Yes.  There have been times when devs have objected to GWN's coverage of 
their blogs, etc, saying they were taken out of context and GWN's 
interpretation got it all wrong.  Posting to an embargoed location 
accessible only to devs first, for a preview and objection if necessary, 
was the compromise.  (I'm not sure if it was in place before that or not, 
but while not a dev myself, I can definitely see the need, as I've seen 
the blame-games played and accusations fly and if it can be avoided, it 
certainly should be.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Monthly Gentoo Council Reminder for April

[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 April

[Petteri Räty]

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

Mike Frysinger kirjoitti:
> 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/

Defining required amount of activity for ebuild devs. I would like us to 
raise the required amount of activity for ebuild devs. Just committing 
monthly is not enough imho to require a developer status. How does 
having the average time between commits be at most a week sound and if 
it goes under that, undertakers will get a notification? Devaway would 
be there of course as usual.

Regards,
Petteri


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

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

[Wulf C. Krueger]

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

On Wednesday, 02. April 2008 22:46:16 Petteri Räty wrote:
> How does having the average time between commits be at most a week
> sound and if it goes under that, undertakers will get a notification?

It sounds like you're trying to get rid of someone.

-- 
Best regards, Wulf

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

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

[joshua jackson]

Wulf C. Krueger wrote:
>  On Wednesday, 02. April 2008 22:46:16 Petteri Räty wrote:
> > How does having the average time between commits be at most a week
> > sound and if it goes under that, undertakers will get a notification?
>
>  It sounds like you're trying to get rid of someone.
>
>
>  -------------------------
>
>  !DSPAM:47f3f2be39031804284693!
Yep its me!

Seriously...we don't need to be paranoid people.

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

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

[Mike Auty]

Petteri Räty wrote:
> Defining required amount of activity for ebuild devs. I would like us to 
> raise the required amount of activity for ebuild devs.

Given that the low number of developers is ranked as our number one 
problem in Donnie's informal survey[1], taking any kind of action 
against infrequently-committing developers is likely to reduce the 
number of devs we have, and potentially make the problem worse.

What benefits are you aiming to get from the suggestion?  I can think og 
keeping the books tidy and reducing management time required to maintain 
the devs.  Are there others I've missed?  If they're worth the 
cost/effort involved with putting someone through the dev tests and 
getting them trained, then it seems a good idea, but otherwise probably 
not...

Mike  5:)

[1] http://dberkholz.wordpress.com/2008/02/21/redux-gentoos-top-3-issues/
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Petteri Räty]

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

Mike Auty kirjoitti:
> Petteri Räty wrote:
>> Defining required amount of activity for ebuild devs. I would like us 
>> to raise the required amount of activity for ebuild devs.
> 
> Given that the low number of developers is ranked as our number one 
> problem in Donnie's informal survey[1], taking any kind of action 
> against infrequently-committing developers is likely to reduce the 
> number of devs we have, and potentially make the problem worse.
> 
> What benefits are you aiming to get from the suggestion?  I can think og 
> keeping the books tidy and reducing management time required to maintain 
> the devs.  Are there others I've missed?  If they're worth the 
> cost/effort involved with putting someone through the dev tests and 
> getting them trained, then it seems a good idea, but otherwise probably 
> not...
> 
> Mike  5:)
> 
> [1] http://dberkholz.wordpress.com/2008/02/21/redux-gentoos-top-3-issues/

If you can't manage weekly commits, you can't respond to security issues 
either. This means that you should have devaway on.

Regards,
Petteri


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

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

[Petteri Räty]

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

Wulf C. Krueger kirjoitti:
> On Wednesday, 02. April 2008 22:46:16 Petteri Räty wrote:
>> How does having the average time between commits be at most a week
>> sound and if it goes under that, undertakers will get a notification?
> 
> It sounds like you're trying to get rid of someone.
> 

I don't have numbers yet, but I presume this is going to mark quite a 
few developers.

Regards,
Petteri


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

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

[Richard Brown]

On Wed, Apr 2, 2008 at 10:26 PM, Petteri Räty <betelgeuse@gentoo.org> wrote:
>  If you can't manage weekly commits, you can't respond to security issues
> either. This means that you should have devaway on.

So if you don't maintain enough packages to commit on average once a
week, you're not worth having?

Also, you said average, did you mean mode, median or mean? Over what
time period?


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

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

[Jan Kundrát]

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

Petteri Räty wrote:
> If you can't manage weekly commits, you can't respond to security issues 
> either. This means that you should have devaway on.

That assumption is false. If there was a need to do weekly commits and 
the dev in question couldn't manage it, it would be wise to expect that 
he can't be relied upon with security fixes. However, there is no need 
to do periodic commits now, so the above theorem doesn't hold. :)

Cheers,
-jkt

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


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

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

[Mike Auty]

Petteri Räty wrote:
> If you can't manage weekly commits, you can't respond to security issues 
> either.

I can see your point, I was more thinking about developers who have 
maybe one or two small packages that don't have many version bumps or 
bugs.  They may be entirely able to respond to security issues, but may 
not have reason to make the weekly commit quota.  I don't know the 
habits of developers well enough to know if this is a reasonable scenario?

I was under the impression that if a dev couldn't respond quickly enough 
to a security issue, the security team could take steps (mask the 
package, try to fix it) to ensure the package doesn't pose a problem (as 
is presumably the case now with devs who forget to mark themselves as 
away).  Depending on the actions you envisaged (sending a warning email, 
marking as away or retiring) this could create a lot of extra work for 
little benefit.  If it was simply a warning email it might not be very 
pointful, but marking them as away then it sounds like it could be 
useful and automated...  5:)

Mike  5:)
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Petteri Räty]

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

Mike Auty kirjoitti:
> Petteri Räty wrote:
>> If you can't manage weekly commits, you can't respond to security 
>> issues either.
> 
> I can see your point, I was more thinking about developers who have 
> maybe one or two small packages that don't have many version bumps or 
> bugs.  They may be entirely able to respond to security issues, but may 
> not have reason to make the weekly commit quota.  I don't know the 
> habits of developers well enough to know if this is a reasonable scenario?
> 
> I was under the impression that if a dev couldn't respond quickly enough 
> to a security issue, the security team could take steps (mask the 
> package, try to fix it) to ensure the package doesn't pose a problem (as 
> is presumably the case now with devs who forget to mark themselves as 
> away).  Depending on the actions you envisaged (sending a warning email, 
> marking as away or retiring) this could create a lot of extra work for 
> little benefit.  If it was simply a warning email it might not be very 
> pointful, but marking them as away then it sounds like it could be 
> useful and automated...  5:)
> 
> Mike  5:)

Undertakers would still be processing the retirements. What I am talking 
about is changing how the list of potentially inactive people is created.

Regards,
Petteri


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

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

[William L. Thomson Jr.]

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


On Wed, 2008-04-02 at 22:19 +0100, Mike Auty wrote:
> Petteri Räty wrote:
> > Defining required amount of activity for ebuild devs. I would like us to 
> > raise the required amount of activity for ebuild devs.
> 
> Given that the low number of developers is ranked as our number one 
> problem in Donnie's informal survey[1], taking any kind of action 
> against infrequently-committing developers is likely to reduce the 
> number of devs we have, and potentially make the problem worse.

It's about quality not quantity maybe?

> What benefits are you aiming to get from the suggestion?  I can think og 
> keeping the books tidy and reducing management time required to maintain 
> the devs.  Are there others I've missed?  If they're worth the 
> cost/effort involved with putting someone through the dev tests and 
> getting them trained, then it seems a good idea, but otherwise probably 
> not...

Well I think in part is keeping up with changes within Gentoo. Since I
joined we have change the syntax and semantics of Gentoo Java ebuilds
allot. Lots of things wrt to ebuilds constantly change. So could be more
of your game. If your not keeping u[, you run the greater chance of
falling behind, etc.

The other side of that, and maybe it's part of the above suggestion, is
re-taking the quizzes. I have long thought, just like driving tests.
That maybe every so often existing devs should re-take the quizzes. The
quizzes do change at times. Much less if your skills are sharp, should
only take a few minutes if that.

( Mostly thinking of myself when I think about re-taking quizzes ;) )

I take it as an all around approach to increased QA. Possible motivator
for developer activity with some very reasonable minimum requirements.
Surely could have side effects, but not a horrible idea

-- 
William L. Thomson Jr.
amd64/Java/Trustees
Gentoo Foundation


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

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

[Richard Freeman]

Jan Kundrát wrote:
> Petteri Räty wrote:
>> If you can't manage weekly commits, you can't respond to security 
>> issues either. This means that you should have devaway on.
> 
> That assumption is false. If there was a need to do weekly commits and 
> the dev in question couldn't manage it, it would be wise to expect that 
> he can't be relied upon with security fixes. However, there is no need 
> to do periodic commits now, so the above theorem doesn't hold. :)
> 

Would it make more sense to just make a policy that failure to maintain 
packages that you're maintainer on will result in getting removed as the 
maintainer, with said packages going up for grabs?  Devs who keep 
claiming packages only to allow them to bitrot can be booted.

However, unless a dev is actually a liability, does it make sense to get 
rid of them?  Even a small positive contribution is still a positive 
contribution.  If the concern is devs who become liabilities then why 
not make the policy to look for the liabilities themselves?
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Jorge Manuel B. S. Vicetto]

Petteri Räty wrote:
> Mike Auty kirjoitti:
>> Petteri Räty wrote:
>>> Defining required amount of activity for ebuild devs. I would like us 
>>> to raise the required amount of activity for ebuild devs.
>>
>> Given that the low number of developers is ranked as our number one 
>> problem in Donnie's informal survey[1], taking any kind of action 
>> against infrequently-committing developers is likely to reduce the 
>> number of devs we have, and potentially make the problem worse.
>>

I agree with the above point.
Also, as I recall, both Pettery (betelgeuse) and Denis (calchan) have 
stated before that we no longer have any queue of people waiting on 
recruiters to join Gentoo. I'm not seeing an avalanche of new blood 
entering the distro, so I'm wondering where we want to go.
If we keep going the route of the last months, I wonder how long it will 
take until we get under 150 devs. I don't think this will benefit 
anyone. Furthermore, the trend in the last months was in large part the 
result of finally retiring people that had been slacking for a long 
time. This proposal could (would?) lead to sending away people that 
still do work, albeit at a slower pace or on bursts.

>> What benefits are you aiming to get from the suggestion?  I can think 
>> og keeping the books tidy and reducing management time required to 
>> maintain the devs.  Are there others I've missed?  If they're worth 
>> the cost/effort involved with putting someone through the dev tests 
>> and getting them trained, then it seems a good idea, but otherwise 
>> probably not...
>>
>> Mike  5:)
>>
>> [1] http://dberkholz.wordpress.com/2008/02/21/redux-gentoos-top-3-issues/
> 
> If you can't manage weekly commits, you can't respond to security issues 
> either. This means that you should have devaway on.
> 

As others have commented, I don't agree with this point. Also, you're 
forgetting we have quite a few people working on this project and that 
we have many different roles.
Although you're talking about ebuild devs only - so doc devs, infra and 
forums staff are exempt from this rule - you're assuming (asking?) that 
all people with access to gentoo-x86 are package maintainers and do a 
few, regular commits to the tree. As others have said, that assumes 
people keep more than a few ebuilds and that those packages require 
constant attention.
Recalling previous discussions about work on gentoo and some of the 
existing roles, what will you do to AT folks, release members or QA 
members? Are they also obliged to do a weekly commit to keep their 
"privileges"?
Finally, I thought the whole point of removing access to infra boxes 
(which is the end result of retiring a dev), was a concern with security 
and not a way to get rid of people - with the exception of 
administrative action by devrel.

We've been having a few discussions about the future of Gentoo for some 
time and people have shown different goals and views on its future and 
on how to get there. One of the views seems to be that we need (only 
need?) an "elite" of super-devs that do daily (hourly?) commits. I have 
nothing against people that can give so much to this project, but I 
don't think it's reasonable, desirable or healthy to expect everyone to 
be able to that level of commitment. Also, wasn't this distro at one 
point all about community? I don't think raising the commitement level 
helps to involve people and as William (wltjr) pointed out shouldn't we 
be more concerned with quality than with quantity?
I understand and agree that ebuild devs should keep a minimum level of 
work to justify their access to the gentoo-x86 tree. I would also like 
to have a few devs that can do major commits (although commit sprees can 
have their own problems), but I think there's still a place in this 
distro for people that want to maintain a few packages, that want to do 
AT work, that care with the QA of the tree or that work on releases. 
These people shouldn't be sent away, just because they can't keep with 
weekly commits (not enough work or time?) or because they work in bursts.

As a final thought, I think this point is a tangent to the old debate 
about tree-wide commit privileges and or the scm of the tree. Afterall, 
if gentoo-x86 was a git tree and or we had acls in the tree, I don't 
think we would be having or would need to have this argument.

> Regards,
> Petteri
> 

-- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / SPARC / KDE
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Christian Faulhammer]

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

Hi,

"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>:
> As others have commented, I don't agree with this point. Also, you're 
> forgetting we have quite a few people working on this project and
> that we have many different roles.

 And just remember Diego's post, where he by accident accused a
developer being a slacker [1], while that person was mostly working on
the overlay.

V-Li

[1]
<URL:http://blog.flameeyes.eu/articles/2008/03/06/amending-my-soc-post>


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

[Fabian Groffen]

On 02-04-2008 21:21:25 -0400, Richard Freeman wrote:
> Would it make more sense to just make a policy that failure to maintain 
> packages that you're maintainer on will result in getting removed as the 
> maintainer, with said packages going up for grabs?  Devs who keep claiming 
> packages only to allow them to bitrot can be booted.

On other projects I sometimes see a remark such as:
"Maintainer time-out, committing the fix as in bug #bla"

Maybe that is a bit less intrusive as dropping the maintainer entirely.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Ciaran McCreesh]

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

On 01 Apr 2008 05:30:01
Mike Frysinger <vapier@gentoo.org> wrote:
> 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.

I'd like initial comments from the Council on PMS please. We're
reaching the point where we'll be ready to push a draft for general
review, and I'd like to know whether there are any major changes that
the Council considers necessary or whether it's just a case of
fine-tuning the details.

http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git

-- 
Ciaran McCreesh

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

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

[Petteri Räty]

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

Jorge Manuel B. S. Vicetto kirjoitti:
> Petteri Räty wrote:
> 
> I agree with the above point.
> Also, as I recall, both Pettery (betelgeuse) and Denis (calchan) have 
> stated before that we no longer have any queue of people waiting on 
> recruiters to join Gentoo. I'm not seeing an avalanche of new blood 
> entering the distro, so I'm wondering where we want to go.
> If we keep going the route of the last months, I wonder how long it will 
> take until we get under 150 devs. I don't think this will benefit 
> anyone. Furthermore, the trend in the last months was in large part the 
> result of finally retiring people that had been slacking for a long 
> time. This proposal could (would?) lead to sending away people that 
> still do work, albeit at a slower pace or on bursts.
> 

We do have somewhat of a backlog at this point because Calchan was away 
for a while and you can always query bugzilla for the current situation.

> 
> As others have commented, I don't agree with this point. Also, you're 
> forgetting we have quite a few people working on this project and that 
> we have many different roles.
 >

And you are assuming that undertakers wouldn't check their role before 
acting.

> Recalling previous discussions about work on gentoo and some of the 
> existing roles, what will you do to AT folks, release members or QA 
> members? Are they also obliged to do a weekly commit to keep their 
> "privileges"?

AT folks aren't devs and see above.

> Finally, I thought the whole point of removing access to infra boxes 
> (which is the end result of retiring a dev), was a concern with security 
> and not a way to get rid of people - with the exception of 
> administrative action by devrel.

Security and gives us a better picture on what is really maintained and 
what is not.

>
> I understand and agree that ebuild devs should keep a minimum level of 
> work to justify their access to the gentoo-x86 tree. I would also like 
> to have a few devs that can do major commits (although commit sprees can 
> have their own problems), but I think there's still a place in this 
> distro for people that want to maintain a few packages, that want to do 
> AT work, that care with the QA of the tree or that work on releases. 
> These people shouldn't be sent away, just because they can't keep with 
> weekly commits (not enough work or time?) or because they work in bursts.
>

To quote myself:
"How does having the average time between commits be at most a week 
sound and if it goes under that, undertakers will get a notification?"

I didn't suggest they have to commit every week. This means 4 commits a 
month instead of the currently monthly or bimonthly commit check in the 
script.

> 
> As a final thought, I think this point is a tangent to the old debate 
> about tree-wide commit privileges and or the scm of the tree. Afterall, 
> if gentoo-x86 was a git tree and or we had acls in the tree, I don't 
> think we would be having or would need to have this argument.
> 

If we used git, proxy maintaining would be easier.

Regards,
Petteri


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

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

[Petteri Räty]

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

Fabian Groffen kirjoitti:
> On 02-04-2008 21:21:25 -0400, Richard Freeman wrote:
>> Would it make more sense to just make a policy that failure to maintain 
>> packages that you're maintainer on will result in getting removed as the 
>> maintainer, with said packages going up for grabs?  Devs who keep claiming 
>> packages only to allow them to bitrot can be booted.
> 
> On other projects I sometimes see a remark such as:
> "Maintainer time-out, committing the fix as in bug #bla"
> 
> Maybe that is a bit less intrusive as dropping the maintainer entirely.
> 

The process of coming back should be quick and easy as the quizzes don't 
really change that much.

Regards,
Petteri



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

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

[Jorge Manuel B. S. Vicetto]

Petteri Räty wrote:
> Jorge Manuel B. S. Vicetto kirjoitti:
>> Petteri Räty wrote:
>>
>>
>> As others have commented, I don't agree with this point. Also, you're 
>> forgetting we have quite a few people working on this project and that 
>> we have many different roles.
>  >
> 
> And you are assuming that undertakers wouldn't check their role before 
> acting.
> 

I read it as a rule to drop developers. If we're only talking about it 
raising a warning to undertakers so they can check the dev status, then 
I don't have a problem with the proposal.

>> Recalling previous discussions about work on gentoo and some of the 
>> existing roles, what will you do to AT folks, release members or QA 
>> members? Are they also obliged to do a weekly commit to keep their 
>> "privileges"?
> 
> AT folks aren't devs and see above.
> 

To be clear, I didn't meant arch testers but people that do keywords for 
arch teams.

>> Finally, I thought the whole point of removing access to infra boxes 
>> (which is the end result of retiring a dev), was a concern with 
>> security and not a way to get rid of people - with the exception of 
>> administrative action by devrel.
> 
> Security and gives us a better picture on what is really maintained and 
> what is not.
> 

But in that case I don't think that the level of commits is the best 
indicator if someone is maintaining properly a package or not. The 
number of open bugs and the mean time that it takes for the developer to 
react to a bug might give us a better picture.

>>
>> As a final thought, I think this point is a tangent to the old debate 
>> about tree-wide commit privileges and or the scm of the tree. 
>> Afterall, if gentoo-x86 was a git tree and or we had acls in the tree, 
>> I don't think we would be having or would need to have this argument.
>>
> 
> If we used git, proxy maintaining would be easier.

True, but with some acls we could also have a different model where 
people worked on parts of the tree and where commit privileges didn't 
pose so many security risks. With the current practice of doing work in 
overlays it would also be simpler to merge the work back into the 
Portage tree.

> 
> Regards,
> Petteri
> 

-- 
Regards,

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 April

[Ciaran McCreesh]

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

On Thu, 03 Apr 2008 11:35:20 +0000
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> True, but with some acls we could also have a different model where 
> people worked on parts of the tree and where commit privileges didn't 
> pose so many security risks. With the current practice of doing work
> in overlays it would also be simpler to merge the work back into the 
> Portage tree.

How does only being able to commit to only part of a tree make commit
access any less of a security risk?

-- 
Ciaran McCreesh

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

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 871 bytes --]

2008-04-03 13:35 Jorge Manuel B. S. Vicetto <jmbsvicetto@gentoo.org> napisał(a):
> Petteri Räty wrote:
> > Jorge Manuel B. S. Vicetto kirjoitti:
> > > As a final thought, I think this point is a tangent to the old debate
> about tree-wide commit privileges and or the scm of the tree. Afterall, if
> gentoo-x86 was a git tree and or we had acls in the tree, I don't think we
> would be having or would need to have this argument.
> > >
> > >
> >
> > If we used git, proxy maintaining would be easier.
> >
>
>  True, but with some acls we could also have a different model where people
> worked on parts of the tree and where commit privileges didn't pose so many
> security risks. With the current practice of doing work in overlays it would
> also be simpler to merge the work back into the Portage tree.

Also Subversion would be sufficient.
éí¢‡^¾X¬¶È\x1ežÚ(¢¸&j)bž	b²

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

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> On Thu, 03 Apr 2008 11:35:20 +0000
> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
>> True, but with some acls we could also have a different model where 
>> people worked on parts of the tree and where commit privileges didn't 
>> pose so many security risks. With the current practice of doing work
>> in overlays it would also be simpler to merge the work back into the 
>> Portage tree.
> 
> How does only being able to commit to only part of a tree make commit
> access any less of a security risk?
> 

Yeah, you only need access to one ebuild to do whatever you want to 
user's systems.

Regards,
Petteri


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

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

[Mike Auty]

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

Petteri Räty wrote:
| Yeah, you only need access to one ebuild to do whatever you want to
| user's systems.

Perhaps then we should direct more of our efforts towards the GPG
package signing system, so that when a dev becomes a libability, their
keys can be revoked?

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkf0xgsACgkQu7rWomwgFXrStgCglCcTvdRaEGMyOdU0qfhcG7w8
TuwAnj1Vmho+LPCqreZNKlNhSRBHUjQU
=LjIi
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 03 Apr 2008 12:56:59 +0100
Mike Auty <ikelos@gentoo.org> wrote:
> Petteri Räty wrote:
> | Yeah, you only need access to one ebuild to do whatever you want to
> | user's systems.
> 
> Perhaps then we should direct more of our efforts towards the GPG
> package signing system, so that when a dev becomes a libability, their
> keys can be revoked?

Signing offers no protection against a malicious developer.

-- 
Ciaran McCreesh

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

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

[Mike Auty]

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

Ciaran McCreesh wrote:
|
| Signing offers no protection against a malicious developer.
|

I had envisaged a system whereby when the tree was synced, as was some
kind of master signed list of all acceptable dev-keys.  Every package
would also be signed, and would only be installed when signed.  As soon
as a dev becomes a liability their key is removed from the list/revoked.
~ On next sync any packages or package upgrades signed after the time of
revocation would not be installed.  There would be a window of
vulnerability, but no bigger than with revoking a dev's access to the
tree.  Do you think this would offer suitable protection for users from
a malicious dev or not?

I understand there are difficulties with eclasses, etc, which is why the
current implementation is still not widely used or mandated, but I'm
more interested in the feasibility of the idea.

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkf0yu8ACgkQu7rWomwgFXrxOwCeKOdkiFhpknf/q/6jq1sPf70t
3xMAoJxlLYhweQspnIJe626TYdmeA3BQ
=hKID
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Mike Auty]

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

William L. Thomson Jr. wrote:
| It's about quality not quantity maybe?

It's about both, and getting the balance right is effectively what this
boils down to (as do many discussions on -dev).  There's those devs who
want high levels of QA and those devs that want the
latest/obscure/testing/rare packages.  Generally the two sides play
oppose each other.

Personally I think having both super-devs (who do lots of commits, care
deeply about QA and know their stuff intimately) and
official-contributor type devs (those who maintain a few specialist
packages when they can) is a good idea.  Giving the undertakers more
work by giving them more reports of potentially lax devs and requiring
them to investigate seems a little wasteful to me.  I'd far rather the
undertakers spent the extra time on positive contributions to the actual
distribution (rather than it's administration).

So the still unanswered question appears to be, would we like Gentoo to
have fewer packages and less choice but greater QA, stability and a feel
of professionalism, or would we like to have more packages and choice
but a worse QA record, make some mistakes, and have a more
community-based feel?  If you're going to try to answer this question
please be delicate with your repsonses, in the past I can recall
developers leaving over exactly this divide...

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkf0y6wACgkQu7rWomwgFXoCRACdHKACZY9yjfetGKJ5JtRP6y6U
YBkAniFzWanDJvUkXUe8XglBBBP9sXsk
=mp9f
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 03 Apr 2008 13:17:51 +0100
Mike Auty <ikelos@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> | Signing offers no protection against a malicious developer.
> 
> I had envisaged a system whereby when the tree was synced, as was some
> kind of master signed list of all acceptable dev-keys.  Every package
> would also be signed, and would only be installed when signed.  As
> soon as a dev becomes a liability their key is removed from the
> list/revoked. ~ On next sync any packages or package upgrades signed
> after the time of revocation would not be installed.  There would be
> a window of vulnerability, but no bigger than with revoking a dev's
> access to the tree.  Do you think this would offer suitable
> protection for users from a malicious dev or not?

Nope. In fact, using such a system, there are ways of getting in code
that doesn't get triggered until someone's key gets invalidated.

And if you are worrying about malicious developers, you need to worry
about malicious infra people too. An infra member throwing his toys out
of the pram can do much more lasting damage than someone who can get
some global scope nastiness into an ebuild for an hour or two...

-- 
Ciaran McCreesh

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

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

[Patrick Lauer]

Ciaran McCreesh wrote:
> On Thu, 03 Apr 2008 13:17:51 +0100
> Mike Auty <ikelos@gentoo.org> wrote:
>   
>> Ciaran McCreesh wrote:
>> | Signing offers no protection against a malicious developer.
>>
>> I had envisaged a system whereby when the tree was synced, as was some
>> kind of master signed list of all acceptable dev-keys.  Every package
>> would also be signed, and would only be installed when signed.  As
>> soon as a dev becomes a liability their key is removed from the
>> list/revoked. ~ On next sync any packages or package upgrades signed
>> after the time of revocation would not be installed.  There would be
>> a window of vulnerability, but no bigger than with revoking a dev's
>> access to the tree.  Do you think this would offer suitable
>> protection for users from a malicious dev or not?
>>     
>
> Nope. In fact, using such a system, there are ways of getting in code
> that doesn't get triggered until someone's key gets invalidated.
>   
By this reasoning you shouldn't use passwords ...

The idea is to limit the attack vectors and make simple attacks much 
harder. A sophisticated "hacker" could just rent a busload of angry 
serbians, kidnap 12 developers and force them to do some subtle changes 
in many places. But is that likely to happen?
> And if you are worrying about malicious developers, you need to worry
> about malicious infra people too. An infra member throwing his toys out
> of the pram can do much more lasting damage than someone who can get
> some global scope nastiness into an ebuild for an hour or two...
>   
That has nothing to do with the discussion ... and I don't see how infra 
could manipulate the signatures in a useful way apart from adding keys 
or removing some from the official keyring ...
This they could do at the moment by manipulating the cvs to rsync copy 
process, but I'm not aware of something like that happening. So you 
might want to have a marginal trust in people and not accuse them of 
things they might do in the future ...


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

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

[Ciaran McCreesh]

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

On Thu, 03 Apr 2008 14:29:10 +0200
Patrick Lauer <bugs@dev.gentooexperimental.org> wrote:
> > Nope. In fact, using such a system, there are ways of getting in
> > code that doesn't get triggered until someone's key gets
> > invalidated. 
> By this reasoning you shouldn't use passwords ...
> 
> The idea is to limit the attack vectors and make simple attacks much 
> harder. A sophisticated "hacker" could just rent a busload of angry 
> serbians, kidnap 12 developers and force them to do some subtle
> changes in many places. But is that likely to happen?

No no. The point is, there's no effective technological way of
preventing malicious developers from using the tree to screw over end
users. Signing isn't designed to and can't prevent that class of
attack (and nor can it protect against compromised end user systems).
What it *can* do is reduce the amount of damage done by a compromised
rsync server.

> > And if you are worrying about malicious developers, you need to
> > worry about malicious infra people too. An infra member throwing
> > his toys out of the pram can do much more lasting damage than
> > someone who can get some global scope nastiness into an ebuild for
> > an hour or two... 
>
> That has nothing to do with the discussion ... and I don't see how
> infra could manipulate the signatures in a useful way apart from
> adding keys or removing some from the official keyring ...
> This they could do at the moment by manipulating the cvs to rsync
> copy process, but I'm not aware of something like that happening. So
> you might want to have a marginal trust in people and not accuse them
> of things they might do in the future ...

That's exactly the thing under discussion -- the design of the system
necessitates trust in both the main repository and the end user system,
and signing does absolutely nothing to help there. No-one is suggesting
that anyone from infra is going to do anything to utterly screw over
Gentoo for petty personal reasons.

-- 
Ciaran McCreesh

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

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

[Patrick Lauer]

Mike Auty wrote:
> Ciaran McCreesh wrote:
> |
> | Signing offers no protection against a malicious developer.
> |
>
> I had envisaged a system whereby when the tree was synced, as was some
> kind of master signed list of all acceptable dev-keys.  Every package
> would also be signed, and would only be installed when signed.  As soon
> as a dev becomes a liability their key is removed from the list/revoked.
> ~ On next sync any packages or package upgrades signed after the time of
> revocation would not be installed.  There would be a window of
> vulnerability, but no bigger than with revoking a dev's access to the
> tree.  Do you think this would offer suitable protection for users from
> a malicious dev or not?
There has been some previous work which has never been finalized, for 
all interested parties:
http://viewcvs.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/

Getting this cleaned up and ready for discussion would be quite valuable.
>
> I understand there are difficulties with eclasses, etc, which is why the
> current implementation is still not widely used or mandated, but I'm
> more interested in the feasibility of the idea.
It can be done if people can agree to a policy and allow the 
programmatic and infrastructural changes to happen.

Have fun,

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

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

[Patrick Lauer]

Ciaran McCreesh wrote:
> On Thu, 03 Apr 2008 14:29:10 +0200
> Patrick Lauer <bugs@dev.gentooexperimental.org> wrote:
>   
>>> Nope. In fact, using such a system, there are ways of getting in
>>> code that doesn't get triggered until someone's key gets
>>> invalidated. 
>>>       
>> By this reasoning you shouldn't use passwords ...
>>
>> The idea is to limit the attack vectors and make simple attacks much 
>> harder. A sophisticated "hacker" could just rent a busload of angry 
>> serbians, kidnap 12 developers and force them to do some subtle
>> changes in many places. But is that likely to happen?
>>     
>
> No no. The point is, there's no effective technological way of
> preventing malicious developers from using the tree to screw over end
> users. Signing isn't designed to and can't prevent that class of
> attack (and nor can it protect against compromised end user systems).
> What it *can* do is reduce the amount of damage done by a compromised
> rsync server.
>   
So then we should at first focus the discussion on a few things:
- what classes of attackers are there
- what defense mechanisms we can use
- what the costs (complexity, time, extra code) of each defense is

and then, from that design space, select the option(s) that have the 
best behaviour. If you get bored you can read the not-yet-GLEPs robbat2 
has written with the help of a few others, which would cut out a large 
part of the discussion:
http://viewcvs.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/

That's exactly the thing under discussion -- the design of the system
> necessitates trust in both the main repository and the end user system,
> and signing does absolutely nothing to help there. No-one is suggesting
> that anyone from infra is going to do anything to utterly screw over
> Gentoo for petty personal reasons.
>   
But if you don't trust anyone there is no reason why you would even try 
to interact with Gentoo. So at some point you will have to decide to 
arbitrarily trust a few entities, be it devs or servers or cryptographic 
keys ...



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

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

[Ciaran McCreesh]

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

On Thu, 03 Apr 2008 14:44:45 +0200
Patrick Lauer <bugs@dev.gentooexperimental.org> wrote:
> and then, from that design space, select the option(s) that have the 
> best behaviour. If you get bored you can read the not-yet-GLEPs
> robbat2 has written with the help of a few others, which would cut
> out a large part of the discussion:
> http://viewcvs.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/

Uh... Which signing system did you think we were discussing when we
started talking about signing the tree?

> But if you don't trust anyone there is no reason why you would even
> try to interact with Gentoo. So at some point you will have to decide
> to arbitrarily trust a few entities, be it devs or servers or
> cryptographic keys ...

Uh huh, which is what my original reply to Mike was all about.

We're way ahead of you here...

-- 
Ciaran McCreesh

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

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

[Patrick Lauer]

Ciaran McCreesh wrote:
> On Thu, 03 Apr 2008 14:44:45 +0200
> Patrick Lauer <bugs@dev.gentooexperimental.org> wrote:
>   
>> and then, from that design space, select the option(s) that have the 
>> best behaviour. If you get bored you can read the not-yet-GLEPs
>> robbat2 has written with the help of a few others, which would cut
>> out a large part of the discussion:
>> http://viewcvs.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/
>>     
>
> Uh... Which signing system did you think we were discussing when we
> started talking about signing the tree?
>   
Well, now we agree that we talk about the same thing after only 4 email 
pingpongs. That is quite fast!
>> But if you don't trust anyone there is no reason why you would even
>> try to interact with Gentoo. So at some point you will have to decide
>> to arbitrarily trust a few entities, be it devs or servers or
>> cryptographic keys ...
>>     
>
> Uh huh, which is what my original reply to Mike was all about.
>
> We're way ahead of you here...
>   
Or so you think.

So now that you've tried to label me as a dimwit we're past that stage 
and can now return to actually discussing the set of issues and how to 
handle them, ja?


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

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

[Ciaran McCreesh]

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

On Thu, 03 Apr 2008 14:55:43 +0200
Patrick Lauer <bugs@dev.gentooexperimental.org> wrote:
> > Uh huh, which is what my original reply to Mike was all about.
> >
> > We're way ahead of you here...
> >   
> Or so you think.
> 
> So now that you've tried to label me as a dimwit we're past that
> stage and can now return to actually discussing the set of issues and
> how to handle them, ja?

We established a long time ago that handling the issues isn't a
technological problem.

-- 
Ciaran McCreesh

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

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

[Richard Freeman]

Mike Auty wrote:
> So the still unanswered question appears to be, would we like Gentoo to
> have fewer packages and less choice but greater QA, stability and a feel
> of professionalism, or would we like to have more packages and choice
> but a worse QA record, make some mistakes, and have a more
> community-based feel?  If you're going to try to answer this question
> please be delicate with your repsonses, in the past I can recall
> developers leaving over exactly this divide...
> 

Well, Gentoo is about choice, so why not be both?  We already have 
~arch/arch and overlays, and if the need really arose we could have more 
levels of QA.  Then everybody can have the level of bleeding-edge that 
they desire.

Maybe all we need is to make it easier to contribute to overlays and use 
overlays, and then have a moderately-higher general level of QA in the 
main tree, and then the highest level of QA for stable (particularly for 
system packages).  You could even have the opposite - maybe a 
super-stable overlay for stuff like server apps with backported patches 
that users could elect to take priority even over the portage tree.  The 
only real gap is a general facility for assigning priority for 
repositories (possibly on a per-package basis), and maybe a GUI for 
managing everything.

Regardless, as long as devs actually follow policy I don't see any need 
to boot them.  Maybe very long periods of inactivity should result in 
having accounts locked as a security measure (so that we don't end up 
with hundreds of ssh keys with commit access floating around who knows 
where).  Booting out lots of devs just takes a limited set of resources 
and limits them further.  If anything we want to find a way to let more 
people contribute in a significant way - not less...
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Tiziano Müller]

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

GLEP-0046

Thanks.


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

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

[Thomas Anderson]

On 11:35 Thu 03 Apr     , Jorge Manuel B. S. Vicetto wrote:
> Petteri R??ty wrote:
>> Jorge Manuel B. S. Vicetto kirjoitti:
>>> Petteri R??ty wrote:
>>>
>>>
>>> As others have commented, I don't agree with this point. Also, you're 
>>> forgetting we have quite a few people working on this project and that we 
>>> have many different roles.
>>  >
>> And you are assuming that undertakers wouldn't check their role before 
>> acting.
>
> I read it as a rule to drop developers. If we're only talking about it 
> raising a warning to undertakers so they can check the dev status, then I 
> don't have a problem with the proposal.
>
>>> Recalling previous discussions about work on gentoo and some of the 
>>> existing roles, what will you do to AT folks, release members or QA 
>>> members? Are they also obliged to do a weekly commit to keep their 
>>> "privileges"?
>> AT folks aren't devs and see above.
>
> To be clear, I didn't meant arch testers but people that do keywords for 
> arch teams.

Actually, 'AT' can refer to either arch teams or Arch Testers, but given
the fact that he was referring to those people with commit access, it
should be obvious he meant 'Arch Teams'.

Thomas

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

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

[Wulf C. Krueger]

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

> If we used git, proxy maintaining would be easier.

Many things would be easier then. I'm all for switching to git.

-- 
Best regards, Wulf

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

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

[Christian Faulhammer]

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

Hi,

"Wulf C. Krueger" <philantrop@gentoo.org>:
> > If we used git, proxy maintaining would be easier.
> 
> Many things would be easier then. I'm all for switching to git.

 Robbat2 is really monitoring our options...I think he would be first
to announce a git test tree.  Upstream of git has to sort some things
out if I remember correctly.

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

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

[Christian Faulhammer]

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

Hi,

Mike Auty <ikelos@gentoo.org>:
> So the still unanswered question appears to be, would we like Gentoo
> to have fewer packages and less choice but greater QA, stability and
> a feel of professionalism, or would we like to have more packages and
> choice but a worse QA record, make some mistakes, and have a more
> community-based feel?  If you're going to try to answer this question
> please be delicate with your repsonses, in the past I can recall
> developers leaving over exactly this divide...

 Sometimes we have bugs and packages that have some official
maintainer, but he never reacts...do we want that? Sometimes I clear
some old bugs assigned to some, that are trivial to fix; seldomly I get
a reaction from that person (negatively or positively). 
 I have no problem with a trigger for undertakers so they can go and
check if the person committing only a bit takes care of his bugs...

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 April

[Chrissy Fullam]

> Petteri Räty wrote:
> > Mike Frysinger kirjoitti:
> > 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.
> 
> Defining required amount of activity for ebuild devs. I would like us to
> raise the required amount of activity for ebuild devs. Just committing
> monthly is not enough imho to require a developer status. How does having
> the average time between commits be at most a week sound and if it goes
> under that, undertakers will get a notification? Devaway would be there of
> course as usual

Why four commits a month? Currently we are at one commit a month, any reason to quadruple it instead of requesting a slight raise, such as two commits a month? 

My concern is that not all developers who do contribute something each month can give Gentoo the commitment you request for every month. Should we lose their contributions as they are a smaller quantity because some people think that if you cant do more all the time then it's just not good enough? 

It seems that the goal should be to find positive ways to encourage more developers to become active, not start retiring those that cant give Gentoo as much time that others can.


Kind regards,
Christina Fullam
Gentoo Developer Relations Lead | Gentoo Public Relations 




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

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

[Petteri Räty]

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

Chrissy Fullam kirjoitti:
>> Petteri Räty wrote:
>>> Mike Frysinger kirjoitti:
>>> 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.
>> Defining required amount of activity for ebuild devs. I would like us to
>> raise the required amount of activity for ebuild devs. Just committing
>> monthly is not enough imho to require a developer status. How does having
>> the average time between commits be at most a week sound and if it goes
>> under that, undertakers will get a notification? Devaway would be there of
>> course as usual
> 
> Why four commits a month? Currently we are at one commit a month, any reason to quadruple it instead of requesting a slight raise, such as two commits a month? 
> 
> My concern is that not all developers who do contribute something each month can give Gentoo the commitment you request for every month. Should we lose their contributions as they are a smaller quantity because some people think that if you cant do more all the time then it's just not good enough? 
> 
> It seems that the goal should be to find positive ways to encourage more developers to become active, not start retiring those that cant give Gentoo as much time that others can.
> 
> 

I checked the current slacker script and it checks for having at least 
one commit in last 60 days. We could of course just change the slacker 
script to list the activity for everyone during the last 60 days and 
leave the interpretation to undertakers.

Regards,
Petteri


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

RE: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Chrissy Fullam]

> Petteri Räty wrote:
> 
> I checked the current slacker script and it checks for having at least one
> commit in last 60 days. We could of course just change the slacker script
> to list the activity for everyone during the last 60 days and leave the
> interpretation to undertakers.

Interesting information, thank you for looking into the detail; I had been led to believe it was for 30 days. I do see value to modifying the script to list all activity, aiding undertakers in their task as well as useful information for those who may inquire.
I do not rightly recall who wrote the script. Who can modify that script for us so we may test it out?


Kind regards,
Christina Fullam
Gentoo Developer Relations Lead | Gentoo Public Relations 




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

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

[Donnie Berkholz]

On 09:53 Thu 03 Apr     , Thomas Anderson wrote:
> On 11:35 Thu 03 Apr     , Jorge Manuel B. S. Vicetto wrote:
> > Petteri R??ty wrote:
> >>> Recalling previous discussions about work on gentoo and some of the 
> >>> existing roles, what will you do to AT folks, release members or QA 
> >>> members? Are they also obliged to do a weekly commit to keep their 
> >>> "privileges"?
> >> AT folks aren't devs and see above.
> >
> > To be clear, I didn't meant arch testers but people that do keywords for 
> > arch teams.
> 
> Actually, 'AT' can refer to either arch teams or Arch Testers, but given
> the fact that he was referring to those people with commit access, it
> should be obvious he meant 'Arch Teams'.

It wasn't obvious at all to me, because he was talking about people who 
would have trouble keeping commit access. My understanding is that arch 
team members are constantly testing and keywording.

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

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

[Chris Gianelloni]

On Thu, 2008-04-03 at 13:49 +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
> > > If we used git, proxy maintaining would be easier.
> > >
> >
> >  True, but with some acls we could also have a different model where people
> > worked on parts of the tree and where commit privileges didn't pose so many
> > security risks. With the current practice of doing work in overlays it would
> > also be simpler to merge the work back into the Portage tree.
> 
> Also Subversion would be sufficient.

Release Engineering has been using subversion for the 2008.0 snapshot
tree.  The repository is running in tmpfs on a dual Opteron box.  IT's
still quite painfully slow.  Of course, we're doing commits at the
top-level since we have a single top-level ChangeLog for the repository,
but we don't even have history.  We literally just pulled ebuilds from
the tree.

Once the release is done, we can play around with the repository all
that we want to get some real numbers, but unless there's some magic
bullet that I'm missing, subversion might simply be too damned slow for
our needs.  As an anecdotal example, I've had a single commit of several
profiles take up to 6 minutes to complete, and that's not with repoman
or anything.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Chris Gianelloni]

On Thu, 2008-04-03 at 09:21 -0400, Richard Freeman wrote:
> Regardless, as long as devs actually follow policy I don't see any need 
> to boot them.  Maybe very long periods of inactivity should result in 
> having accounts locked as a security measure (so that we don't end up 
> with hundreds of ssh keys with commit access floating around who knows 
> where).  Booting out lots of devs just takes a limited set of resources 
> and limits them further.  If anything we want to find a way to let more 
> people contribute in a significant way - not less...

I think many people seem to forget that it isn't the number of
developers or the number of commits.  It is all about the amount of
actual work that gets done.  We need more work being done.  Period.  It
doesn't matter how that gets accomplished, but it is what we need.
Removing less active developers would be perfectly fine once we had a
good proxy maintainer program in place that would allow people to
contribute easily without having to have commit access.  A developer who
only commits rarely isn't any more valuable to Gentoo than a "regular
user" who contributes at the same pace.  The only difference is the
commit access and the Gentoo resources used by the individual.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Bo Ørsted Andresen]

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

On Thursday 03 April 2008 14:55:43 Patrick Lauer wrote:
> >> But if you don't trust anyone there is no reason why you would even
> >> try to interact with Gentoo. So at some point you will have to decide
> >> to arbitrarily trust a few entities, be it devs or servers or
> >> cryptographic keys ...
> >
> > Uh huh, which is what my original reply to Mike was all about.
> >
> > We're way ahead of you here...
>
> Or so you think.
>
> So now that you've tried to label me as a dimwit 

I think you managed that quite well on your own.

> we're past that stage and can now return to actually discussing the set of
> issues and how to handle them, ja?

The point of this subthread was that limiting developers' access to only the 
parts of the tree they are going to work on accomplishes nothing from a 
security point of view and only makes things harder when they occasionally 
need to do tree wide changes from any other point of view. There is no 
technical solution that can "fix" that.

-- 
Bo Andresen
Gentoo KDE Dev

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

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

[Peter Volkov]

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

В Чтв, 03/04/2008 в 18:56 +0300, Petteri Räty пишет:
> >> Petteri Räty wrote:
> >> Defining required amount of activity for ebuild devs. I would like us to
> >> raise the required amount of activity for ebuild devs. 

> I checked the current slacker script and it checks for having at least 
> one commit in last 60 days. We could of course just change the slacker 
> script to list the activity for everyone during the last 60 days and 
> leave the interpretation to undertakers.

Number of commits is bad measure for work and time spent on gentoo: some
work require long investigation and exactly one commit, while another
work require lots of commits and small amount of time spent on that. So,
please, stop this formalism!

Also this change does not magically fix bugs so bugs are different
issue. If you know how/want to fix the bug just mail maintainer, wait
some time (one day normally is enough if bug was opened for a long
time...) and fix bug. That's it! No need to retire maintainer to fix
bugs in his packages.

Security is also unrelated as this change does not improve security.

The only reason we have that script is to check that developer really
left gentoo, but forgot to notify infra...

-- 
Peter.

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

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

[Petteri Räty]

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

Petteri Räty kirjoitti:
> 
> I checked the current slacker script and it checks for having at least 
> one commit in last 60 days. We could of course just change the slacker 
> script to list the activity for everyone during the last 60 days and 
> leave the interpretation to undertakers.
> 
> Regards,
> Petteri
> 

So I wrote a new slacker script that gets the active developers from 
LDAP and checks the activity for the last 60 days. One repoman commit 
should equal a couple entries on history but not sure on that. robbat2 
succested that we add the info to LDAP on who is expected to have 
commits so purely infra people would not show up. Current slacker script 
has the info hard coded. Posting to public as the info is available via 
anoncvs for example any way.


betelgeuse@stork ~ $ python slacker.py /var/cvsroot/CVSROOT/history
0 aetius
0 agaffney
0 amne
0 aross
0 b33fc0d3
0 bbj
0 blackace
0 cab
0 codeman
0 dams
0 dav_it
0 dcoutts
0 desultory
0 djay
0 dmwaters
0 dostrow
0 earthwings
0 ehmsen
0 eradicator
0 gmsoft
0 hparker
0 jforman
0 jmglov
0 joslwah
0 jrinkovs
0 jsin
0 kallamej
0 kanaka
0 kernelsensei
0 klieber
0 kolmodin
0 leonardop
0 livewire
0 markm
0 mbres
0 mdisney
0 mduft
0 musikc
0 pilla
0 pingu
0 pipping
0 pjp
0 polvi
0 psi29a
0 pvdabeel
0 r3pek
0 ramereth
0 redhatter
0 rl03
0 shellsage
0 stkn
0 strerror
0 tacotest
0 tchiwam
0 the_paya
0 think4urs11
0 thoand
0 tomk
0 vanquirius
0 wormo
1 hattya
1 neddyseagoon
1 yuval
2 astinus
2 jaervosz
2 maedhros
2 tantive
2 trapni
3 ferdy
3 haubi
3 mattepiu
3 pauldv
4 kumba
4 mjolnir
4 pappy
4 radek
5 dju
5 g2boojum
5 joker
5 killerfox
5 ribosome
5 tommy
6 centic
6 jurek
7 mark_alec
7 sirseoman
8 nichoj
8 swift
9 tsunam
9 vorlon
10 cryos
10 griffon26
10 peitolm
11 jkt
11 spb
12 kingtaco
12 moloh
13 fordfrog
13 jmbsvicetto
13 peper
14 chtekk
14 elvanor
15 battousai
15 lucass
15 nixphoeni
16 bass
16 kang
17 falco
17 ian
17 shindo
18 jakub
18 pythonhead
19 fuzzyray
19 humpback
19 keytoaster
19 pclouds
19 yoswink
20 agorf
21 gregkh
22 genone
22 gurligebis
23 smithj
24 anant
26 george
26 iluxa
26 je_fro
27 chiguire
27 chutzpah
27 marineam
28 flammie
29 deathwing00
30 fox2mike
32 drizzt
32 lavajoe
32 phosphan
33 rajiv
35 truedfx
39 lordvan
41 py
42 araujo
42 cam
46 zmedico
48 rbrown
49 jsbronder
49 yvasilev
51 antarus
51 omp
52 lack
52 lu_zero
52 titefleur
53 tupone
54 josejx
59 dsd
60 grobian
60 voxus
61 suka
62 s4t4n
63 pylon
65 ikelos
65 mrness
67 bangert
68 hoffie
68 stefaan
70 spock
71 ali_bush
74 halcy0n
78 hkbst
79 keri
79 steev
83 nerdboy
83 tgall
87 solar
88 welp
88 wrobel
89 mabi
89 tgurr
95 sbriesen
98 williamh
100 chainsaw
105 ken69267
106 rich0
109 rbu
111 remi
126 tove
130 zaheerm
136 dang
142 matsuu
144 hawking
146 voyageur
158 swegener
159 compnerd
159 nelchael
159 neysx
159 zlin
163 genstef
171 yngwin
177 dragonheart
187 caleb
188 alonbl
189 grahl
192 klausman
193 markusle
194 hanno
200 calchan
203 ticho
206 zzam
225 mpagano
226 caster
226 dirtyepic
239 wltjr
252 ricmm
253 xmerlin
262 hd_brummy
267 cla
275 wschlich
281 tester
290 nyhm
292 dev-zero
302 cedk
326 angelos
350 bicatali
354 shadow
363 scen
364 pebenito
406 fmccor
433 pva
462 dberkholz
487 robbat2
493 dertobi123
494 nightmorph
524 rane
525 flameeyes
527 betelgeuse
531 beandog
532 ulm
584 jokey
598 r0bertz
603 cardoe
632 carlo
669 graaff
692 eva
704 phreak
715 mr_bones_
742 leio
763 hollow
920 aballier
946 wolf31o2
978 corsair
1046 nixnut
1063 maekke
1088 coldwind
1094 drac
1118 ranger
1590 vapier
1671 opfer
2836 jer
3404 armin76
26767 ingmar
41523 philantrop


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

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

[Mike Pagano]

On Monday 07 April 2008 04:37:18 pm Petteri Räty wrote:
> Petteri Räty kirjoitti:
> > 
> So I wrote a new slacker script that gets the active developers from 
> LDAP and checks the activity for the last 60 days. One repoman commit 
> should equal a couple entries on history but not sure on that. robbat2 
> succested that we add the info to LDAP on who is expected to have 
> commits so purely infra people would not show up. Current slacker script 
> has the info hard coded. Posting to public as the info is available via 
> anoncvs for example any way.
> 
> 
> betelgeuse@stork ~ $ python slacker.py /var/cvsroot/CVSROOT/history
> snip

I may be incorrect but I do believe I see some 'staff' level people without commit access on the list. We may want to exclude them along with the infra folks, also.
--
gentoo-dev@lists.gentoo.org mailing list

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

[Jan Kundrát]

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

Petteri Räty wrote:
> 26767 ingmar
> 41523 philantrop

Go KDE go! :)

Cheers,
-jkt

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


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

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

[Petteri Räty]

[-- Attachment #1.1: Type: text/plain, Size: 1166 bytes --]

Mike Pagano kirjoitti:
> On Monday 07 April 2008 04:37:18 pm Petteri Räty wrote:
>> Petteri Räty kirjoitti:
>> So I wrote a new slacker script that gets the active developers from 
>> LDAP and checks the activity for the last 60 days. One repoman commit 
>> should equal a couple entries on history but not sure on that. robbat2 
>> succested that we add the info to LDAP on who is expected to have 
>> commits so purely infra people would not show up. Current slacker script 
>> has the info hard coded. Posting to public as the info is available via 
>> anoncvs for example any way.
>>
>>
>> betelgeuse@stork ~ $ python slacker.py /var/cvsroot/CVSROOT/history
>> snip
> 
> I may be incorrect but I do believe I see some 'staff' level people without commit access on the list. We may want to exclude them along with the infra folks, also.

Guess I wasn't clear enough. There is no filtering in that list based on 
the developer role in Gentoo. It's all Gentoo developers marked as 
active in LDAP. We first need to add the LDAP attributes before we can 
add the filter to the script. Might as well attach the script too.

Regards,
Petteri

[-- Attachment #1.2: history.py --]
[-- Type: text/plain, Size: 888 bytes --]

def fetch_nicks_from_ldap():
	import ldap
	l = ldap.initialize('ldap://ldap1.gentoo.org')
	l.set_option(ldap.OPT_X_TLS_DEMAND, True)
	l.start_tls_s()
	l.simple_bind_s()
	nicks = {}
	for entry in l.search_s('ou=devs,dc=gentoo,dc=org', ldap.SCOPE_ONELEVEL,
							filterstr='(&(gentooStatus=active)(uid=*))', attrlist=['uid']):
			nicks[entry[1]['uid'][0]] = 0
	l.unbind()
	return nicks

import sys

if len(sys.argv) < 2:
	sys.stderr.write("Give CVS history file location.\n")
	sys.exit(1)

from  datetime import datetime,timedelta
start = datetime.now() - timedelta(days=60)
f = open(sys.argv[1],'r')
nicks = fetch_nicks_from_ldap()
for line in f:
	time,nick = line.split('|')[0:2]
	time = datetime.fromtimestamp(int(time[1:], 16))
	if time > start and nick in nicks:
		nicks[nick] += 1
f.close()

for t in sorted(nicks.items(), key=lambda(k,v):(v,k)):
	print "%d %s" % tuple(reversed(t))

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

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

[Robin H. Johnson]

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

On Tue, Apr 08, 2008 at 03:10:03AM +0300, Petteri R??ty wrote:
> Guess I wasn't clear enough. There is no filtering in that list based on 
> the developer role in Gentoo. It's all Gentoo developers marked as active 
> in LDAP. We first need to add the LDAP attributes before we can add the 
> filter to the script. Might as well attach the script too.
Furthermore, to clarify, while it includes all CVS add/remove/modify
commits, it doesn't include any SVN operations.

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

[Roy Bamford]

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

On 2008.04.07 21:37, Petteri Räty wrote:
> Petteri Räty kirjoitti:
> > 
> > I checked the current slacker script and it checks for having at
> least 
> > one commit in last 60 days. We could of course just change the
> slacker 
> > script to list the activity for everyone during the last 60 days 
> and
> 
> > leave the interpretation to undertakers.
> > 
> > Regards,
> > Petteri
> > 
> 
> So I wrote a new slacker script that gets the active developers from 
> LDAP and checks the activity for the last 60 days. One repoman commit 
> should equal a couple entries on history but not sure on that. 
> robbat2

[snip]

> Posting to public as the info is available
> via anoncvs for example any way.
> 
> 
> betelgeuse@stork ~ $ python slacker.py /var/cvsroot/CVSROOT/history
[snip]
> 1 neddyseagoon
[snip]

That's worrying, I'm not supposed to have commit access to the tree.
trustees docs, yes but that's the limit. To my knowledge, I've never 
made a commit there either.

We should exclude forums mods who are not ebuild developers, (like me).
I see a few forums mods in the lists, e.g. amne and pilla.

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkf7q74ACgkQTE4/y7nJvasdDACfU5hMP7dQjHFZmnKLaaFz+vEI
oK4An3pjGMnTQjldOW5tv71JrWS0i6m9
=K4ZB
-----END PGP SIGNATURE-----

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

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

[Robin H. Johnson]

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

On Tue, Apr 08, 2008 at 06:30:17PM +0100, Roy Bamford wrote:
> That's worrying, I'm not supposed to have commit access to the tree.
> trustees docs, yes but that's the limit. To my knowledge, I've never 
> made a commit there either.
That's for ALL of CVS. Not just gentoo-x86.

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

[Raúl Porcel]

I win, as always *g*
-- 
gentoo-dev@lists.gentoo.org mailing list