[gentoo-dev] Monthly Gentoo Council Reminder for April

[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 / 1500 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@gentoo.org mailing list

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

[Mike Doty]

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

Mike Frysinger wrote:
> some topics off the top of my head:
>  - unaddressed CoC issues:
> 	- add a "mission" statement
> 	- fix wording to have a positive spin
> 	- what else ?
>  - sync Social Contract with Gentoo Foundation statement (external entities)
>  - documentation for mail servers still pending i believe (SPF / reply-to)
>  - PMS:
> 	- status update from spb
> 	- moving it to Gentoo svn
> 	- schedule for getting remaining issues settled
>  - splitting gentoo-dev mailing lists ?
> -mike
apparent decline of QA in our packages.

- --
=======================================================
Mike Doty                      kingtaco -at- gentoo.org
Gentoo Council
Gentoo Infrastructure
Gentoo/AMD64 Strategic Lead
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (GNU/Linux)

iQCVAwUBRhNA4oBrouQZ9K4FAQI5UAQAwvttdK9LELxXCckP4wm3AblkNt7y0SAt
7RX5H4X7b0Jmp0E2uGYnWGRcdQcLCLxDNkIrNK7NDZgo+zOJeuHL6kOe8v1FaQYl
REifgbI1iltpvRPdMmBFL9wnDbRJt2CiG7RwpTS0aR503JGt+CjY5TYzvH4g194U
vsXBGvCXHB4=
=bdZs
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Donnie Berkholz]

Mike Doty wrote:
> apparent decline of QA in our packages.

Anyone got numbers for that? Talking opinions, as in the SCM discussion, 
isn't real meaningful.

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

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

[Mike Doty]

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

Donnie Berkholz wrote:
> Mike Doty wrote:
>> apparent decline of QA in our packages.
> 
> Anyone got numbers for that? Talking opinions, as in the SCM discussion,
> isn't real meaningful.
> 
> Thanks,
> Donnie
What metric would you use?  the number of stages tried against a live
tree before one can install?  the number of companies leaving gentoo for
another distro? bugs? mailing list posts? number of users?

I don't know of a good metric for what you ask.  Here's what I do know:
1) a QA team was formed in 06
2) QA has not visibly improved since then.  To the outsider, it looks
like it's gotten worse.

- --
=======================================================
Mike Doty                      kingtaco -at- gentoo.org
Gentoo Council
Gentoo Infrastructure
Gentoo/AMD64 Strategic Lead
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (GNU/Linux)

iQCVAwUBRhUk0oBrouQZ9K4FAQLY0QP/fa1wU/4yJsc7eY5m/GVCrsJPNYreQf70
JxnWDBfu1bCn6byGjYnRb5rHc0MIJ6BfwxEm1cD6KKF89fRIG4RxZyzGDZd3ISnv
m5tkhjHnl4EQHJyGHI/Jh5SQomFNDZJBtoRLP0YHuejCfrd6YjXoLd/PGMKogBg1
LSlthDzxrmw=
=qj95
-----END PGP SIGNATURE-----
-- 
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

[gentoo-dev] QA sucks

[Torsten Veller]

* Mike Doty <kingtaco@gentoo.org>:
>  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.

So what do you want to do about it?
-- 
gentoo-dev@gentoo.org mailing list

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

[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

[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

[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

[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

[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

[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] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Thu, 5 Apr 2007 15:11:47 -0700
Brian Harring <ferringb@gmail.com> wrote:
> 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.

Well, EAPI 1 needs to be delivered quickly... So it's down to what
Portage can give quickly... Candidates, I believe, being:

* SLOT deps, but probably not USE deps
* Remove automatic directory making for do*
* do* fail on missing files
* Phase changes: src_fetch -> src_unpack -> src_prepare ->
src_configure -> src_compile -> src_test -> src_install
* src_test always called except if RESTRICT=test
* no automatic RDEPEND
* *DIR, ROOT guaranteed to end in /

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Luca Barbato]

Ciaran McCreesh wrote:
> * Remove automatic directory making for do*

Why?

lu


-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > * Remove automatic directory making for do*
>
> Why?

hmm guess i should have read each item ... this is not something we want to do 
and i dont recall anyone ever mentioning this change in behavior
-mike

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Marius Mauch]

On Wed, 11 Apr 2007 15:41:01 +0100
Ciaran McCreesh <ciaranm@ciaranm.org> wrote:

> On Thu, 5 Apr 2007 15:11:47 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > 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.
> 
> Well, EAPI 1 needs to be delivered quickly... So it's down to what
> Portage can give quickly... Candidates, I believe, being:
> 
> * SLOT deps, but probably not USE deps
> * Remove automatic directory making for do*

No

> * do* fail on missing files
> * Phase changes: src_fetch -> src_unpack -> src_prepare ->
> src_configure -> src_compile -> src_test -> src_install

No to src_fetch

> * src_test always called except if RESTRICT=test

I don't think this would fit into EAPI, to me it's an implementation
detail of the package manager, or why should the ebuild care about it?

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Marius Mauch wrote:
> Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> > * src_test always called except if RESTRICT=test
>
> I don't think this would fit into EAPI, to me it's an implementation
> detail of the package manager, or why should the ebuild care about it?

hmm, i'd have to agree ... this is something that could be done easily via the 
profile in EAPI-0 now ... requiring package managers to behave this way 
doesnt really gain anything
-mike

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 14:21:16 +0200
Marius Mauch <genone@gentoo.org> wrote:
> On Wed, 11 Apr 2007 15:41:01 +0100
> Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> > * Remove automatic directory making for do*
> 
> No

It masks all kinds of programming screwups. doblah should make a blah,
not make a blah and possibly make a directory.

> > * do* fail on missing files
> > * Phase changes: src_fetch -> src_unpack -> src_prepare ->
> > src_configure -> src_compile -> src_test -> src_install
> 
> No to src_fetch

Why? It would be useful for CVS, SVN etc ebuilds. I'm not suggesting it
be used for SRC_URI things.

> > * src_test always called except if RESTRICT=test
> 
> I don't think this would fit into EAPI, to me it's an implementation
> detail of the package manager, or why should the ebuild care about it?

It's the best way of ensuring that ebuilds have a working src_test.
Arch teams need this.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Ciaran McCreesh wrote:
> Marius Mauch <genone@gentoo.org> wrote:
> > Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> > > * Remove automatic directory making for do*
> >
> > No
>
> It masks all kinds of programming screwups. doblah should make a blah,
> not make a blah and possibly make a directory.

name one

you're proposing we suddenly bloat all of our src_install functions for no 
gain at all ... sounds like a no brainer to me

> > > * src_test always called except if RESTRICT=test
> >
> > I don't think this would fit into EAPI, to me it's an implementation
> > detail of the package manager, or why should the ebuild care about it?
>
> It's the best way of ensuring that ebuilds have a working src_test.
> Arch teams need this.

then arch teams can update their profiles
-mike

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 10:53:38 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> > It masks all kinds of programming screwups. doblah should make a
> > blah, not make a blah and possibly make a directory.
> 
> name one

dosym's old behaviour prevented a broken Vim release (upstream screwed
up a Makefile dependency) from getting into the tree unnoticed. Had
that happened after you changed some (but not all) of the do*
utilities, the duff symlinks would probably have gone unnoticed for a
while.

> you're proposing we suddenly bloat all of our src_install functions
> for no gain at all ... sounds like a no brainer to me

No, I'm proposing that functions not have strange side effects.

> > > > * src_test always called except if RESTRICT=test
> > >
> > > I don't think this would fit into EAPI, to me it's an
> > > implementation detail of the package manager, or why should the
> > > ebuild care about it?
> >
> > It's the best way of ensuring that ebuilds have a working src_test.
> > Arch teams need this.
> 
> then arch teams can update their profiles

Well no, they can't, because there are a whole load of ebuilds that
will break if they do that. But if it's introduced as mandatory
(barring ebuilds RESTRICTing it) for EAPI 1, the tree will slowly move
towards everything that reasonably can do having working test suites,
which will be a huge step forward for QA.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> wrote:
> > > It masks all kinds of programming screwups. doblah should make a
> > > blah, not make a blah and possibly make a directory.
> >
> > name one
>
> dosym's old behaviour prevented a broken Vim release (upstream screwed
> up a Makefile dependency) from getting into the tree unnoticed. Had
> that happened after you changed some (but not all) of the do*
> utilities, the duff symlinks would probably have gone unnoticed for a
> while.

improper package testing that was saved by a dosym that did not create 
directories ... useful mayhaps, but not nearly enough to justify the proposed 
change

> > you're proposing we suddenly bloat all of our src_install functions
> > for no gain at all ... sounds like a no brainer to me
>
> No, I'm proposing that functions not have strange side effects.

the behavior here is desired ... you install into a directory, then the 
directory should exist

> Well no, they can't, because there are a whole load of ebuilds that
> will break if they do that. But if it's introduced as mandatory
> (barring ebuilds RESTRICTing it) for EAPI 1, the tree will slowly move
> towards everything that reasonably can do having working test suites,
> which will be a huge step forward for QA.

that's really the QA's job to enforce, not the package manager

if the QA team wants to spear head a tree wide effort at getting src_test up 
and running, they're certainly free to
-mike

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 11:52:16 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> > > you're proposing we suddenly bloat all of our src_install
> > > functions for no gain at all ... sounds like a no brainer to me
> >
> > No, I'm proposing that functions not have strange side effects.
> 
> the behavior here is desired ... you install into a directory, then
> the directory should exist

These fail:

cp somefile dirdoesnotexist/
mv somefile dirdoesnotexist/
ln -s somefile dirdoesnotexist/
dohard somefile dirdoesnotexist/
mkdir dirdoesnotexist/newdir

This succeeds:

dosym somefile dirdoesnotexist/

> > Well no, they can't, because there are a whole load of ebuilds that
> > will break if they do that. But if it's introduced as mandatory
> > (barring ebuilds RESTRICTing it) for EAPI 1, the tree will slowly
> > move towards everything that reasonably can do having working test
> > suites, which will be a huge step forward for QA.
> 
> that's really the QA's job to enforce, not the package manager
> 
> if the QA team wants to spear head a tree wide effort at getting
> src_test up and running, they're certainly free to

The arch teams have been pushing for this for a long time. They're
trying to get this enforced, but are having limited success because
there's no way for FEATURES=test to become widely used that won't lead
to broken user systems. Moving src_test to be always on in future EAPIs
is an easy way of helping arch teams achieve this goal without breaking
anyone's system in the meantime.

-- 
Ciaran McCreesh


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

[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Steve Long]

Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> wrote:
>> > > you're proposing we suddenly bloat all of our src_install
>> > > functions for no gain at all
How big a bloat is it? Surely it's a coupla lines in the eclasses? Cos the
behaviour is inconsistent, as Ciaran pointed out.

>> > Well no, they can't, because there are a whole load of ebuilds that
>> > will break if they do that. But if it's introduced as mandatory
>> > (barring ebuilds RESTRICTing it) for EAPI 1, the tree will slowly
>> > move towards everything that reasonably can do having working test
>> > suites, which will be a huge step forward for QA.
>> 
>> that's really the QA's job to enforce, not the package manager
>> 
>> if the QA team wants to spear head a tree wide effort at getting
>> src_test up and running, they're certainly free to
> 
> The arch teams have been pushing for this for a long time. They're
> trying to get this enforced, but are having limited success because
> there's no way for FEATURES=test to become widely used that won't lead
> to broken user systems. Moving src_test to be always on in future EAPIs
> is an easy way of helping arch teams achieve this goal without breaking
> anyone's system in the meantime.
> 
I have to say Mr McCreesh's argument has persuaded me on this aspect too.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 13:02:00 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday 13 April 2007, Ciaran McCreesh wrote:
> > These fail:
> >
> > cp somefile dirdoesnotexist/
> > mv somefile dirdoesnotexist/
> > ln -s somefile dirdoesnotexist/
> > dohard somefile dirdoesnotexist/
> > mkdir dirdoesnotexist/newdir
> >
> > This succeeds:
> >
> > dosym somefile dirdoesnotexist/
> 
> any other obvious statements you care to make ?
> 
> compare your standard handwritten Makefile install: target to
> src_install() in an ebuild ... i'll take the much shorter
> src_install() any day

Except that we already know that it doesn't make a substantial
difference to the lengths of src_installs in the tree. Very few
packages are relying upon the automatic directory creation.

> > The arch teams have been pushing for this for a long time. They're
> > trying to get this enforced, but are having limited success because
> > there's no way for FEATURES=test to become widely used that won't
> > lead to broken user systems. Moving src_test to be always on in
> > future EAPIs is an easy way of helping arch teams achieve this goal
> > without breaking anyone's system in the meantime.
> 
> if you have a problem with the QA team then complain to your buddy spb

Er, no, I'm explaining why enforcing src_test for EAPI 1 will be
helpful for an awful lot of Gentoo developers.

Please refrain from that kind of comment. It doesn't help anyone.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> wrote:
> > On Friday 13 April 2007, Ciaran McCreesh wrote:
> > > These fail:
> > >
> > > cp somefile dirdoesnotexist/
> > > mv somefile dirdoesnotexist/
> > > ln -s somefile dirdoesnotexist/
> > > dohard somefile dirdoesnotexist/
> > > mkdir dirdoesnotexist/newdir
> > >
> > > This succeeds:
> > >
> > > dosym somefile dirdoesnotexist/
> >
> > any other obvious statements you care to make ?
> >
> > compare your standard handwritten Makefile install: target to
> > src_install() in an ebuild ... i'll take the much shorter
> > src_install() any day
>
> Except that we already know that it doesn't make a substantial
> difference to the lengths of src_installs in the tree. Very few
> packages are relying upon the automatic directory creation.

i bet you have hard #s to back that up ?  since you dont, bloating src_install 
is not the answer to a marginalized issue

> > > The arch teams have been pushing for this for a long time. They're
> > > trying to get this enforced, but are having limited success because
> > > there's no way for FEATURES=test to become widely used that won't
> > > lead to broken user systems. Moving src_test to be always on in
> > > future EAPIs is an easy way of helping arch teams achieve this goal
> > > without breaking anyone's system in the meantime.
> >
> > if you have a problem with the QA team then complain to your buddy spb
>
> Er, no, I'm explaining why enforcing src_test for EAPI 1 will be
> helpful for an awful lot of Gentoo developers.

except that you back the tree into a corner that it cannot come out of

> Please refrain from that kind of comment. It doesn't help anyone.

the answer is the same: talk to the QA team to get the tree into a state where 
having src_test enabled by default is feasible and then the QA team can 
change the profile

enforcing via spec is the wrong way to go here ... spec is for defining how 
the ebuilds work, not for forcing policy down peoples throats
-mike

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Daniel Ostrow]

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

<snip>

> > > Er, no, I'm explaining why enforcing src_test for EAPI 1 will be
> > > helpful for an awful lot of Gentoo developers.
> > 
> > except that you back the tree into a corner that it cannot come out of
> 
> Huh? Not at all. If a package can't use its test suite, the ebuild can
> set RESTRICT=test.
> 
> > > Please refrain from that kind of comment. It doesn't help anyone.
> > 
> > the answer is the same: talk to the QA team to get the tree into a
> > state where having src_test enabled by default is feasible and then
> > the QA team can change the profile
> 
> That isn't going to happen any time soon. There are too many changes
> and the impact of turning it on is too high. A gradual migration via
> EAPI is much safer and much more useful.
> 
> > enforcing via spec is the wrong way to go here ... spec is for
> > defining how the ebuilds work, not for forcing policy down peoples
> > throats
> 
> And whether or not src_test is called is part of how ebuilds work.
> Policy is whether or not src_test is required to do something in all
> situations, or whether it can be RESTRICTed out as necessary.

</snip>

First off...wow...long time since I've been active...so if anyone wants
to discount my comments based on that alone feel free. I'm trying to get
back in the game and I think a few e-mails as participation might be
best...hopefully you'll actually see me online soon.

Now on to the real topic at hand. For src_test I see things this way.

1). Even though src_test is not mandatory in the here and now any
package that provides a test suite that fails said tests has a bug. It
may not be a critical bug but it is in fact a bug.

2). The proper fix, again in the here and now, for said bug is either to
a). fix the test suite or b). add a RESTRICT="test" to the ebuild. Since
sec_test is not mandatory however these things happen rarely if at all.

With the above in mind I entirely agree that adding it as a mandatory
phase for EAPI=1 makes sense. Think of it this way:

1). Developer A is bumping a package and is including some new
functionality in his ebuilds that require something in EAPI=1, say for
example a SLOT dependency. As such Developer A is already editing the
ebuild *and* testing it.

2). As part of his test he checks if the built in test suite works,
something he should be doing *anyway*. If it does great, if it doesn't
then he has two choices, as above, fix it or add a RESTRICT="test", at
*worst* adding 15 whole characters (16 if you include the extra carriage
return he will need to add) to his ebuild.

3). Developer A then marks his ebuild as EAPI=1 and off he goes on to
bigger and better things.

This will allow a whole slew of VERY useful information to be available:

1). The QA team can now query the tree for packages that have known bad
test suites simply by looking for ebuilds that have RESTRICT="test". As
it stands now this is impossible to accomplish.

2). Interested volunteers, both developer and user alike, who are
looking for ways to help out, can now be given a concrete list of known
test suites to go and fix, this improves the QA of the packages in the
tree.

3). The fact that a bug in the test suite exists is no longer hidden
from view.

4). Since the test suites are now mandatory end users can feel more
confident in the state of their installed software, this is no silver
bullet but it is a step in the right direction.

The *only* downside that I can see here is that by default the package
installation process gets a little longer. To get around this some
method of globally opting out of src_test should be provided to the end
user, however since it is an on by default feature someone at least has
*tried* the test suite.

Again, since src_test would only be turned on by default for ebuilds
marked EAPI=1, not globally for the whole tree, the only additional work
required of developers would be to actually run the test suite and
possibly fix a bug in one of two accepted ways. After all, the ebuild is
being touched *anyway*. As with all the phase changes under discussion
*no one* is talking about making a global tree change, src_test would
just be default for those ebuilds that have EAPI >= 1.

Just my 2 cents...

--Dan

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Daniel Ostrow]

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

<snip>
> The *only* downside that I can see here is that by default the package
> installation process gets a little longer. To get around this some
> method of globally opting out of src_test should be provided to the end
> user, however since it is an on by default feature someone at least has
> *tried* the test suite.
</snip>

More to the point a facility to opt out either on a per-package basis or
globally should be allowed. But that is an implementation detail not a
specification one. The spec should say that running src_test is default.
There is nothing in that statement that says that there shouldn't be a
way to  turn it off if the end user doesn't want it.

Take paludis for example, with SKIP_FUNCTIONS you can already do this
with a simple case statement, that however as I said is implementation
specific not a spec issue.

--Dan

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ferris McCormick]

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

On Fri, 2007-04-13 at 12:17 -0700, Daniel Ostrow wrote:
> <snip>
> 
> > > > Er, no, I'm explaining why enforcing src_test for EAPI 1 will be
> > > > helpful for an awful lot of Gentoo developers.
> > > 
> > > except that you back the tree into a corner that it cannot come out of
> > 
> > Huh? Not at all. If a package can't use its test suite, the ebuild can
> > set RESTRICT=test.
> > 
> > > > Please refrain from that kind of comment. It doesn't help anyone.
> > > 
> > > the answer is the same: talk to the QA team to get the tree into a
> > > state where having src_test enabled by default is feasible and then
> > > the QA team can change the profile
> > 
> > That isn't going to happen any time soon. There are too many changes
> > and the impact of turning it on is too high. A gradual migration via
> > EAPI is much safer and much more useful.
> > 
> > > enforcing via spec is the wrong way to go here ... spec is for
> > > defining how the ebuilds work, not for forcing policy down peoples
> > > throats
> > 
> > And whether or not src_test is called is part of how ebuilds work.
> > Policy is whether or not src_test is required to do something in all
> > situations, or whether it can be RESTRICTed out as necessary.
> 
> </snip>
> 
> First off...wow...long time since I've been active...so if anyone wants
> to discount my comments based on that alone feel free. I'm trying to get
> back in the game and I think a few e-mails as participation might be
> best...hopefully you'll actually see me online soon.
> 
> Now on to the real topic at hand. For src_test I see things this way.
> 

Welcome back to the real (Gentoo, that is) world. :)  Good summary of
the situation, I think (although I've snipped it since everyone's read
it once.)

--- snip ---

> Just my 2 cents...
> 
> --Dan

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


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Daniel Ostrow wrote:
> 1). Even though src_test is not mandatory in the here and now any
> package that provides a test suite that fails said tests has a bug. It
> may not be a critical bug but it is in fact a bug.
>
> 2). The proper fix, again in the here and now, for said bug is either to
> a). fix the test suite or b). add a RESTRICT="test" to the ebuild. Since
> sec_test is not mandatory however these things happen rarely if at all.
>
> With the above in mind I entirely agree that adding it as a mandatory
> phase for EAPI=1 makes sense. Think of it this way:
>
> 1). Developer A is bumping a package and is including some new
> functionality in his ebuilds that require something in EAPI=1, say for
> example a SLOT dependency. As such Developer A is already editing the
> ebuild *and* testing it.
>
> 2). As part of his test he checks if the built in test suite works,
> something he should be doing *anyway*. If it does great, if it doesn't
> then he has two choices, as above, fix it or add a RESTRICT="test", at
> *worst* adding 15 whole characters (16 if you include the extra carriage
> return he will need to add) to his ebuild.
>
> 3). Developer A then marks his ebuild as EAPI=1 and off he goes on to
> bigger and better things.
>
> This will allow a whole slew of VERY useful information to be available:
>
> 1). The QA team can now query the tree for packages that have known bad
> test suites simply by looking for ebuilds that have RESTRICT="test". As
> it stands now this is impossible to accomplish.
>
> 2). Interested volunteers, both developer and user alike, who are
> looking for ways to help out, can now be given a concrete list of known
> test suites to go and fix, this improves the QA of the packages in the
> tree.
>
> 3). The fact that a bug in the test suite exists is no longer hidden
> from view.
>
> 4). Since the test suites are now mandatory end users can feel more
> confident in the state of their installed software, this is no silver
> bullet but it is a step in the right direction.
>
> The *only* downside that I can see here is that by default the package
> installation process gets a little longer. To get around this some
> method of globally opting out of src_test should be provided to the end
> user, however since it is an on by default feature someone at least has
> *tried* the test suite.

so you've validated that the platform the developer testing the ebuild on 
works ... you know nothing about any other platform that Gentoo supports and 
in the end, the users continue to hit src_test failure after src_test failure 
which, after they quickly get tired of filing [duplicate] bugs, they realize 
they have no way at all of disabling the mandatory test ... RESTRICT is an 
ebuild variable, not a package manager variable

as you said yourself, it may not be a critical bug, but it's still a bug and 
users have no way of trivially bypassing it or even opting out of tests in 
the first place.  you may enjoy running src_test on every single machine of 
yours out there, but i certainly dont.

this is why implementing it via the profile FEATURES works ... users can still 
easily opt out and in case of some catastrofuck and we havent screwed 
ourselves into a corner by mixing policy with spec
-mike

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

[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Duncan]

Mike Frysinger <vapier@gentoo.org> posted
200704132301.41614.vapier@gentoo.org, excerpted below, on  Fri, 13 Apr
2007 23:01:40 -0400:

> they realize they have no way at all of disabling the mandatory test ...
> RESTRICT is an ebuild variable, not a package manager variable

> this is why implementing it via the profile FEATURES works ... users can
> still easily opt out and in case of some catastrofuck and we havent
> screwed ourselves into a corner by mixing policy with spec

Why not keep the feature but simply default it to ON instead of OFF?  
That's what I had assumed all along, and in fact seems to have been what 
was proposed since in several places the argument was that devs would be 
testing it anyway, thus implying the option remains NOT to test it.

As I've said a couple times now, however, adding FEATURES=bigtest would 
IMO be useful, then let the ebuild use that for extra resource intensive 
tests or the like.  Default would be FEATURES="test -bigtest", thus 
advancing the default QA for everyone, while continuing to allow users to 
opt-in/out entirely if desired.

As for non-maintainer archs, the maintainer would test it on his arch, 
and arch-teams would test it on theirs before keywording stable.  Those 
(like myself) running ~arch on non-maintainer archs should be prepared to 
live with the consequences of that choice anyway, including the 
occasional test failure on their arch because the maintainer didn't test 
it there and the arch-team hasn't gotten to it yet.

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Matthias Langer]

> > > The arch teams have been pushing for this for a long time. They're
> > > trying to get this enforced, but are having limited success because
> > > there's no way for FEATURES=test to become widely used that won't
> > > lead to broken user systems. Moving src_test to be always on in
> > > future EAPIs is an easy way of helping arch teams achieve this goal
> > > without breaking anyone's system in the meantime.
> > 

Hmm, as an arch tester, i completely agree that packages where src_test
fails are an annoyance. However, I would not suggest to activate
src_test by default, as for normal users, it just introduces another
source of potential defects, without that much benefits. Instead, i
think that arch teams should refuse to stable packages that fail with
FEATURES=test and thus encourage ebuild developers to either fix their
tests, or to deactivate them explicitly.

Matthias

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Steve Long]

Matthias Langer wrote:
> Hmm, as an arch tester, i completely agree that packages where src_test
> fails are an annoyance. However, I would not suggest to activate
> src_test by default, as for normal users, it just introduces another
> source of potential defects, without that much benefits. Instead, i
> think that arch teams should refuse to stable packages that fail with
> FEATURES=test and thus encourage ebuild developers to either fix their
> tests, or to deactivate them explicitly.
> 
That makes a lot of sense. How about exending it a tiny bit and asking for
it to be policy for all ebuilds EAPI=1 not to be allowed into stable
without RESTRICT=test, or a functional test suite on the arch in question?
The last bit would be automagically checked by the arch team, if the ebuild
has no RESTRICT=test, during normal stabilisation (I'd hope?) since the
build would fail.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Petteri Räty]

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

Steve Long kirjoitti:
>
> That makes a lot of sense. How about exending it a tiny bit and asking for
> it to be policy for all ebuilds EAPI=1 not to be allowed into stable
> without RESTRICT=test, or a functional test suite on the arch in question?
> The last bit would be automagically checked by the arch team, if the ebuild
> has no RESTRICT=test, during normal stabilisation (I'd hope?) since the
> build would fail.
> 

And this is different from the current policy in what way?

Regards,
Petteri



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

Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Matthias Langer]

On Sat, 2007-04-14 at 14:58 +0300, Petteri Räty wrote: 
> Steve Long kirjoitti:
> >
> > That makes a lot of sense. How about exending it a tiny bit and asking for
> > it to be policy for all ebuilds EAPI=1 not to be allowed into stable
> > without RESTRICT=test, or a functional test suite on the arch in question?
> > The last bit would be automagically checked by the arch team, if the ebuild
> > has no RESTRICT=test, during normal stabilisation (I'd hope?) since the
> > build would fail.
> > 
> 
> And this is different from the current policy in what way?

Hmm, i don't want to offend anyone, i don't even want to say that it was
wrong to push these to stable regarding the current situation, but what,
for example, about these?

bug 165085
bug 133002
bug 156572




-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Saturday 14 April 2007, Matthias Langer wrote:
> bug 165085

i'd do some research into the glibc situation before you go pointing at it
-mike

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Joshua Jackson]

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



>
> The arch teams have been pushing for this for a long time. They're
> trying to get this enforced, but are having limited success because
> there's no way for FEATURES=test to become widely used that won't lead
> to broken user systems. Moving src_test to be always on in future EAPIs
> is an easy way of helping arch teams achieve this goal without breaking
> anyone's system in the meantime.
>
>   

Erm, no I have not at all (speaking as a project lead for x86). Test is
not viable for a lot of reason as being on by default. One that I can
come up with off the top of my head is php. The test suite for it makes
test inadvisable on any desktop system, I'd say the same for a server as
well. Not to mention that a lot of upstream test functions are in fact
themselves broken because they require dependencies that are not
required for the application itself. This is not a simple case of
downstream (being gentoo) doing this. There has to be quite a bit
changed for test to be viable and even then I don't think it really is
unfortunately due to test packages that can take 12+ hours on a decently
equipped modern system.


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 11:16:14 -0700
Joshua Jackson <tsunam@gentoo.org> wrote:
> Erm, no I have not at all (speaking as a project lead for x86). Test
> is not viable for a lot of reason as being on by default. One that I
> can come up with off the top of my head is php. The test suite for it
> makes test inadvisable on any desktop system, I'd say the same for a
> server as well. Not to mention that a lot of upstream test functions
> are in fact themselves broken because they require dependencies that
> are not required for the application itself. This is not a simple
> case of downstream (being gentoo) doing this. There has to be quite a
> bit changed for test to be viable and even then I don't think it
> really is unfortunately due to test packages that can take 12+ hours
> on a decently equipped modern system.

If a test suite isn't viable, the ebuild should be RESTRICTing test
anyway.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Ciaran McCreesh wrote:
> Joshua Jackson <tsunam@gentoo.org> wrote:
> > Erm, no I have not at all (speaking as a project lead for x86). Test
> > is not viable for a lot of reason as being on by default. One that I
> > can come up with off the top of my head is php. The test suite for it
> > makes test inadvisable on any desktop system, I'd say the same for a
> > server as well. Not to mention that a lot of upstream test functions
> > are in fact themselves broken because they require dependencies that
> > are not required for the application itself. This is not a simple
> > case of downstream (being gentoo) doing this. There has to be quite a
> > bit changed for test to be viable and even then I don't think it
> > really is unfortunately due to test packages that can take 12+ hours
> > on a decently equipped modern system.
>
> If a test suite isn't viable, the ebuild should be RESTRICTing test
> anyway.

which doesnt apply here ... some packages have ridiculous awesome coverage for 
their source code and take much longer to run than even compile the package

care to force mysql test suites on everyone ?  php ?  gcc ?  binutils ?
-mike

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 15:06:44 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> > If a test suite isn't viable, the ebuild should be RESTRICTing test
> > anyway.
> 
> which doesnt apply here ... some packages have ridiculous awesome
> coverage for their source code and take much longer to run than even
> compile the package
> 
> care to force mysql test suites on everyone ?  php ?  gcc ?
> binutils ?

A separate solution is needed for those anyway, since there're plenty
of people running with FEATURES=test.

-- 
Ciaran McCreesh


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

[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Duncan]

Ciaran McCreesh <ciaranm@ciaranm.org> posted
20070413203309.7df28d50@snowflake, excerpted below, on  Fri, 13 Apr 2007
20:33:09 +0100:

> On Fri, 13 Apr 2007 15:06:44 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
>> > If a test suite isn't viable, the ebuild should be RESTRICTing test
>> > anyway.
>> 
>> which doesnt apply here ... some packages have ridiculous awesome
>> coverage for their source code and take much longer to run than even
>> compile the package
>> 
>> care to force mysql test suites on everyone ?  php ?  gcc ? binutils ?
> 
> A separate solution is needed for those anyway, since there're plenty of
> people running with FEATURES=test.

FEATURES=bigtest ??

Interesting idea.  Then default test to on and bigtest to off, with 
appropriate user descriptions and developer guidelines for when use of 
"bigtest" is appropriate (extra deps, long runtime, etc.).

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Robin H. Johnson]

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

On Fri, Apr 13, 2007 at 03:06:44PM -0400, Mike Frysinger wrote:
> which doesnt apply here ... some packages have ridiculous awesome coverage for 
> their source code and take much longer to run than even compile the package
Furthermore, there are packages with testcases where if you want them,
you basically need to build in a specific way, and then rebuild again
for the version that you install (or build twice during src_compile in
the first place).

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

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Luca Barbato]

Ciaran McCreesh wrote:
> 
> If a test suite isn't viable, the ebuild should be RESTRICTing test
> anyway.
> 

That means ALL the media applications, almost all the toolchain
applications, most languages and a couple of other items I don't touch.

I don't think it shoud be part of the spec even if you don't have test
broken on delivery.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 21:29:29 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > If a test suite isn't viable, the ebuild should be RESTRICTing test
> > anyway.
> 
> That means ALL the media applications, almost all the toolchain
> applications, most languages and a couple of other items I don't
> touch.

What, you're saying they all ship with test suites that exist but don't
work?

> I don't think it shoud be part of the spec even if you don't have test
> broken on delivery.

src_test is already part of the spec, and ebuilds are supposed to
either support it or RESTRICT it. I'm just proposing that EAPI 1 be a
lot stricter about it...

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Luca Barbato]

Ciaran McCreesh wrote:
> What, you're saying they all ship with test suites that exist but don't
> work?

anything that takes more than 10m to test is broken from an user point
of view: you want the application, not having it tested.

I'd rather keep it in features since tests are _optional_, not necessary
to use the applications, just a waste of user time if they aren't
concerned (e.g.: nobody but some would care about ffmpeg failing to do
bit exact decoding of an ${fringe codec} nobody but who is developing it
uses, and surely will be angry at me not being able to get those 20%
speed improvements on h264).

> 
>> I don't think it shoud be part of the spec even if you don't have test
>> broken on delivery.
> 
> src_test is already part of the spec, and ebuilds are supposed to
> either support it or RESTRICT it. I'm just proposing that EAPI 1 be a
> lot stricter about it...
> 

Adding more build time, requirements (yes, there are some tests that
needs more ram and cpu to complete than the actual build phase) w/out
ways to opt out is just hindering our users.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Christopher Sawtell]

On Saturday 14 April 2007 18:14:48 Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > What, you're saying they all ship with test suites that exist but don't
> > work?
>
> anything that takes more than 10m to test is broken from an user point
> of view: you want the application,
Indeed, but speaking as a user, one wants the application to build and work, 
that is after all the whole point of installing a package.

> not having it tested.
That all depends. If having it tested means that it _will_ work, I'd be 
infavour of that. However I do appreciate that having every user's install 
repeating tests which have been done thousands of times before is probably 
un-neccessary.

How abouot setting the _default_ for test flags to true for '~' builds and 
false for supposedly stable builds?


[ all good stuff ]

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Luca Barbato]

Christopher Sawtell wrote:
> Indeed, but speaking as a user, one wants the application to build and work, 
> that is after all the whole point of installing a package.

If you have it on the tree it is supposed to work or at least have
passed a round of tests on the developer system, so you don't want a
round of test run before installing it.

> 
>> not having it tested.
> That all depends. If having it tested means that it _will_ work, I'd be 
> infavour of that. However I do appreciate that having every user's install 
> repeating tests which have been done thousands of times before is probably 
> un-neccessary.

having no way to opt out src_test at user level means that depending on
the system you:

- spend quite a lot of time to merge certain applications

- got the application fail to merge because the tests fails because it
is broken or has requirements completely unrelated to the application or
the usage you planned for it

- force me do more unnecessary work restricting and unrestricting tests
on the ebuild level.

> 
> How about setting the _default_ for test flags to true for '~' builds and 
> false for supposedly stable builds?

you can do that FEATURES="test", that is the current situation, that
works as should =P

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Matthias Langer]

> > not having it tested.
> That all depends. If having it tested means that it _will_ work, I'd be 
> infavour of that. 

Well, the problem is, that a working test suite does not guarantee a
working program, as well as a failing test suite doesn't necessarily
mean that the program is broken. This doesn't mean that test suites
aren't useful (i tend to write lot's of unit tests when I'm programming
myself), but I would say that they are targeted at developers, both up-
and downstream, not at end users.  

Thus, considering all arguments i've seen so far, i would highly
appreciate it, if various src_test functions in the tree see some love,
maybe encouraged due a changed policy, but i don't think that package
managers should enable test suites by default. If you want some test
action, try sys-devel/autoconf with tests activated with the package
manager of your choice ;-)

Matthias

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Duncan]

Luca Barbato <lu_zero@gentoo.org> posted 46207158.3070103@gentoo.org,
excerpted below, on  Sat, 14 Apr 2007 08:14:48 +0200:

> Adding more build time, requirements (yes, there are some tests that
> needs more ram and cpu to complete than the actual build phase) w/out
> ways to opt out is just hindering our users.

Tell me about it.  We (I'm involved upstream) had a bug in pan that 
required ~1.3 gig of memory to compile one of the tests... IF one was 
using gcc-3.4.x AND >= -O2.  I /think/ it was eventually resolved by 
turning off optimization for compiling the tests (not sure as gcc-3.x is 
not commonly used any more and I didn't follow the bug to full 
resolution), but it hit several users, including some Gentoo users back 
before gcc-4.x went stable, which we were able to help.

That said, I don't believe /anyone/ is proposing doing something so un-
Gentoo-like as not giving the user ways to opt-out.  From my read, 
FEATURES=test would simply be the default, with individual ebuilds able 
to opt-out via restrict, and individual users being able to opt-out by 
simply setting the feature off, just as the opt-in by simply setting it 
on, now.

I like the idea in general, tho I'd like to see something like 
FEATURES=bigtest implemented for the biggest/longest/most-resource-
intensive/extra-dependencies tests.  The extra granularity would give 
users a no-hassle way to enable tests on most packages, without forcing 
the huge tests on folks that weren't prepared for them, OR forcing 
maintainers to turn off (restrict) tests altogether in such cases.  
Restrict=test could then be reserved for those that are known to be 
broken, regardless of the resources thrown at them.

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Jakub Moc]

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

Mike Frysinger napsal(a):
>>>> * Remove automatic directory making for do*
>>> No
>> It masks all kinds of programming screwups. doblah should make a blah,
>> not make a blah and possibly make a directory.
> 
> name one
> 
> you're proposing we suddenly bloat all of our src_install functions for no 
> gain at all ... sounds like a no brainer to me

+1, this is a horrible idea that would just cause loads of bugs
impossible to check for in advance, major work for lots of people and
major bloat for no good reason. Bleh. :/


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 17:36:33 +0200
Jakub Moc <jakub@gentoo.org> wrote:
> Mike Frysinger napsal(a):
> >>>> * Remove automatic directory making for do*
> >>> No
> >> It masks all kinds of programming screwups. doblah should make a
> >> blah, not make a blah and possibly make a directory.
> > 
> > name one
> > 
> > you're proposing we suddenly bloat all of our src_install functions
> > for no gain at all ... sounds like a no brainer to me
> 
> +1, this is a horrible idea that would just cause loads of bugs
> impossible to check for in advance

What? No it wouldn't. It would ensure that bugs were caught during the
src_install phase rather than after a package has been installed.

>, major work for lots of people

Again, no.

> and major bloat for no good reason.

What? No it wouldn't. Very few things rely upon the automatic directory
creation behaviour. We know this because we have Paludis warning us
when it's used...

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Jakub Moc]

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

Ciaran McCreesh napsal(a):
> What? No it wouldn't. It would ensure that bugs were caught during the
> src_install phase rather than after a package has been installed.

What kind of bugs exactly? The ones *created* by this behavior change?
I'd rather not create such bugs for starters, because it's plain pointless.

If the Makefiles suck, file bugs upstream instead of dumping the stuff
on Gentoo users. People are already pretty much overloaded by the tons
of various QA checks all over the place...


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 18:22:24 +0200
Jakub Moc <jakub@gentoo.org> wrote:
> Ciaran McCreesh napsal(a):
> > What? No it wouldn't. It would ensure that bugs were caught during
> > the src_install phase rather than after a package has been
> > installed.
> 
> What kind of bugs exactly? The ones *created* by this behavior change?
> I'd rather not create such bugs for starters, because it's plain
> pointless.

You're missing the point.

As of a year or so ago, dosym will succeed even if the dosym target
directory doesn't exist, and even if it means creating arbitrary
directories. Some other utilities, such as dohard for example, will
fail under otherwise identical circumstances.

There is nothing in dosym's name that suggests that it will create a
directory as well as a symlink -- it is not like, for example, dobin or
dosbin in this respect, both of which clearly are allowed to create a
well defined, non-variable path.

If anyone really *is* relying upon dosym to create a directory, rather
than having it happen by accident, adding in a dodir beforehand when
switching EAPIs is easy, and will prevent accidental directory creation.

> If the Makefiles suck, file bugs upstream instead of dumping the stuff
> on Gentoo users.

It's not the users that will see this. It's developers. The only time
it will fail for users and not developers is when something's broken
anyway, and that's far better than ending up with a broken install.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Jakub Moc]

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

Ciaran McCreesh napsal(a):
> You're missing the point.
> 
> As of a year or so ago, dosym will succeed even if the dosym target
> directory doesn't exist, and even if it means creating arbitrary
> directories. Some other utilities, such as dohard for example, will
> fail under otherwise identical circumstances.
> 
> There is nothing in dosym's name that suggests that it will create a
> directory as well as a symlink -- it is not like, for example, dobin or
> dosbin in this respect, both of which clearly are allowed to create a
> well defined, non-variable path.

Err, your suggestion was:

* Remove automatic directory making for do*

So, yeah I really fail to see the point of doing stuff like this:

-dobin foo
+dodir /usr/bin
+dobin foo

or

-exeinto /usr/share/${PN}/scripts
-doexe scripts/*
+exeinto /usr/share/${PN}/scripts
+dodir /usr/share/${PN}/scripts
+doexe scripts/*

all over the tree.

> If anyone really *is* relying upon dosym to create a directory, rather
> than having it happen by accident, adding in a dodir beforehand when
> switching EAPIs is easy, and will prevent accidental directory creation.

And who will wade through the entire tree and check for such stuff? You?

>> If the Makefiles suck, file bugs upstream instead of dumping the stuff
>> on Gentoo users.
> 
> It's not the users that will see this. It's developers. The only time
> it will fail for users and not developers is when something's broken
> anyway, and that's far better than ending up with a broken install.

Well of course it's the users who will see it, see above. It's not like
that we would have 100 volunteers around to drop everything they have in
their hands a go spend days on changing ebuilds that are not broken just
because of this idea.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Petteri Räty]

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

Jakub Moc kirjoitti:
> 
> Well of course it's the users who will see it, see above. It's not like
> that we would have 100 volunteers around to drop everything they have in
> their hands a go spend days on changing ebuilds that are not broken just
> because of this idea.
> 
> 

We are talking about EAPI=1 so it's not magically going to change
anything for current ebuilds. EAPI=1 should also change do* functions to
die on failure so at best the ebuilds would die when the directory is
not created and maintainers who commit stuff with trying to emerge them
first shouldn't be devs in the first place. Not that it would mean that
having to add dodir's for everything is a good idea.

Regards,
Petteri


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 19:06:42 +0200
Jakub Moc <jakub@gentoo.org> wrote:
> Err, your suggestion was:
> 
> * Remove automatic directory making for do*

Because I was giving a one line summary, rather than a description of
the full change. The full description has been discussed elsewhere
several times.

> So, yeah I really fail to see the point of doing stuff like this:
> 
> -dobin foo
> +dodir /usr/bin
> +dobin foo

Which was not what was being discussed.

> > If anyone really *is* relying upon dosym to create a directory,
> > rather than having it happen by accident, adding in a dodir
> > beforehand when switching EAPIs is easy, and will prevent
> > accidental directory creation.
> 
> And who will wade through the entire tree and check for such stuff?
> You?

Uh. What. There's no need to do that. That's the whole point of
sticking it in at an EAPI change.

When people switch an ebuild's EAPI, they test it. That's required
anyway because EAPI changes various behaviour options. Ebuilds whose
EAPI isn't switched aren't affected.

> >> If the Makefiles suck, file bugs upstream instead of dumping the
> >> stuff on Gentoo users.
> > 
> > It's not the users that will see this. It's developers. The only
> > time it will fail for users and not developers is when something's
> > broken anyway, and that's far better than ending up with a broken
> > install.
> 
> Well of course it's the users who will see it, see above. It's not
> like that we would have 100 volunteers around to drop everything they
> have in their hands a go spend days on changing ebuilds that are not
> broken just because of this idea.

Explain in more detail how users will see it please.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Marius Mauch]

On Fri, 13 Apr 2007 18:18:27 +0100
Ciaran McCreesh <ciaranm@ciaranm.org> wrote:

> On Fri, 13 Apr 2007 19:06:42 +0200
> Jakub Moc <jakub@gentoo.org> wrote:
> > Err, your suggestion was:
> > 
> > * Remove automatic directory making for do*
> 
> Because I was giving a one line summary, rather than a description of
> the full change. The full description has been discussed elsewhere
> several times.

I don't remember any discussion about this, so a more specific pointer
would be appreciated.

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Sat, 14 Apr 2007 00:02:29 +0200
Marius Mauch <genone@gentoo.org> wrote:
> > Because I was giving a one line summary, rather than a description
> > of the full change. The full description has been discussed
> > elsewhere several times.
> 
> I don't remember any discussion about this, so a more specific pointer
> would be appreciated.

For do*, the suggestion was to remove automatic directory creation for
utilities where the directory to be made isn't clear and static based
upon the utility name. In practice, this means removing it from dosym,
not adding it to dohard, and cleaning up doins in some unspecified
manner.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Ciaran McCreesh wrote:
> On Sat, 14 Apr 2007 00:02:29 +0200
>
> Marius Mauch <genone@gentoo.org> wrote:
> > > Because I was giving a one line summary, rather than a description
> > > of the full change. The full description has been discussed
> > > elsewhere several times.
> >
> > I don't remember any discussion about this, so a more specific pointer
> > would be appreciated.
>
> For do*, the suggestion was to remove automatic directory creation for
> utilities where the directory to be made isn't clear and static based
> upon the utility name. In practice, this means removing it from dosym,
> not adding it to dohard, and cleaning up doins in some unspecified
> manner.

dohard has been fixed to match the behavior of all the other do* bins
-mike

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Alec Warner]

Ciaran McCreesh wrote:
>>> * src_test always called except if RESTRICT=test
>> I don't think this would fit into EAPI, to me it's an implementation
>> detail of the package manager, or why should the ebuild care about it?
> 
> It's the best way of ensuring that ebuilds have a working src_test.
> Arch teams need this.
> 

Any arch team that wants tests by default on their arch can just add 
test to FEATURES in their arch profiles; magically the users running 
that arch will get the tests run (with USE=test set) by default.  Users 
who don't want tests can always turn them off in make.conf.

So I struggle to grasp why this must be mandated via EAPI, since the 
arches who want testing could just turn it on.

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Jakub Moc]

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

Alec Warner napsal(a):
> Any arch team that wants tests by default on their arch can just add
> test to FEATURES in their arch profiles; magically the users running
> that arch will get the tests run (with USE=test set) by default.  Users
> who don't want tests can always turn them off in make.conf.

Even such change would piss off users. Having *no* way to turn off
tests, uuuhhh please retire me *before* someone implements this, I'm not
going to waste my time on totally pointless bugs filed by furious users.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Jan Kundrát]

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

Jakub Moc wrote:
> Alec Warner napsal(a):
>> Any arch team that wants tests by default on their arch can just add
>> test to FEATURES in their arch profiles; magically the users running
>> that arch will get the tests run (with USE=test set) by default.  Users
>> who don't want tests can always turn them off in make.conf.
> 
> Even such change would piss off users. Having *no* way to turn off
> tests, uuuhhh please retire me *before* someone implements this, I'm not
> going to waste my time on totally pointless bugs filed by furious users.

FEATURES="-test"?

-jkt

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


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Jakub Moc]

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

Jan Kundrát napsal(a):
> Jakub Moc wrote:
>> Even such change would piss off users. Having *no* way to turn off
>> tests, uuuhhh please retire me *before* someone implements this, I'm not
>> going to waste my time on totally pointless bugs filed by furious users.
> 
> FEATURES="-test"?

... wouldn't do anything, because the suggestion was that src_test()
should be mandatory in EAPI=1 and would run by default unless you have
RESTRICT="test" set in ebuild.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Sat, 14 Apr 2007 02:44:31 -0700
Alec Warner <antarus@gentoo.org> wrote:
> Any arch team that wants tests by default on their arch can just add 
> test to FEATURES in their arch profiles; magically the users running 
> that arch will get the tests run (with USE=test set) by default.
> Users who don't want tests can always turn them off in make.conf.
> 
> So I struggle to grasp why this must be mandated via EAPI, since the 
> arches who want testing could just turn it on.

And for at least the third time...

That can't be done because there are too many EAPI 0 packages that will
fail, which leads to user confusion. But bringing it in for EAPI 1
ensures a smooth gradual migration.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Alec Warner]

Ciaran McCreesh wrote:
> On Sat, 14 Apr 2007 02:44:31 -0700
> Alec Warner <antarus@gentoo.org> wrote:
>> Any arch team that wants tests by default on their arch can just add 
>> test to FEATURES in their arch profiles; magically the users running 
>> that arch will get the tests run (with USE=test set) by default.
>> Users who don't want tests can always turn them off in make.conf.
>>
>> So I struggle to grasp why this must be mandated via EAPI, since the 
>> arches who want testing could just turn it on.
> 
> And for at least the third time...
> 
> That can't be done because there are too many EAPI 0 packages that will
> fail, which leads to user confusion. But bringing it in for EAPI 1
> ensures a smooth gradual migration.
> 

Well we could implement this differently.  One could enable 
RESTRICT=test implicitly for EAPI=0, and drop it for EAPI=1.

At least there your making the change as apart of the ebuild's API and 
not as some random package manager implementation detail.  Everyone can 
turn tests on all they like; only ebuilds with EAPI=1 will get tested.

The whole argument against doing it the other way is that running tests, 
outside of RESTRICT, has absolutly nothing to do with any kind of api; 
which is why I'm against it.  At that point arch teams would essentially 
be hijacking EAPI for something it was never meant to cover.  We all 
know how bad that can be no?

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

Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Sat, 14 Apr 2007 12:17:24 -0700
Alec Warner <antarus@gentoo.org> wrote:
> The whole argument against doing it the other way is that running
> tests, outside of RESTRICT, has absolutly nothing to do with any kind
> of api; which is why I'm against it.  At that point arch teams would
> essentially be hijacking EAPI for something it was never meant to
> cover.  We all know how bad that can be no?

Ebuild functions are an EAPI issue. They address how ebuilds are used
by the package manager.

-- 
Ciaran McCreesh


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

src_fetch (was Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April))

[Marijn Schouten (hkBst)]

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

Ciaran McCreesh wrote:
> On Fri, 13 Apr 2007 14:21:16 +0200
> Marius Mauch <genone@gentoo.org> wrote:
>> On Wed, 11 Apr 2007 15:41:01 +0100
>> Ciaran McCreesh <ciaranm@ciaranm.org> wrote:

>>> * Phase changes: src_fetch -> src_unpack -> src_prepare ->
>>> src_configure -> src_compile -> src_test -> src_install
>> No to src_fetch
> 
> Why? It would be useful for CVS, SVN etc ebuilds. I'm not suggesting it
> be used for SRC_URI things.

Hi list,

Not having src_fetch is really braindead. There are always gonna be silly
packages that don't fit into the nice default SRC_URI scheme.

Use case one: package is completely unversioned upstream.
Have src_fetch add a version as appropriate to the downloaded/mirrored
version. This will work as change of upstream sources will be detected by all
the checksums we do.

Use case two: package is incompatibly versioned.
smlnj for example releases unversioned files in a versioned directory. There
is currently no way to mirror that in distfiles as there is nowhere that I
could specify that I want files to go to a separate directory.

Right. These use cases are really a bonus. Having src_fetch that we can
redefine is simply the right thing and I can't believe it doesn't exist already.

Consider this my vote for an EAPI 2 which adds user-redefinable src_fetch ASAP.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNJvRp/VmCx0OL2wRAnc9AJ0bIm1snoGivLSZgTEE4dx7e2VgQwCeL7Kk
fwvaBcfVHv+nSXQd1KTT3ls=
=44uf
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: src_fetch (was Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April))

[Ciaran McCreesh]

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

On Fri, 09 Nov 2007 18:41:38 +0100
"Marijn Schouten (hkBst)" <hkBst@gentoo.org> wrote:
> Use case one: package is completely unversioned upstream.
> Have src_fetch add a version as appropriate to the downloaded/mirrored
> version. This will work as change of upstream sources will be
> detected by all the checksums we do.

You're confusing multiple problems here. src_fetch *won't* work for
checksums. If we're talking merely badly named tarballs, a better
solution is SRC_URI arrow support.

> Use case two: package is incompatibly versioned.
> smlnj for example releases unversioned files in a versioned
> directory. There is currently no way to mirror that in distfiles as
> there is nowhere that I could specify that I want files to go to a
> separate directory.

Again, SRC_URI arrow support is a much better solution.

> Right. These use cases are really a bonus. Having src_fetch that we
> can redefine is simply the right thing and I can't believe it doesn't
> exist already.
> 
> Consider this my vote for an EAPI 2 which adds user-redefinable
> src_fetch ASAP.

src_fetch is necessary, yes, but it shouldn't be used in the cases you
describe. Arrows solve the same problem, don't break mirroring (if
implemented correctly) and don't break checksumming.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 15:24:25 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
> > Brian Harring <ferringb@gmail.com> wrote:
> >> 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.
> > 
> > Well, EAPI 1 needs to be delivered quickly...
> 
> Why exactly does EAPI=1 need to be rushed?

Because the tree needed the functionality in question several years ago.

> I thought the whole point of 0 was allowing a base, so that new stuff
> could be developed while guaranteeing certain behaviour. What's the
> hurry? It's not like there are systems b0rking or anything because
> EAPI=1 isn't around;

Except there are. Hence why we want EAPI 1 in the short term, not
several years from now. The stuff that will take longer can go into a
later EAPI.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Ciaran McCreesh wrote:
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > Ciaran McCreesh wrote:
> > > Brian Harring <ferringb@gmail.com> wrote:
> > >> 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.
> > >
> > > Well, EAPI 1 needs to be delivered quickly...
> >
> > Why exactly does EAPI=1 need to be rushed?
>
> Because the tree needed the functionality in question several years ago.
>
> > I thought the whole point of 0 was allowing a base, so that new stuff
> > could be developed while guaranteeing certain behaviour. What's the
> > hurry? It's not like there are systems b0rking or anything because
> > EAPI=1 isn't around;
>
> Except there are. Hence why we want EAPI 1 in the short term, not
> several years from now. The stuff that will take longer can go into a
> later EAPI.

this is really up to the portage team to drive
-mike

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

Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 11:11:07 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> > Except there are. Hence why we want EAPI 1 in the short term, not
> > several years from now. The stuff that will take longer can go into
> > a later EAPI.
> 
> this is really up to the portage team to drive

If they instead decide that EAPI 1 is a long term goal, will the
Council intervene?

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Mike Frysinger]

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

On Friday 13 April 2007, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> wrote:
> > > Except there are. Hence why we want EAPI 1 in the short term, not
> > > several years from now. The stuff that will take longer can go into
> > > a later EAPI.
> >
> > this is really up to the portage team to drive
>
> If they instead decide that EAPI 1 is a long term goal, will the
> Council intervene?

the Council, as always, will act as it deems necessary
-mike

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

[gentoo-dev] Re: Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Steve Long]

Ciaran McCreesh wrote:
>> Why exactly does EAPI=1 need to be rushed?
> 
> Because the tree needed the functionality in question several years ago.
> 
>> I thought the whole point of 0 was allowing a base, so that new stuff
>> could be developed while guaranteeing certain behaviour. What's the
>> hurry? It's not like there are systems b0rking or anything because
>> EAPI=1 isn't around;
> 
> Except there are. Hence why we want EAPI 1 in the short term, not
> several years from now. The stuff that will take longer can go into a
> later EAPI.
> 
Man here we go again: I spend a lot of time helping and being helped by
other gentoo users. *There has been no significant system b0rkage for
nearly a year* *QA is getting better not worse* and *the gentoo development
process works*

You may have your issues with the gentoo dev team, but spreading this kinda
FUD is outta line imo.

3 months for specification of EAPI 1 after a year for EAPI 0 is not exactly
moving slowly. And there are clearly other viewpoints as to what is needed.
Personally speaking, I'd like to find out what those are, as it's both
instructive for me, and better for the distro I use.

If there really are problems with *portage* those are not your concern:
Paludis users presumably don't get that kinda b0rkage so all you need to do
is /wait/ and let the technical superiority of your product win the
argument.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Ciaran McCreesh]

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

On Fri, 13 Apr 2007 18:17:32 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > Except there are. Hence why we want EAPI 1 in the short term, not
> > several years from now. The stuff that will take longer can go into
> > a later EAPI.
> > 
> Man here we go again: I spend a lot of time helping and being helped
> by other gentoo users. *There has been no significant system b0rkage
> for nearly a year* *QA is getting better not worse* and *the gentoo
> development process works*
> 
> You may have your issues with the gentoo dev team, but spreading this
> kinda FUD is outta line imo.

You don't know what QA problems EAPI 1 will solve, do you? It's not FUD
at all.

> 3 months for specification of EAPI 1 after a year for EAPI 0 is not
> exactly moving slowly. And there are clearly other viewpoints as to
> what is needed. Personally speaking, I'd like to find out what those
> are, as it's both instructive for me, and better for the distro I use.

We're not talking specification. We're talking implementation time.
Many of the things likely to be in EAPI 1 were needed years ago, and
the tree has huge problems as a result. The simplest example is the KDE
and Qt dependency hell that's come about as a result of not having slot
deps.

> If there really are problems with *portage* those are not your
> concern: Paludis users presumably don't get that kinda b0rkage so all
> you need to do is /wait/ and let the technical superiority of your
> product win the argument.

*Of course* Paludis users will get the same b0rkage that Portage users
do, since it's using the same ebuilds. Please refrain from contributing
if you don't understand the issues at hand.

-- 
Ciaran McCreesh


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

[gentoo-dev] FUD post 3,023,972 from ciaranm spills into ad-hominem. Never!

[Steve Long]

There is no "company" behind dotProject. 
 
Instead you are dealing with a dedicated but 100% volunteer group who give
their time and energy freely and frequently above and beyond the call of
duty. 
The development team behind, under, in front of and frequently buried by
dotProject are a great bunch of people. Kind, considerate, thoughtful,
experienced, hard working and capable of immensely generous acts. 
They can also be opinionated, dogmatic, stubborn, or whatever else they want
to be. We don't care, this is a great bunch of people and all dotProject
users owe them a vote of thanks and maybe a beer when they run into them in
the pub :)

s/dotProject/gentoo/ and grow the fu, like i asked ya to in #paludis ;)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] FUD post 3,023,972 from ciaranm spills into ad-hominem. Never!

[Charlie Shepherd]

On 14/04/07, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> ...


Can I ask why you choose to enlighten the mailing list with your views
on this matter?
I was given to understand it was a *development* mailing list, not a
"talk trash about someone 'cuz they banned me from their channel"
mailing list.

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

Re: [gentoo-dev] FUD post 3,023,972 from ciaranm spills into ad-hominem. Never!

[Ciaran McCreesh]

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

On Sat, 14 Apr 2007 08:43:39 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> There is no "company" behind dotProject. 

What on earth are you on about? Please stop posting uninformed nonsense
to the list. The noise is getting in the way of sensible discussion.

-- 
Ciaran McCreesh


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

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: Re: Monthly Gentoo Council Reminder for April

[Steve Long]

Paul de Vrieze wrote:
> 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.
> 
Having them on the web would definitely do that, as well as being a great
resource for new devs.


-- 
gentoo-dev@gentoo.org mailing list

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

[Bryan Østergaard]

On Wed, Apr 04, 2007 at 01:51:56AM -0400, Mike Frysinger wrote:
> some topics off the top of my head:
>  - unaddressed CoC issues:
> 	- add a "mission" statement
> 	- fix wording to have a positive spin
> 	- what else ?
We need quite a few more people on the CoC team. One reason being that
we want to be sure to cover more timezzones and different cultures.
Other reason being to make sure it's not just an old boys club where
everybody on the team sees things exactly the same way which could
easily undermine any consensus based decisions.
>  - sync Social Contract with Gentoo Foundation statement (external entities)
>  - documentation for mail servers still pending i believe (SPF / reply-to)
Kingtaco or robbat2 said they would commit that documentation a good
while ago iirc.
>  - PMS:
> 	- status update from spb
> 	- moving it to Gentoo svn
> 	- schedule for getting remaining issues settled
>  - splitting gentoo-dev mailing lists ?
> -mike

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

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

[Wernfried Haas]

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

Since i tried to get things running for the last week or two, i need
to throw in my 2 cents here.

On Wed, Apr 04, 2007 at 10:18:17AM +0200, Bryan Østergaard wrote:
> On Wed, Apr 04, 2007 at 01:51:56AM -0400, Mike Frysinger wrote:
> > some topics off the top of my head:
> >  - unaddressed CoC issues:
> > 	- add a "mission" statement

++, also some other docs stuff.

> > 	- fix wording to have a positive spin

Sounds like a good idea.

Since i first read about this here on the dev list:
Please, if you want to get stuff done, at least cc:
proctors@gentoo.org so they have a chance to do so.

> > 	- what else ?
> We need quite a few more people on the CoC team. One reason being that
> we want to be sure to cover more timezzones and different cultures.

I fully agree. So far two people have been added, who were suggested
by me and added after a given timeframe had passed with no complaints.
Still, this is not enough yet i think.

> Other reason being to make sure it's not just an old boys club where
> everybody on the team sees things exactly the same way which could
> easily undermine any consensus based decisions.

Which is the reason i didn't bring in more people myself, but am still
waiting for others to suggest someone. :-P

Other than that, i already expected this to be a topic at the next
council meeting and there is a list of things that should be done by
then.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

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

[Mike Frysinger]

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

On Wednesday 04 April 2007, Wernfried Haas wrote:
> Since i tried to get things running for the last week or two, i need
> to throw in my 2 cents here.
>
> On Wed, Apr 04, 2007 at 10:18:17AM +0200, Bryan Østergaard wrote:
> > On Wed, Apr 04, 2007 at 01:51:56AM -0400, Mike Frysinger wrote:
> > >  - unaddressed CoC issues:
> > > 	- add a "mission" statement
>
> ++, also some other docs stuff.
> <snip>
> Other than that, i already expected this to be a topic at the next
> council meeting and there is a list of things that should be done by
> then.

rather than hinting at stuff, can we make sure all issues expect to have 
discussed actually enumerated ?  vagueness in the past has forced us to 
simply punt topics to the next meeting :/
-mike

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

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

[Wernfried Haas]

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

On Wed, Apr 04, 2007 at 05:55:56AM -0400, Mike Frysinger wrote:
> On Wednesday 04 April 2007, Wernfried Haas wrote:
> > Since i tried to get things running for the last week or two, i need
> > to throw in my 2 cents here.
> >
> > On Wed, Apr 04, 2007 at 10:18:17AM +0200, Bryan Østergaard wrote:
> > > On Wed, Apr 04, 2007 at 01:51:56AM -0400, Mike Frysinger wrote:
> > > >  - unaddressed CoC issues:
> > > > 	- add a "mission" statement
> >
> > ++, also some other docs stuff.
> > <snip>
> > Other than that, i already expected this to be a topic at the next
> > council meeting and there is a list of things that should be done by
> > then.
> 
> rather than hinting at stuff, can we make sure all issues expect to have 
> discussed actually enumerated ?  

I'm not sure if i understand your question correctly, so sorry if my
answer has nothing to with your question.

I compiled a list of things that i think need to be done such as
defining some general guidelines for work, setting up a project page,
recruiting people, etc. Since none of the council people watching over
the work complained, i think we're on the right track, but if there's
something missing or you have a list of issues that need to be
addressed, please give me a copy to merge it with mine.
If you want to be involved more closely or need more info, just poke
me on irc.

> vagueness in the past has forced us to 
> simply punt topics to the next meeting :/

I'm a bit sucked up by real life atm, but i definitely want to (and
most likely will) to get work done until the next meeting.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

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

[Mike Frysinger]

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

On Wednesday 04 April 2007, Wernfried Haas wrote:
> I compiled a list of things that i think need to be done such as
> defining some general guidelines for work, <snip>

sorry, due to the thread (things for Council to talk about), i thought the 
work you were talking about was stuff for the Council to discuss ... that 
seems to not be the case
-mike

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

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

[Wernfried Haas]

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

On Wed, Apr 04, 2007 at 12:27:09PM -0400, Mike Frysinger wrote:
> sorry, due to the thread (things for Council to talk about), i thought the 
> work you were talking about was stuff for the Council to discuss ... that 
> seems to not be the case

Ah, sorry about that. As you said, right now there is nothing on my
mind that needs to be actually discussed by the council.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

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

[Ciaran McCreesh]

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

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?

-- 
Ciaran McCreesh


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

[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

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

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

[Alexandre Buisse]

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

On Sun, Apr  1, 2007 at 12:32:06 +0200, Mike Frysinger wrote:

> This is your monthly friendly reminder !  Same bat time (typically
> the 2nd Thursday at 2000 UTC / 1500 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.

Hi,

I won't take this to the council myself, but I think this should be
discussed at the very least: we need a way to limit the council power,
since it seems there is nothing to this effect in the metastructure
glep. I think that when members of the council, who have total control
on gentoo, say things like "I don't feel we should listen to what the
dev community thinks", then one should begin to worry.

Concretely, I suggest that a reasonable way is created to appeal council
decisions. Of course, one should make sure that this won't led to
systematic appeals that would only make people lose time (something like
"20% of devs must have agreed to this before any vote takes place", or
so).

If enough people are interested, I'm sure someone will step up to
present this to the council, and if not, well, it will just have been
another lost email on this list.

Regards,
/Alexandre

PS: sorry to post this with my g.o address, I haven't resubscribed with
another address yet.
-- 
Hi, I'm a .signature virus! Please copy me in your ~/.signature.

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

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

[Donnie Berkholz]

Alexandre Buisse wrote:
> I won't take this to the council myself, but I think this should be
> discussed at the very least: we need a way to limit the council power,
> since it seems there is nothing to this effect in the metastructure
> glep.

I'm not going to write an essay because I don't have the time, but I 
dislike this idea. We'll just get everything wrapped up in red tape 
again like devrel was, and who do you appeal to when you (in the plural) 
decided to put this group of people in charge in the first place? This 
isn't a three-branch government and I don't think it should be.

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

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

[Grant Goodyear]

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

Alexandre Buisse wrote: [Wed Apr 04 2007, 02:36:43PM CDT]
> I won't take this to the council myself, but I think this should be
> discussed at the very least: we need a way to limit the council power,
> since it seems there is nothing to this effect in the metastructure
> glep. 

For what it's worth, I deliberately wrote the GLEP that way.  The
truth of the matter is that the Council has only whatever power the
devs permit, so adding additional restrictions seems like a really bad
idea to me.

> I think that when members of the council, who have total control
> on gentoo, say things like "I don't feel we should listen to what the
> dev community thinks", then one should begin to worry.

Someone actually said that?

In any event, Gentoo is a community project.  If you can convince
enough of the community that you're right, and the Council is wrong,
then the Council is extremely likely to listen.  If they don't, vote
out the bums.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

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

[Matti Bickel]

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

Grant Goodyear <g2boojum@gentoo.org> wrote:
> For what it's worth, I deliberately wrote the GLEP that way.  The
> truth of the matter is that the Council has only whatever power the
> devs permit, so adding additional restrictions seems like a really bad
> idea to me.

grant++
Seriously, if enough devs can agree that the council's wrong, the
council can say all they like, in the end it's the community that has to
implement changes. If there's uproar about councils decisions, i'm sure
we'd find a way to let them know in a way they can't ignore :)

In general, please give the guys some credit, please give the community
some credit. We're not powerless, we'll never be.
-- 
Regards, Matti Bickel
Homepage: http://www.rateu.de
Encrypted/Signed Email preferred

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

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

[Alexandre Buisse]

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

On Wed, Apr  4, 2007 at 22:27:45 +0200, Grant Goodyear wrote:

> Alexandre Buisse wrote: [Wed Apr 04 2007, 02:36:43PM CDT]
> > I won't take this to the council myself, but I think this should be
> > discussed at the very least: we need a way to limit the council power,
> > since it seems there is nothing to this effect in the metastructure
> > glep. 
> 
> For what it's worth, I deliberately wrote the GLEP that way.  The
> truth of the matter is that the Council has only whatever power the
> devs permit, so adding additional restrictions seems like a really bad
> idea to me.

This is true as long as you don't have written rules on who is the boss
of what. Since the metastructure explicitly says "council is the boss of
everyone", I don't see why there shouldn't be an explicit "but if
council messes up, we can appeal and/or fire them". Most power systems,
if not all, do have this one way or another. Unlimited power is no good.

 
> > I think that when members of the council, who have total control
> > on gentoo, say things like "I don't feel we should listen to what the
> > dev community thinks", then one should begin to worry.
> 
> Someone actually said that?

Yes, on #gentoo-council iirc. I don't have logs at the moment so I can't
give you the reference, but it was during the CoC "discussion".
 

> In any event, Gentoo is a community project.  If you can convince
> enough of the community that you're right, and the Council is wrong,
> then the Council is extremely likely to listen.  If they don't, vote
> out the bums.

Well, the thing is, vote happens only once a year, and quite a lot of
things can be done during that time. I just think that not having any
rule at all concerning limitations to the council is tying our hands in
our back. If the council never messes up, then this rule won't ever be
used, and if they do, we'll be happy to have this handy rather than
having to argue for ages and being told "you elected us, so shut up
and if you don't agree, don't vote for us next time" (which is an
answer I actually got several times).

Now, this is all I have to say on the topic. I resigned from gentoo and,
to be perfectly honest, I don't really care one way or another since I'm
not involved anymore, but I felt that this should at least be said,
since it's in my opinion a major flaw of the current metastructure.

Regards,
/Alexandre
-- 
Hi, I'm a .signature virus! Please copy me in your ~/.signature.

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

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

[Denis Dupeyron]

On 4/5/07, Alexandre Buisse <nattfodd@gentoo.org> wrote:
> Well, the thing is, vote happens only once a year, and quite a lot of
> things can be done during that time. I just think that not having any
> rule at all concerning limitations to the council is tying our hands in
> our back. If the council never messes up, then this rule won't ever be
> used, and if they do, we'll be happy to have this handy rather than
> having to argue for ages and being told "you elected us, so shut up
> and if you don't agree, don't vote for us next time" (which is an
> answer I actually got several times).

Why not simply allow trustees to veto a council decision ? This does
not give trustees enough power to be a second council, but would
permit them to stop something that they believe will damage Gentoo.
This is very little red tape IMHO.

If it's only stupid and not harmful it will be solved naturally with
the current structure by waiting for the next elections (either at the
end of the term or because enough council members resigned due to the
situation).

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

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

[Seemant Kulleen]

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

On Thu, 2007-04-05 at 13:29 +0200, Denis Dupeyron wrote:
> Why not simply allow trustees to veto a council decision ? This does
> not give trustees enough power to be a second council, but would
> permit them to stop something that they believe will damage Gentoo.
> This is very little red tape IMHO.

I believe that the trustees do not necessarily have any jurisdiction
over the council.  They are concerned with legal type matters that
affect the foundation, not with technical and political things within
Gentoo itself.  I could be wrong about this, but that's how I read it.

Thanks,

Seemant



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

[Chris Gianelloni]

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

On Thu, 2007-04-05 at 08:19 -0400, Seemant Kulleen wrote:
> On Thu, 2007-04-05 at 13:29 +0200, Denis Dupeyron wrote:
> > Why not simply allow trustees to veto a council decision ? This does
> > not give trustees enough power to be a second council, but would
> > permit them to stop something that they believe will damage Gentoo.
> > This is very little red tape IMHO.
> 
> I believe that the trustees do not necessarily have any jurisdiction
> over the council.  They are concerned with legal type matters that
> affect the foundation, not with technical and political things within
> Gentoo itself.  I could be wrong about this, but that's how I read it.

Correct.  Currently, the Council (or anyone, really) would have to do
something to endanger our copyrights, trademarks, or our legal standing
for the trustees to do anything.

-- 
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] Monthly Gentoo Council Reminder for April

[Paul de Vrieze]

Seemant Kulleen wrote:
> On Thu, 2007-04-05 at 13:29 +0200, Denis Dupeyron wrote:
>> Why not simply allow trustees to veto a council decision ? This does
>> not give trustees enough power to be a second council, but would
>> permit them to stop something that they believe will damage Gentoo.
>> This is very little red tape IMHO.
> 
> I believe that the trustees do not necessarily have any jurisdiction
> over the council.  They are concerned with legal type matters that
> affect the foundation, not with technical and political things within
> Gentoo itself.  I could be wrong about this, but that's how I read it.

Actually much of the hardware that supports gentoo is owned by or lend 
to the foundation. The trustees have legal control over that (while 
infrastructure has technical control), so if it comes to a pissing 
context, the foundation would probably win. It is not a situation anyone 
would want to get into. There is no other formal relationship between 
the foundation and the council.

Paul
(Gentoo dev/trustee)
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Thu, 2007-04-05 at 13:29 +0200, Denis Dupeyron wrote:
> On 4/5/07, Alexandre Buisse <nattfodd@gentoo.org> wrote:
> > Well, the thing is, vote happens only once a year, and quite a lot of
> > things can be done during that time. I just think that not having any
> > rule at all concerning limitations to the council is tying our hands in
> > our back. If the council never messes up, then this rule won't ever be
> > used, and if they do, we'll be happy to have this handy rather than
> > having to argue for ages and being told "you elected us, so shut up
> > and if you don't agree, don't vote for us next time" (which is an
> > answer I actually got several times).
> 
> Why not simply allow trustees to veto a council decision ? This does
> not give trustees enough power to be a second council, but would
> permit them to stop something that they believe will damage Gentoo.

Actually, while it isn't spelled out, this is likely the case, since the
trustees (and the Foundation members, by extension) are the holders of
the Gentoo name.  The Foundation is what grants the Council its power by
"allowing" Gentoo (Linux) to govern itself.

Trust me, if the Council were doing something nasty and underhanded that
would endanger Gentoo, the trustees would try to do *something* to
prevent it.  That being said, I don't think that anybody is out to try
to harm Gentoo.  We (the Council) understand that we cannot appease
everybody all the time and don't make any apologies for not being able
to do so.

> This is very little red tape IMHO.

That being said, the Trustees really don't have "jurisdiction" over the
Council's technical decisions or their decisions on how to actually run
Gentoo.  This is a power the trustees could have, but it isn't one they
necessarily *do* have.  I have no idea if they would even want it and my
opinion doesn't matter a whole lot, since I would be in conflict of
interest in pretty much any decision.

> If it's only stupid and not harmful it will be solved naturally with
> the current structure by waiting for the next elections (either at the
> end of the term or because enough council members resigned due to the
> situation).

There's a huge difference between the Council doing something against
Gentoo and the Council doing something certain people don't agree with.
The former is completely intolerable while the latter is very likely to
happen with any decision the Council makes.  Some people will always
spout off conspiracy theories and their opinions on how they think
things should be, which is all fine and dandy except that it isn't how
things *are* currently.  If someone wants something changed, they can
very well work to get it changed.  Trying to force the Council to do
something via underhanded tactics or baseless accusations doesn't do
much.  Getting the community together does.

If the community decided that the Council is only allowed to hold
meetings on Thursday when the moon is full, we'd abide by it.

I just find this whole situation hysterical since you have so many
people saying the Council needs to "grow a pair" and actually try to
enact some good, and when we do, you hear a few vocal individuals
running around screaming like we killed their kitten.  So which is it?
Would you rather have a strong Council that is capable of making
decisions without having to worry about whether that decision is popular
or not, or would you rather have a weak Council that cannot do anything
without prior developer approval, completely castrating their abilities
to enact change for fear of being removed from office?

-- 
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] Monthly Gentoo Council Reminder for April

[Denis Dupeyron]

On 4/5/07, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> I just find this whole situation hysterical since you have so many
> people saying the Council needs to "grow a pair" and actually try to
> enact some good, and when we do, you hear a few vocal individuals
> running around screaming like we killed their kitten.  So which is it?

Why would the council need to "grow a pair" when it already has
SpanKY's ;o) I only proposed the veto thing because I felt that it
could be a good compromise to reassure those devs who fall for the
conspiracy theories, so that they feel safe and get back to work. I
never believed the council would realistically do something that would
harm Gentoo. I'm sorry for the confusion if any.

> Would you rather have a strong Council that is capable of making
> decisions without having to worry about whether that decision is popular
> or not, or would you rather have a weak Council that cannot do anything
> without prior developer approval, completely castrating their abilities
> to enact change for fear of being removed from office?

Agreed, here. There was one vote last summer when we collectively
decided that the current council members were the best for the job.
And that's all we need until next summer. I have been reading
carefully a lot of emails and irclogs for some time, especially during
the recent events, and I must say that I'm very pleased with the way
things went, and how people (of the council and devrel mainly)
interacted. While I'm not 100% satisfied with the outcome, which may
be a sure sign the right decisions were made, I certainly won't
complain.

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

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

[Ciaran McCreesh]

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

On Wed, 4 Apr 2007 15:17:18 -0500
Grant Goodyear <g2boojum@gentoo.org> wrote:
> Alexandre Buisse wrote: [Wed Apr 04 2007, 02:36:43PM CDT]
> > I won't take this to the council myself, but I think this should be
> > discussed at the very least: we need a way to limit the council
> > power, since it seems there is nothing to this effect in the
> > metastructure glep. 
> 
> For what it's worth, I deliberately wrote the GLEP that way.  The
> truth of the matter is that the Council has only whatever power the
> devs permit, so adding additional restrictions seems like a really bad
> idea to me.

Right.

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?

-- 
Ciaran McCreesh


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

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

[Wernfried Haas]

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

On Thu, Apr 05, 2007 at 09:26:41AM +0100, 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?

If they want to have sekrit meetings with sekrit handshakes, let
them. If enough people think this is not acceptable, they'll be gone
on the next election.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

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

[Christopher Sawtell]

On Fri, 06 Apr 2007 00:09:12 Wernfried Haas wrote:
> On Thu, Apr 05, 2007 at 09:26:41AM +0100, 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?
>
> If they want to have sekrit meetings with sekrit handshakes, let
> them. If enough people think this is not acceptable, they'll be gone
> on the next election.

If Gentoo goes all political and ties itself up in  hundreds of rules, 
regulations, and miles of the proverbial red tape it will cease to be 
effective, and become a fork target to be effectively taken over by 
somebody or other with superiour people and technical skills.

Don't the names Debian, Shuttleworth, and Ubuntu ring bells?

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

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

[Ciaran McCreesh]

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

On Thu, 5 Apr 2007 14:09:12 +0200
Wernfried Haas <amne@gentoo.org> wrote:
> On Thu, Apr 05, 2007 at 09:26:41AM +0100, 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?
> 
> If they want to have sekrit meetings with sekrit handshakes, let
> them. If enough people think this is not acceptable, they'll be gone
> on the next election.

Which is all very well, but it's kind of hard to evaluate the
effectiveness of Council members and the Council as a whole if they're
doing things behind everyone's backs and making horrible threats to try
to prevent people from publishing logs of their goings on...

I mean, what're people supposed to think from the likes of these?

Kugelfang> there have been, at that time, 6 council members plus one
    non council members in that channel
...
Kugelfang> ciaranm: and that's all i'll say regarding that, until the
    rest allows me to speak about the contents of that meeting
...
Kugelfang> i really wish i could publish this thing

and:

wolf31o2|mobile> we're entrusted by certain outside parties to not
    disclose things that are spoken to us in confidence

tove> wolf31o2|mobile: how are outside parties involved in "our" coc? i
    don't understand this. can you please elaborate on it?

wolf31o2|mobile> tove: no, I cannot elaborate, nor do I care to... just
    realize that Gentoo has responsibilities to outside parties that
    provide services and goods to Gentoo... we have relationships that
    we would like to maintain... and that's about all I can say (or
    have time to say... I am at work)

I mean, when it's reached the point where certain Council members are
threatening to pull each others' access if anyone goes public with
whatever it was that was discussed, *something* has to be done... The
details can remain private if necessary, but publishing a brief summary
along the lines of "we discussed x and y and decided z" *has* to be
less harmful than the current mess where people are deleting their work
and considering resignation because of whatever it is the Council are
up to...

-- 
Ciaran McCreesh


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

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

[Matti Bickel]

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

Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> > If they want to have sekrit meetings with sekrit handshakes, let
> > them. If enough people think this is not acceptable, they'll be gone
> > on the next election.
> 
> Which is all very well, but it's kind of hard to evaluate the
> effectiveness of Council members and the Council as a whole if they're
> doing things behind everyone's backs and making horrible threats to try
> to prevent people from publishing logs of their goings on...

Please evaluate the council's effectivness based on their achievements.
And no, secret meetings don't count towards that.

Seriously, i understand that the council should be as transparent as
possible, but there are issues that need some confidential handling.

> threatening to pull each others' access if anyone goes public with
> whatever it was that was discussed, *something* has to be done...

Um, that's hard to say without the thing in the open. I just trust the
involved parties to have enough insight to bring anything that would
harm gentoo to public scrunity (and following outcry).

> The details can remain private if necessary, but publishing a brief
> summary along the lines of "we discussed x and y and decided z" *has*

Um, wait. Council *decisions*, as long as they're affecting gentoo's
ways, must be out in the open. We won't end up with National Security
Letters to infra or something (and i trust there'll be an uproar, if it
ever reaches that point). Say, if the council decides to ice a project,
how can that be kept secret?
-- 
Regards, Matti Bickel
Homepage: http://www.rateu.de
Encrypted/Signed Email preferred

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

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

[Chris Gianelloni]

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

On Thu, 2007-04-05 at 14:51 +0100, Ciaran McCreesh wrote:
> details can remain private if necessary, but publishing a brief summary
> along the lines of "we discussed x and y and decided z" *has* to be
> less harmful than the current mess where people are deleting their work
> and considering resignation because of whatever it is the Council are
> up to...

Except we *did* do that when we first published what we'd done with the
CoC.  Just because ti didn't have a shiny "Meeting Summary" in the topic
doesn't mean it wasn't the outcome of the meeting.  You know the topic
of discussion.  You know the outcome.  The details are private.  Even
you admit that is fine.

I mean, all this "the Council is hiding something" conspiracy theory is
bullshit.  How about when I hang out with Mike Doty and we discuss
Gentoo stuff?  Is that some super-secret meeting where we're trying to
circumvent some supposed requirement for transparency?  Of course not...
If the individual members of the Council feel like getting together and
discussing something, we're perfectly free to do that.  We don't have to
tell you what we discussed.  We're allowed to bounce ideas off each
other, especially when discussing things said to us in confidence.  I
understand that some people disagree with this, but this is a simple
fact of life.  There are going to be cases where people will say
something to someone in confidence and not include everyone in on it.
There's nothing we can do about that and there is plenty of precedence
for it.  When someone asks me not to betray their trust, I won't.
That's just how I am.  If others feel that their knowing stuff that is
honestly insignificant in detail since the end result turned out to be
the same and done publicly, well, they're more than welcome to run for
Council, themselves, but if they were to divulge such information after
being privy to it, disciplinary action would *need* to be taken to
retain the trustworthiness of Gentoo as a whole.

Now, that being said, we *did* have a *public* meeting about our
discussion, and all *decisions* we made were 100% public.  I'm sorry if
anyone feels like they were slighted by not being included in the
discussions prior to the public meeting, but there's nothing anywhere
that says that we have to have all of our discussions in public or even
made publicly available.  We *do* have to have all of our decisions made
public, obviously.

Personally, I'd just assume make the thing public just to shut people
up, but I've really grown to have a stance where I'm less likely to give
in to this sort of pressure, since it will do nothing more but prove
that being a whiny bitch and trying to pressure people into doing
something will get people what they want.  I surely don't want to set
*that* precedent.

-- 
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] Monthly Gentoo Council Reminder for April

[Ciaran McCreesh]

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

On Thu, 05 Apr 2007 10:47:37 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> I mean, all this "the Council is hiding something" conspiracy theory
> is bullshit.

Then why are certain Council members, you included, threatening to
remove other Council members' and Gentoo developers' access if logs of
whatever it was that occurred are published? What could possibly have
been discussed related to the CoC that this level of threat is
necessary or appropriate? Why are certain Council members claiming that
if anyone disagrees with them they will soon not have a Gentoo email
address?

Honestly, the only reason there is any suggestion of a conspiracy is
because of the threats being made by certain people to keep a certain
log a secret...

-- 
Ciaran McCreesh


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

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

[Chris Gianelloni]

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

On Thu, 2007-04-05 at 16:00 +0100, Ciaran McCreesh wrote:
> Honestly, the only reason there is any suggestion of a conspiracy is
> because of the threats being made by certain people to keep a certain
> log a secret...

The log contains information that was given to us in confidence.  How
much plainer do I have to make it?  We can not, and WILL NOT break that
trust.  It really is that simple.

-- 
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] Monthly Gentoo Council Reminder for April

[Josh Saddler]

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

Chris Gianelloni wrote:
> On Thu, 2007-04-05 at 16:00 +0100, Ciaran McCreesh wrote:
>> Honestly, the only reason there is any suggestion of a conspiracy is
>> because of the threats being made by certain people to keep a certain
>> log a secret...
> 
> The log contains information that was given to us in confidence.  How
> much plainer do I have to make it?  We can not, and WILL NOT break that
> trust.  It really is that simple.

Here's how it appears to someone reading all this, though:

Ciaran *already knows* what's going on, which means that some person(s)
who *were* privy to those meetings have talked, plain and simple. If
that's true, then the information is out one way or another, and now the
Council can decide if they want to talk about it first or let someone
who wasn't actually at those meetings to divulge all the details.

I guess it comes down to the trust you expect the Gentoo developers who
voted for you in the first place to have in you against the trust the
council members have in each other. This isn't a matter of throwing
someone to the wolves, but consider the rest of the trust. :)



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

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

[Chris Gianelloni]

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

On Thu, 2007-04-05 at 09:04 -0700, Josh Saddler wrote:
> Chris Gianelloni wrote:
> > On Thu, 2007-04-05 at 16:00 +0100, Ciaran McCreesh wrote:
> >> Honestly, the only reason there is any suggestion of a conspiracy is
> >> because of the threats being made by certain people to keep a certain
> >> log a secret...
> > 
> > The log contains information that was given to us in confidence.  How
> > much plainer do I have to make it?  We can not, and WILL NOT break that
> > trust.  It really is that simple.
> 
> Here's how it appears to someone reading all this, though:
> 
> Ciaran *already knows* what's going on, which means that some person(s)
> who *were* privy to those meetings have talked, plain and simple. If
> that's true, then the information is out one way or another, and now the
> Council can decide if they want to talk about it first or let someone
> who wasn't actually at those meetings to divulge all the details.

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 guess it comes down to the trust you expect the Gentoo developers who
> voted for you in the first place to have in you against the trust the
> council members have in each other. This isn't a matter of throwing
> someone to the wolves, but consider the rest of the trust. :)

I'm not sure I follow what you're saying here.  Are you saying that
Gentoo developers would lose trust in us because we are keeping our word
to people who spoke to us in confidence?  Are you referring to a
potential leak?

As I said, I will not betray the trust put in me.  If someone says
something in confidence to me, it'll stay that way.  I cannot speak for
all of the other Council members, but I put the same level of trust in
them to do the same.  If one of them really has taken private
conversations and made them public, then we really do have a problem and
we need to address it, because that can severely damage Gentoo as a
whole very easily.  If nobody trusts us anymore, why will they support
us?  Simple.  They won't.

-- 
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] Monthly Gentoo Council Reminder for April

[Ciaran McCreesh]

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

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?

> I'm not sure I follow what you're saying here.  Are you saying that
> Gentoo developers would lose trust in us because we are keeping our
> word to people who spoke to us in confidence?  Are you referring to a
> potential leak?

There is nothing stopping you from posting a several paragraph summary
of whatever it was that was being discussed. Leave gaps for
confidential things as appropriate, but don't use it as an excuse for
burying the whole thing as you're trying to do here.

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

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] Monthly Gentoo Council Reminder for April

[Ciaran McCreesh]

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

On Thu, 05 Apr 2007 09:04:09 -0700
Josh Saddler <nightmorph@gentoo.org> wrote:
> Here's how it appears to someone reading all this, though:
> 
> Ciaran *already knows* what's going on, which means that some
> person(s) who *were* privy to those meetings have talked, plain and
> simple. If that's true, then the information is out one way or
> another, and now the Council can decide if they want to talk about it
> first or let someone who wasn't actually at those meetings to divulge
> all the details.

No, I don't know what's going on exactly -- I only have access to what
people have said in public, and even then I'm not watching most of the
IRC channels in which such things are usually said. What I do know:

I know that there's a log involving a conversation between four or five
Council members and one or two non-Council members that certain Council
members are trying extremely hard to keep secret.

I know that topics discussed in this log include the Code of Conduct
and Gentoo sponsors, including OSL, and that it goes far beyond a
private conversation.

I know that at least one Council member would rather that this log were
published.

I know that at kingtaco and wolf31o2 have made threats along the lines
of "if you screw us over we will remove your access", including to a
fellow Council member.

I know that at least one Gentoo developer is seriously considering
resigning because of what the Council have been doing on this, and that
several more have expressed extreme dissatisfaction at the way the
Council is handling things.

I know that the person responsible for the CoC is no longer involved
with it because of the Council's actions.

I know that at least one Council member has made claims to the effect
of "if we don't get our way with this, Gentoo will be dead within a
week", and that "you can disagree all you want, but you won't have an
@gentoo.org address if you do".

What I *don't* know is what the heck the Council has done to get Gentoo
into such a mess, if those claims are true. Or, if they're not, I don't
know how Council members can get away with making the kind of threats
they are making.

Now, to resolve this... Why don't the people involved get together and
publish a several paragraph summary of what was discussed? They can
agree to leave out anything that really is sensitive, but since the
majority of the log presumably isn't, it would be good to see a public
summary.

> I guess it comes down to the trust you expect the Gentoo developers
> who voted for you in the first place to have in you against the trust
> the council members have in each other. This isn't a matter of
> throwing someone to the wolves, but consider the rest of the trust. :)

It kind of stops becoming a matter of trust when Council members that
also have infra powers make threats about removing other Council
members' access...

-- 
Ciaran McCreesh


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

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

[Danny van Dyk]

Am Donnerstag, 5. April 2007 14:09 schrieb Wernfried Haas:
> If they want to have sekrit meetings with sekrit handshakes, let
> them. If enough people think this is not acceptable, they'll be gone
> on the next election.
Especially as there are council members who don't rely like any privacy 
in that at all. vapier comes to my mind there :-D

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

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

[Chris Gianelloni]

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

On Thu, 2007-04-05 at 22:15 +0200, Danny van Dyk wrote:
> Am Donnerstag, 5. April 2007 14:09 schrieb Wernfried Haas:
> > If they want to have sekrit meetings with sekrit handshakes, let
> > them. If enough people think this is not acceptable, they'll be gone
> > on the next election.
> Especially as there are council members who don't rely like any privacy 
> in that at all. vapier comes to my mind there :-D

I don't like it, either.  I understand that there are sometimes
requirements on keeping things private, but I'm all for doing everything
as publicly as possible.  It keeps complete wastes of time like this
current thread from cropping up as easily, for one.

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

[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] Monthly Gentoo Council Reminder for April

[Mike Frysinger]

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

On Thursday 05 April 2007, 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?

what exactly does this solve ?  nothing ?  we go from having meetings nobody 
knows about where discussions happen that no one sees to having meetings 
everyone knows about where discussions happen that no one sees ... the only 
thing that comes from this is now people have more things to refer to vaguely 
to support lame "hypothetical" sitautions

ive got a better idea Ciaran, stop spreading FUD ... i do believe we have 
something now that says purposefully spreading FUD is a no no
-mike

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

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

[Mike Frysinger]

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

On Sunday 01 April 2007, Mike Frysinger 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.

another one i had mentioned earlier:
 - a time frame on moving gentoo-core to public archives ... two years ?
-mike

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

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

[William L. Thomson Jr.]

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

On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote:
> On Sunday 01 April 2007, Mike Frysinger 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.
> 
> another one i had mentioned earlier:
>  - a time frame on moving gentoo-core to public archives ... two years ?

That's seems like a reasonable time frame. Any information would be
outdated at that time, and not have any effect over current issues.

-- 
William L. Thomson Jr.
Gentoo/Java

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

[Danny van Dyk]

Am Donnerstag, 5. April 2007 21:20 schrieb Mike Frysinger:
> On Sunday 01 April 2007, Mike Frysinger 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.
>
> another one i had mentioned earlier:
>  - a time frame on moving gentoo-core to public archives ... two
> years ? -mike
What happened to 1 year?

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

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

[Mike Frysinger]

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

On Thursday 05 April 2007, Danny van Dyk wrote:
> Am Donnerstag, 5. April 2007 21:20 schrieb Mike Frysinger:
> > On Sunday 01 April 2007, Mike Frysinger 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.
> >
> > another one i had mentioned earlier:
> >  - a time frame on moving gentoo-core to public archives ... two
> > years ?
>
> What happened to 1 year?

i'm fine with 1 week, but if people want to argue lower ...
-mike

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

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

[Ned Ludd]

On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote:
> On Sunday 01 April 2007, Mike Frysinger 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.
> 


> 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. There are things said on core 
that I do not wish to be public. I've sent mails myself that if they 
were ever going to be published publicly I would of never sent them.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Petteri Räty]

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

Ned Ludd kirjoitti:
> On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote:
>> On Sunday 01 April 2007, Mike Frysinger 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.
> 
> 
>> 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. There are things said on core 
> that I do not wish to be public. I've sent mails myself that if they 
> were ever going to be published publicly I would of never sent them.
> 

We don't have to decide to open up all the old archives but instead we
can decide that posts from now on will be made public after X amount of
time has passed.

Regards,
Petteri

--
Gentoo/Recruiters lead
Gentoo/Java lead


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

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

[Wernfried Haas]

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

On Thu, Apr 05, 2007 at 02:18:40PM -0700, Ned Ludd wrote:
> I object and hope this is never done. There are things said on core 
> that I do not wish to be public. I've sent mails myself that if they 
> were ever going to be published publicly I would of never sent them.

As far i remember the idea was only to make mails public from whenever
this applies, not the ones sent before. So you can still stop sending
your weekly goat pics once that happens. :-]

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

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

[Mike Frysinger]

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

On Thursday 05 April 2007, Wernfried Haas wrote:
> On Thu, Apr 05, 2007 at 02:18:40PM -0700, Ned Ludd wrote:
> > I object and hope this is never done. There are things said on core
> > that I do not wish to be public. I've sent mails myself that if they
> > were ever going to be published publicly I would of never sent them.
>
> As far i remember the idea was only to make mails public from whenever
> this applies, not the ones sent before. So you can still stop sending
> your weekly goat pics once that happens. :-]

i'd like both, but i'll take what i can get
-mike

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

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

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

[David Leverton]

2009/4/1 Mike Frysinger <vapier@gentoo.org>:
> 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 would like the Council to discuss the matter of Portage repeatedly
changing behaviour in ebuild-visible ways without an EAPI bump or even
an announcement that anything changed.  Notable examples include .lzma
support in unpack (bug 207193), the change in pkg_* phase ordering
(bug 222721) and the preservation of timestamps during merge (bug
264130).  It is quite frustrating to spend considerable effort
determining Portage's behaviour and matching it in Paludis, only to
find a few months later that Portage changed and now users are getting
broken packages if not broken systems because ebuilds are starting to
rely on the new rules.

(The /really/ hilarious part is that certain people then accuse /us/
of being "uncooperative" and "not caring about compatibility".)

This needs to be dealt with if Gentoo is ever going to take the idea
of PMS, or indeed EAPI itself, at all seriously.

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

[Ulrich Mueller]

>>>>> On , 01 Apr 2009, Mike Frysinger 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.

Since EAPI 3 is on the agenda already, I would ask the council to
consider inclusion of "mtime preservation" (see bug 264130, and the
thread "Preserving mtimes for EAPI3" in this ML).

The proposal comes in two variations (to be decided upon):
  a) "mtimes fixup" and preservation of mtimes when merging are both
     mandatory. (This would require changes in all package managers.)
  b) "mtimes fixup" is optional, preservation of mtimes is mandatory.
     (This wouldn't require any immediate changes in Portage and
     Pkgcore.)

Ulrich

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

[Fabian Groffen]

On 01-04-2009 05:30:01 +0000, Mike Frysinger 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 would like the council to discuss the addition of three variables to
EAPI3.

- EPREFIX
  The offset prefix of a Gentoo Prefix installation.  When Gentoo Prefix
  is not used, ${EPREFIX} should be "".
  This variable should be available everywhere.
- EROOT
  The offset prefix appended to ${ROOT}, e.g. ${ROOT%/}${EPREFIX}/
  This variable is available where ROOT is, following PMS: pkg_*
- ED
  The offset prefix appended to ${D}, e.g. ${D%/}${EPREFIX}/
  This variable is available where D is, following PMS: src_install

While the first variable (EPREFIX) can be set using an eclass, the
latter two need to be set by the package manager.  In particular ED,
because the value of D might not be known.  EROOT and ED are convenience
variables.  Making them available already now, even though initialised
as ROOT and D respectively, allows Prefix enabled ebuilds to be shared
between gentoo-x86 and Prefix trees without modifications.


-- 
Fabian Groffen
Gentoo on a different level

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

[Ciaran McCreesh]

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

On Thu, 2 Apr 2009 11:53:47 +0200
Fabian Groffen <grobian@gentoo.org> wrote:
> While the first variable (EPREFIX) can be set using an eclass, the
> latter two need to be set by the package manager.  In particular ED,
> because the value of D might not be known.  EROOT and ED are
> convenience variables.  Making them available already now, even
> though initialised as ROOT and D respectively, allows Prefix enabled
> ebuilds to be shared between gentoo-x86 and Prefix trees without
> modifications.

Why not just do it properly? Come up with a full list of requirements,
propose a full solution, open it up for feedback and adapt it as
necessary. Then just move the whole thing into a future EAPI.

My worry is we'll end up with more legacy mess that package managers
will have to carry on supporting indefinitely, but that won't be used
by anything once prefix goes through the necessary changes to make it
mainstream.

-- 
Ciaran McCreesh

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

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

[Fabian Groffen]

Ciaran,

On 02-04-2009 15:47:05 +0100, Ciaran McCreesh wrote:
> On Thu, 2 Apr 2009 11:53:47 +0200
> Fabian Groffen <grobian@gentoo.org> wrote:
>> While the first variable (EPREFIX) can be set using an eclass, the
>> latter two need to be set by the package manager.  In particular ED,
>> because the value of D might not be known.  EROOT and ED are
>> convenience variables.  Making them available already now, even
>> though initialised as ROOT and D respectively, allows Prefix enabled
>> ebuilds to be shared between gentoo-x86 and Prefix trees without
>> modifications.
>
> Why not just do it properly? Come up with a full list of requirements,
> propose a full solution, open it up for feedback and adapt it as
> necessary. Then just move the whole thing into a future EAPI.

Recently we changed our approach from being a new EAPI into blending
into any existing EAPI.  We can do this, since Prefix is orthogonal to
any existing EAPI to date.  The mentioned variables simply make life
easier, but are not strictly necessary.  Unfortunately we can't set them
from an eclass, so we need help from the package manager for them.

> My worry is we'll end up with more legacy mess that package managers
> will have to carry on supporting indefinitely, but that won't be used
> by anything once prefix goes through the necessary changes to make it
> mainstream.

Limiting Gentoo Prefix ebuilds to a future EAPI will not be acceptable
with regards to system packages and we will still have a crappy overlay
for a long multi-year period.  The fact is, Prefix ebuilds can be used
regardless of EAPI in use.  We used to do EAPI="prefix <#>" but that was
way too much maintance overhead and just recently EAPI=prefix has been
killed in favour of full compatability.

You seem to suggest there are issues, do you have any specific concerns
that we can address?


-- 
Fabian Groffen
Gentoo on a different level

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

[Ciaran McCreesh]

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

On Mon, 6 Apr 2009 19:24:41 +0200
Fabian Groffen <grobian@gentoo.org> wrote:
> You seem to suggest there are issues, do you have any specific
> concerns that we can address?

I've still not seen a full description of the problem you're trying to
solve with prefix. The last time we tried this there were a lot of
unanswered questions about your approach.

What you have for prefix is fine for a "playing around" project, but
unless you've moved on significantly from when we last discussed it,
there's a significant gap between what you have and what you've been
trying to do and what would be suitable or ideal for main tree use.

I think we'd all benefit from a proper discussion of goals and details
of how various problems will be solved before moving prefix to an
official EAPI.

-- 
Ciaran McCreesh

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

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

[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

[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

[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

[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

[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

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

[gentoo-dev] Monthly Gentoo Council Reminder for April

[Mike Frysinger]

This is your monthly friendly reminder !  Same bat time (typically the
2nd Thursday once a month), 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 *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@gentoo.org mailing list

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

[Mike Frysinger]

On Saturday 01 April 2006 04:22, Mike Frysinger wrote:
> This is your monthly friendly reminder !  Same bat time (typically the
> 2nd Thursday once a month), same bat channel (#gentoo-council @
> irc.freenode.net) !

due to LWE we're pushing it back to the 21st
-mike
-- 
gentoo-dev@gentoo.org mailing list