[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