[gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Grant Goodyear]

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

Over the years we've had a fairly consistent stream of suggestions that
we should open up the e-build maintaining process to users instead of
just devs.  The main arguments against it are the security issues and an
expectation that it would add to developer workloads.  The former is
certainly a real problem, although signing (assuming a reasonable
web-of-trust) could mitigate that some (at least we'd know who to
blame).  The latter, however, is conjecture, and the only good way to
verify it would be to actually try it and see what happens.  Oh, and
there's also a very real fear that if things go horribly wrong, that
Gentoo's reputation would suffer quite badly.  Perhaps I'm naive, but I
tend to think that if we were to advertise project sunrise as
experimental, temporary, use-at-your-own-risk, and
might-break-your-system, and even put it on hardware without a
gentoo.org address and add a portage hook that warns whenever the
project sunrise overlay is used, then our reputation isn't really likely
to suffer even if it's a complete disaster.

So, Chris, what have I failed to address that would make this a really
bad idea?

-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] A heretical thought? Blessing project sunrise as an almost-fork.

[foser]

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

On Tue, 2006-06-13 at 11:10 -0500, Grant Goodyear wrote:
> Over the years we've had a fairly consistent stream of suggestions that
> we should open up the e-build maintaining process to users instead of
> just devs.  The main arguments against it are the security issues and an
> expectation that it would add to developer workloads.  The former is
> certainly a real problem, although signing (assuming a reasonable
> web-of-trust) could mitigate that some (at least we'd know who to
> blame).  The latter, however, is conjecture, and the only good way to
> verify it would be to actually try it and see what happens.  Oh, and
> there's also a very real fear that if things go horribly wrong, that
> Gentoo's reputation would suffer quite badly.  Perhaps I'm naive, but I
> tend to think that if we were to advertise project sunrise as
> experimental, temporary, use-at-your-own-risk, and
> might-break-your-system, and even put it on hardware without a
> gentoo.org address and add a portage hook that warns whenever the
> project sunrise overlay is used, then our reputation isn't really likely
> to suffer even if it's a complete disaster.
> 
> So, Chris, what have I failed to address that would make this a really
> bad idea?

That this describes break-my-gentoo, that it is as old as Gentoo itself
and that it only creates problems for the 'supported' tree : the
unexplained bugs, the weird errors, the continuous suspicion devs need
to have on reported errors. Keep that stuff separated, don't mingle it
with Gentoo.

- foser

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

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Henrik Brix Andersen]

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

On Tue, Jun 13, 2006 at 11:10:47AM -0500, Grant Goodyear wrote:
> Over the years we've had a fairly consistent stream of suggestions that
> we should open up the e-build maintaining process to users instead of
> just devs.  The main arguments against it are the security issues and an
> expectation that it would add to developer workloads.  The former is
> certainly a real problem, although signing (assuming a reasonable
> web-of-trust) could mitigate that some (at least we'd know who to
> blame).  The latter, however, is conjecture, and the only good way to
> verify it would be to actually try it and see what happens.  Oh, and
> there's also a very real fear that if things go horribly wrong, that
> Gentoo's reputation would suffer quite badly.  Perhaps I'm naive, but I
> tend to think that if we were to advertise project sunrise as
> experimental, temporary, use-at-your-own-risk, and
> might-break-your-system, and even put it on hardware without a
> gentoo.org address and add a portage hook that warns whenever the
> project sunrise overlay is used, then our reputation isn't really likely
> to suffer even if it's a complete disaster.
> 
> So, Chris, what have I failed to address that would make this a really
> bad idea?

As I've said all along - I do not have any problems with Project
Sunrise. I have a problem with it being an official project hosted on
*.gentoo.org, as I fear most users will think "hey, it's official,
it's hosted on *.gentoo.org - it can't be that bad". Judging from the
few users who have posted to the previous threads on this subject, my
fear seems to be reasonable.

If the project was to be hosted on a non *.gentoo.org domain (I'll let
infra comment on whether or not non *.gentoo.org domains can be hosted
on infra hardware) my current issues with this project would be gone.

If the project proves to be healthy and not affect the reputation of
Gentoo in a bad way, we could consider adopting it as an official
project after a period of time.

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Henrik Brix Andersen]

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

On Tue, Jun 13, 2006 at 11:10:47AM -0500, Grant Goodyear wrote:
> Over the years we've had a fairly consistent stream of suggestions that
> we should open up the e-build maintaining process to users instead of
> just devs.  The main arguments against it are the security issues and an
> expectation that it would add to developer workloads.  The former is
> certainly a real problem, although signing (assuming a reasonable
> web-of-trust) could mitigate that some (at least we'd know who to
> blame).  The latter, however, is conjecture, and the only good way to
> verify it would be to actually try it and see what happens.  Oh, and
> there's also a very real fear that if things go horribly wrong, that
> Gentoo's reputation would suffer quite badly.  Perhaps I'm naive, but I
> tend to think that if we were to advertise project sunrise as
> experimental, temporary, use-at-your-own-risk, and
> might-break-your-system, and even put it on hardware without a
> gentoo.org address and add a portage hook that warns whenever the
> project sunrise overlay is used, then our reputation isn't really likely
> to suffer even if it's a complete disaster.
> 
> So, Chris, what have I failed to address that would make this a really
> bad idea?

As I've said all along - I do not have any problems with Project
Sunrise. I have a problem with it being an official project hosted on
*.gentoo.org, as I fear most users will think "hey, it's official,
it's hosted on *.gentoo.org - it can't be that bad". Judging from the
few users who have posted to the previous threads on this subject, my
fear seems to be reasonable.

If the project was to be hosted on a non *.gentoo.org domain (I'll let
infra comment on whether or not non *.gentoo.org domains can be hosted
on infra hardware) my current issues with this project would be gone.

If the project proves to be healthy and not affect the reputation of
Gentoo in a bad way, we could consider adopting it as an official
project after a period of time.

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Donnie Berkholz]

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

Henrik Brix Andersen wrote:
> As I've said all along - I do not have any problems with Project
> Sunrise. I have a problem with it being an official project hosted on
> *.gentoo.org, as I fear most users will think "hey, it's official,
> it's hosted on *.gentoo.org - it can't be that bad". Judging from the
> few users who have posted to the previous threads on this subject, my
> fear seems to be reasonable.

Do you also expect that once I'm able to move my overlay to
overlays.g.o, it will become this amazing beautiful thing that never has
any work-in-progress stuff in it that's incredibly broken? (I would love
if that were the case.) The same goes for any other personal or project
overlays there, as I doubt many users will distinguish between them.

Thanks,
Donnie


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

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Henrik Brix Andersen]

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

On Tue, Jun 13, 2006 at 10:06:56AM -0700, Donnie Berkholz wrote:
> Do you also expect that once I'm able to move my overlay to
> overlays.g.o, it will become this amazing beautiful thing that never has
> any work-in-progress stuff in it that's incredibly broken? (I would love
> if that were the case.) The same goes for any other personal or project
> overlays there, as I doubt many users will distinguish between them.

No, but I expect your overlay to mainly consist of ebuilds for
software you use, software you have bothered to actually examine -
perhaps even software you already maintain in-tree.

I don't expect your personal overlay to be a dumping ground for random
ebuilds which you personally have no interest in maintaining.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

[gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Peter]

On Tue, 13 Jun 2006 10:06:56 -0700, Donnie Berkholz wrote:

> Henrik Brix Andersen wrote:
>> As I've said all along - I do not have any problems with Project
>> Sunrise. I have a problem with it being an official project hosted on
>> *.gentoo.org, as I fear most users will think "hey, it's official, it's
>> hosted on *.gentoo.org - it can't be that bad". Judging from the few
>> users who have posted to the previous threads on this subject, my fear
>> seems to be reasonable.
> 
> Do you also expect that once I'm able to move my overlay to overlays.g.o,
> it will become this amazing beautiful thing that never has any
> work-in-progress stuff in it that's incredibly broken? (I would love if
> that were the case.) The same goes for any other personal or project
> overlays there, as I doubt many users will distinguish between them.
> 
> Thanks,
> Donnie

But, we're NOT just talking about borked and incomplete packages. We are
ALSO talking about good, normal, and useful packages which, for a variety
of reasons, just can't seem to make it to the main portage tree. This idea
that everything in sunrise is going to be uber-experimental, possibly bad,
and likely-to-break-your-machine, is overstating the case.

And, again, considering your user-community, a user MUST make a few
concrete action steps in order to open up [the Pandora's box that some
thing this is] Sunrise. No one will ever accidentally be able to download
a Sunrise hosted project without consciously choosing to do so.

As for where it is hosted, as a user. myop says, it should be on
.gentoo.org, and on .gentoo infra. Why? Because of the link to gentoo's
bugzilla. If there is going to be a relation between bugs on bz -> Sunrise
-> bz (and ultimately, maybe) -> main portage tree, then having o.g.o and
sunrise together makes a lot of sense. Otherwise, you end up confusing
matters even more.

While I realize there is a lot at stake, and probably some policy issues
and security issues that deserve discussion, I think that the degree of
doom some of you ascribe to this project is not worthy.

I think, should Sunrise get a green light, that it will turn out to be a
developer and prospective-developer playground and testing site largely
ignored by users. Any user who choose to use Sunrise will have a specific,
very specific need.

As an example, there is a kernel source build I've been playing with. I
know, from the kernel team, it will never, repeat NEVER, get onto the
portage tree. they want no part of it. However, the bug is widely
followed, and if Sunrise were to be a home to it, then these bug readers
would be able to continue to work on the project. Why should it just waste
away on bz? See bug # 103354 started by Scott Jones who did most of the
work on it. This kernel source is also tracked on the gentoo forums.

This kernel source will not cause Armageddon to arrive, cause smoke to
issue from your power supply, nor interfere with other ebuilds. 

I think it Sunrise belongs part of .gentoo.org, and it should be given a
probationary period, say 90 days, for review. I am sure tracking of
downloads, uploads, and problems can easily be done. I think portage can
also be reprogrammed to spit out warnings, even require a positive
acknowledgment, when requesting an overlay the first time. Something like:

YOU ARE REQUESTING AN OVERLAY EBUILD
There are inherent risks associated
with this action. Overlay ebuilds are
not official parts of the Gentoo main
tree, and as such, should be considered
experimental. Do you acknowledge this: (Yes).

If yes, then touch a file somewhere and the user won't be nagged again.

Am I being to simplistic or naive?

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Henrik Brix Andersen]

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

On Tue, Jun 13, 2006 at 01:29:55PM -0400, Peter wrote:
[snip]
> This kernel source will not cause Armageddon to arrive, cause smoke to
> issue from your power supply, nor interfere with other ebuilds. 

That's funny. Did you just claim that a sys-kernel/*-sources ebuild
with the patch-sets listed below would have no possibility of
interfering with other ebuilds? If so, you've just proven my point
that many users wont be able to judge how ebuilds from overlays may
affect the stable tree.

"Features
-ck(s) Con Kolivas Patchset, (server version available as option) -ide
libATA/ide updates, Alsa updates and fixes, Dothan Speedstep, Pentium M
undervolt, IBM ACPI fan control, Suspend2, vesafb-tng, reiser4, unionfs
squashfs, realtime-lsm, fbsplash, configurable mouse polling support,
custom dsdt, Layer7, various fixes and updates." [1]

> Am I being to simplistic or naive?

Both, it seems.

Regards,
Brix

[1]: http://bugs.gentoo.org/show_bug.cgi?id=103354#c51
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

[gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Peter]

On Tue, 13 Jun 2006 19:54:47 +0200, Henrik Brix Andersen wrote:

> On Tue, Jun 13, 2006 at 01:29:55PM -0400, Peter wrote: [snip]
>> This kernel source will not cause Armageddon to arrive, cause smoke to
>> issue from your power supply, nor interfere with other ebuilds.
> 
> That's funny. Did you just claim that a sys-kernel/*-sources ebuild with
> the patch-sets listed below would have no possibility of interfering with
> other ebuilds? If so, you've just proven my point that many users wont be
> able to judge how ebuilds from overlays may affect the stable tree.
> 

I did. Sources don't affect anything. The ck-sources are in the tree, and
there is dire warning associated with them. Only the -mm sources have any
sort of warning. If a user CHOOSES to use a hacked up kernel, then they
obviously choose to. Just like, if a user chooses to try out reiserfs-4,
they get what they pay for. Sources don't affect anything.


> "Features
> -ck(s) Con Kolivas Patchset, (server version available as option) -ide
> libATA/ide updates, Alsa updates and fixes, Dothan Speedstep, Pentium M
> undervolt, IBM ACPI fan control, Suspend2, vesafb-tng, reiser4, unionfs
> squashfs, realtime-lsm, fbsplash, configurable mouse polling support,
> custom dsdt, Layer7, various fixes and updates." [1]
> 
>> Am I being to simplistic or naive?
> 
> Both, it seems.
> 
> Regards,
> Brix
> 
> [1]: http://bugs.gentoo.org/show_bug.cgi?id=103354#c51

And I think these are worthwhile features. Some, actually are part of the
gentoo-base and gentoo-extra patches (see the excludes list). It also
includes spocks vesa-tng and fbsplash.

Look, you can't micro-control all aspects of a user's computing
experience. If someone downloads tmpwatch and mistakenly puts / in the
list of directories to prune, what will you do? Put tmpwatch into
package.mask because it MIGHT be misued? Or, will you package.mask
vixie.cron because someone may not be capable of writing a bash script?

Honestly, I do not see the difference, AND because the kernel is
experimental (or, at least I call it experimental), and widely followed, I
think Sunrise is ideal for it. JM2C.

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Henrik Brix Andersen]

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

On Tue, Jun 13, 2006 at 02:14:24PM -0400, Peter wrote:
> I did. Sources don't affect anything. The ck-sources are in the tree, and
> there is dire warning associated with them. Only the -mm sources have any
> sort of warning. If a user CHOOSES to use a hacked up kernel, then they
> obviously choose to. Just like, if a user chooses to try out reiserfs-4,
> they get what they pay for. Sources don't affect anything.

I rest my case.

./Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Grant Goodyear]

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

Henrik Brix Andersen wrote: [Tue Jun 13 2006, 01:30:27PM CDT]
> On Tue, Jun 13, 2006 at 02:14:24PM -0400, Peter wrote:
> > I did. Sources don't affect anything. The ck-sources are in the tree, and
> > there is dire warning associated with them. Only the -mm sources have any
> > sort of warning. If a user CHOOSES to use a hacked up kernel, then they
> > obviously choose to. Just like, if a user chooses to try out reiserfs-4,
> > they get what they pay for. Sources don't affect anything.
> 
> I rest my case.

Care to elaborate?  The wise, all-knowing Zen argument isn't
particularly helpful....

-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] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Henrik Brix Andersen]

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

On Tue, Jun 13, 2006 at 01:41:21PM -0500, Grant Goodyear wrote:
> Care to elaborate?  The wise, all-knowing Zen argument isn't
> particularly helpful....

All software runs on top of the core of the operating system, the
kernel. If the kernel is buggy it will be reflected in all the
software running on top of it, be it portage, compilers, daemons or
graphical user environments.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Grant Goodyear]

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

Henrik Brix Andersen wrote: [Tue Jun 13 2006, 01:52:18PM CDT]
> All software runs on top of the core of the operating system, the
> kernel. If the kernel is buggy it will be reflected in all the
> software running on top of it, be it portage, compilers, daemons or
> graphical user environments.

Oh, I'm sorry, I thought you were referring to the kernel in terms of
ebuild dependencies.  Isn't your reason why "emerge --info" lists the
kernel?  (Also, the kernel probably isn't the best example, since I
suspect that if there's any single package that people are likely to
install outside of portage, the kernel would be it.)

-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] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Ciaran McCreesh]

On Tue, 13 Jun 2006 13:41:21 -0500 Grant Goodyear <g2boojum@gentoo.org>
wrote:
| Henrik Brix Andersen wrote: [Tue Jun 13 2006, 01:30:27PM CDT]
| > On Tue, Jun 13, 2006 at 02:14:24PM -0400, Peter wrote:
| > > I did. Sources don't affect anything. The ck-sources are in the
| > > tree, and there is dire warning associated with them. Only the
| > > -mm sources have any sort of warning. If a user CHOOSES to use a
| > > hacked up kernel, then they obviously choose to. Just like, if a
| > > user chooses to try out reiserfs-4, they get what they pay for.
| > > Sources don't affect anything.
| > 
| > I rest my case.
| 
| Care to elaborate?  The wise, all-knowing Zen argument isn't
| particularly helpful....

It's perfect proof that there are users that are utterly clueless about
what is best for their system, and utterly clueless about how using
third party software can cause problems for other software.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Peter]

On Tue, 13 Jun 2006 20:17:10 +0100, Ciaran McCreesh wrote:
> | Care to elaborate?  The wise, all-knowing Zen argument isn't |
> particularly helpful....
> 
> It's perfect proof that there are users that are utterly clueless about
> what is best for their system, and utterly clueless about how using
> third party software can cause problems for other software.
> 
> 
It's no such proof. Anyone who rolls a kernel, takes the time to learn
what it entails, understands what he/she is intending to do, knows the
ramifications of those actions. Gentoo users, in particular, by virtue of
the fact that this is a source-based distro, have to be accorded a
slightly higher level of respect and regard.

And, I certainly do not think that you, 4000+ miles away have any idea
what may or may not be best for mine or anyone else's system. That kind of
presumptuous attitude does not help anyone. Any user can hose their
system, whether you are using genkernel, gensources-2.6.16-r?, vanilla
sources, or Stalin-incarnated-sources-666.666.666. 

Why don't you hose all potentially harmful ebuilds from bugzilla then? Why
leave them up for people to download? Why does the kernel team that was
assigned the beyond-sources bug not just nuke it? Why don't you remove
bash, since someone might do rm /? Why don't you remove tmpwatch?

Standing in the way of an enhancement because you want to micromanage
everyone's computing environment to keep it safe is an impossibility.
Someone forgets to run perl cleaner. Ut oh. Someone updates to gcc-4.1. Ut
oh. Someone tries to get modular X installed, ut oh. Portage 2.1 even had
some surprises for unsuspecting users, like nuking a whole bunch of use
flags. But, are those projects hard masked now? 

Provide the warnings, and let the user decide. Those are my points.

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Jon Portnoy]

On Tue, Jun 13, 2006 at 04:17:57PM -0400, Peter wrote:
> It's no such proof. Anyone who rolls a kernel, takes the time to learn
> what it entails, understands what he/she is intending to do, knows the
> ramifications of those actions. Gentoo users, in particular, by virtue of
> the fact that this is a source-based distro, have to be accorded a
> slightly higher level of respect and regard.
> 

Haven't been to #gentoo lately have you?

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[David Morgan]

On 16:17 Tue 13 Jun     , Peter wrote:
> On Tue, 13 Jun 2006 20:17:10 +0100, Ciaran McCreesh wrote:
> > | Care to elaborate?  The wise, all-knowing Zen argument isn't |
> > particularly helpful....
> > 
> > It's perfect proof that there are users that are utterly clueless about
> > what is best for their system, and utterly clueless about how using
> > third party software can cause problems for other software.
> > 
> > 
> It's no such proof. Anyone who rolls a kernel, takes the time to learn
> what it entails, understands what he/she is intending to do, knows the
> ramifications of those actions. Gentoo users, in particular, by virtue of
> the fact that this is a source-based distro, have to be accorded a
> slightly higher level of respect and regard.
> 

heh

-- 
Join The no2id Coalition, http://www.no2id.net/

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

Re: [gentoo-dev] Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Andrej Kacian]

On Tue, 13 Jun 2006 16:17:57 -0400
Peter <pete4abw@comcast.net> wrote:

> It's no such proof. Anyone who rolls a kernel, takes the time to learn
> what it entails, understands what he/she is intending to do, knows the
> ramifications of those actions. Gentoo users, in particular, by
> virtue of the fact that this is a source-based distro, have to be
> accorded a slightly higher level of respect and regard.

It's sad, but a large percentage of Gentoo users look do not have
slightest idea about Linux internals, and look at it as kind of a black
box - not unlike MS Windows. Just try to spend few days/weeks on EFnet's
or IRCnet's (and actually, FreeNode's too) #gentoo channel and you'll
lose that "higher level of respect and regard".

-- 
Andrej

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Mike Frysinger]

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

On Tuesday 13 June 2006 16:17, Peter wrote:
> On Tue, 13 Jun 2006 20:17:10 +0100, Ciaran McCreesh wrote:
> > | Care to elaborate?  The wise, all-knowing Zen argument isn't |
> >
> > particularly helpful....
> >
> > It's perfect proof that there are users that are utterly clueless about
> > what is best for their system, and utterly clueless about how using
> > third party software can cause problems for other software.
>
> It's no such proof. Anyone who rolls a kernel, takes the time to learn
> what it entails, understands what he/she is intending to do, knows the
> ramifications of those actions. Gentoo users, in particular, by virtue of
> the fact that this is a source-based distro, have to be accorded a
> slightly higher level of respect and regard.

you clearly have never heard of love/nitro sources and all the fun we went 
through back when they were being "actively maintained"

being able to download patchsets from the internet, touchup a few lines so 
they apply without rejects, and releasing the result to the rest of the world 
deserves no respect/regard ... you've proven you have skills at:
 - wget
 - patch
 - an editor
 - tar

the respect/regard comes when the compiled kernel *actually performs*
-mike

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

[gentoo-dev] Re: Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Peter]

On Thu, 15 Jun 2006 04:29:44 -0400, Mike Frysinger wrote:

> On Tuesday 13 June 2006 16:17, Peter wrote:
>> On Tue, 13 Jun 2006 20:17:10 +0100, Ciaran McCreesh wrote:
>> > | Care to elaborate?  The wise, all-knowing Zen argument isn't |
>> >
>> > particularly helpful....
>> >
>> > It's perfect proof that there are users that are utterly clueless
>> > about what is best for their system, and utterly clueless about how
>> > using third party software can cause problems for other software.
>>
>> It's no such proof. Anyone who rolls a kernel, takes the time to learn
>> what it entails, understands what he/she is intending to do, knows the
>> ramifications of those actions. Gentoo users, in particular, by virtue
>> of the fact that this is a source-based distro, have to be accorded a
>> slightly higher level of respect and regard.
> 
> you clearly have never heard of love/nitro sources and all the fun we
> went through back when they were being "actively maintained"
> 
Actually, I have. I never wanted to use them because, as with the -mm
sources, they were using stuff not based on the current kernel, but future
enhancements which may or may not make it to the kernel. As for gentoo's
experience with those versions, I am not familiar. Before my time here.
But -mm lives in the tree and so does -ck (and I know dsd is _thrilled_
having them there :)).

> being able to download patchsets from the internet, touchup a few lines
> so they apply without rejects, and releasing the result to the rest of
> the world deserves no respect/regard ... you've proven you have skills
> at:
>  - wget
>  - patch
>  - an editor
>  - tar
> 
> the respect/regard comes when the compiled kernel *actually performs*
> -mike

I respect your opinion. But, does that mean e17 should be removed, because
it really has a lot of problems (like its file manager), or all it's
libraries? How about wine? Just because a project may entail risk, should
not eliminate it from being considered for inclusion in the tree OR in an
overlay.

Anyone can write an ebuild which is different from being able to code an
application. That's obvious. Providing ebuilds is not at all the same in
terms of scope, difficulty or even talent level. I am sure there are many
sucky applications in the tree. But, the purpose of providing ebuilds is
to provide more choice. If you like e17, even though it really is half
functional, and I like e16, which also has some, but not as many issues,
is Gentoo wrong to provide e17 as a choice along with e16?

If a user downloads a hardened kernel and installs it, and wonders why
some things which used to work fine no longer do, is that the fault of the
ebuild provider? The fault of the people who did the patches? The fault
of Gentoo? No. Same with sellinux. People can get just as messed up with
those, as they could with -mm or -ck or -beyond. If someone wants to try
reiser4 and wonder why their hard disk resembles a Picasso painting, is
that the fault of the ebuild's providers?

And, yes, I showed my "limited" skills in downloading and applying
patches for the beyond sources. But, I also applied most of the
gentoo-base and extra patches to beyond as well (if you reviewed the
ebuild). And, you know what? It benchmarks better than all but -ck. I have
not had a crash due to the kernel in two weeks and, it even runs VMWare
which the author (iphitus) wasn't even sure it would do! This was reported
upstream.

JM2C

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Mike Frysinger]

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

On Thursday 15 June 2006 05:39, Peter wrote:
> On Thu, 15 Jun 2006 04:29:44 -0400, Mike Frysinger wrote:
> > being able to download patchsets from the internet, touchup a few lines
> > so they apply without rejects, and releasing the result to the rest of
> > the world deserves no respect/regard ... you've proven you have skills
> > at:
> >  - wget
> >  - patch
> >  - an editor
> >  - tar
> >
> > the respect/regard comes when the compiled kernel *actually performs*
>
> I respect your opinion. But, does that mean e17 should be removed, because
> it really has a lot of problems (like its file manager), or all it's
> libraries? How about wine? Just because a project may entail risk, should
> not eliminate it from being considered for inclusion in the tree OR in an
> overlay.

you really dont get it

e17 doesnt break the whole system

wine doesnt break the whole system

a pos kernel breaks the entire system and wastes everyone's time as it can 
cause *any package at all* to crash and have bug reports filed about that 
package

your little sub thread here wasnt about different bleeding edge packages, it 
was about the obviously incorrect statement that kernel sources has no 
adverse affect on any other package
-mike

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

[gentoo-dev] Re: Re: Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Peter]

On Thu, 15 Jun 2006 10:58:44 -0400, Mike Frysinger wrote:

> On Thursday 15 June 2006 05:39, Peter wrote:
>> On Thu, 15 Jun 2006 04:29:44 -0400, Mike Frysinger wrote:
>> > being able to download patchsets from the internet, touchup a few
>> > lines so they apply without rejects, and releasing the result to the
>> > rest of the world deserves no respect/regard ... you've proven you
>> > have skills at:
>> >  - wget
>> >  - patch
>> >  - an editor
>> >  - tar
>> >
>> > the respect/regard comes when the compiled kernel *actually performs*
>>
>> I respect your opinion. But, does that mean e17 should be removed,
>> because it really has a lot of problems (like its file manager), or all
>> it's libraries? How about wine? Just because a project may entail risk,
>> should not eliminate it from being considered for inclusion in the tree
>> OR in an overlay.
> 
> you really dont get it

Maybe I just don't :(
> 
> e17 doesnt break the whole system

Any alpha software can. Read the warning label. e17 has caused me to hit
the big red switch on several occasions.

> 
> wine doesnt break the whole system
> 
It can trash lots of files. Seen it. Been there. Oh, and one other little
nasty about wine, you can get hit with a virus, and depending on how your
local drives are configured, this can be a bad thing.

> a pos kernel breaks the entire system and wastes everyone's time as it can
> cause *any package at all* to crash and have bug reports filed about that
> package
> 

Any "good" kernel, improperly configured or used can do the same. "Why
doesn't usb work? Why doesn't nvidia work? Why doesn't ssh-fuse not
compile? Why can't I access my home filesystem?" etc. How many users
installed hardened or sellinux and went "Oh sh*t"

> your little sub thread here wasnt about different bleeding edge
> packages, it was about the obviously incorrect statement that kernel
> sources has no adverse affect on any other package -mike

Listen, I'm not going to prolong this. My point was and IS that sources
are just that. They are not applications. They must be configured
correctly to run. If you're going to promote and publish -mm and -ck, then
you can't rightly call a source based on -ck a "pos kernel." Maybe by your
standards, but not by mine, or the others who follow this particular
thread on bz and the forums.

The point of the thread, and I already did my mea culpa for using a kernel
source as an example, was to try and present a user's pov wrt to Sunrise
and how it may benefit the community by hosting such projects. As I wrote
to ciaranm, it's hard to micromanage and control every user's private
installations once the initial install and build has completed.

There's lots of evil out there, but kernel sources are no worse than a pos
application or alpha software.

Obviously, I'm not winning any converts here -- but that was not my
intent. Anything else I write would be redundant. And, should I continue
to fight this, I'd only be a hypocrite by continuing this thread when I
chastise others for making these darn things too long! If you have
particular comments, please contact me off list.

I'll be lurking at the council meeting though. That should be fun!


-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Patrick McLean]

Peter wrote:
 > Maybe I just don't :(
>> e17 doesnt break the whole system
> 
> Any alpha software can. Read the warning label. e17 has caused me to hit
> the big red switch on several occasions.
> 

Then you have a bug in your kernel (or possibly your video driver). It
should be impossible for any user program to take down the system.

>> wine doesnt break the whole system
>>
> It can trash lots of files. Seen it. Been there. Oh, and one other little
> nasty about wine, you can get hit with a virus, and depending on how your
> local drives are configured, this can be a bad thing.

You can be hit by a virus without wine too. Just because there are
currently no viruses for Linux doesn't mean that they are impossible.
Also the damage a virus in wine can do is limited to the user that you
are running wine as, unless of course you are stupid enough to run wine
as root.


> Any "good" kernel, improperly configured or used can do the same. "Why
> doesn't usb work? Why doesn't nvidia work? Why doesn't ssh-fuse not
> compile? Why can't I access my home filesystem?" etc. How many users
> installed hardened or sellinux and went "Oh sh*t"

Those are known conditions. Gentoo developers can debug them. A subtle
failure caused by a bug in the kernel can be VERY hard to debug. Take
for example, a few years ago there was a kernel bug (in vanilla) that
caused perl to fail compiling PORTAGE_TMPDIR was on an ext3 filesystem.
That sort of bug would be almost impossible to track down if it was
caused by some random, untested, duct-tape patchset that the user had
installed.

> 
> Listen, I'm not going to prolong this. My point was and IS that sources
> are just that. They are not applications. They must be configured
> correctly to run. If you're going to promote and publish -mm and -ck, then
> you can't rightly call a source based on -ck a "pos kernel." Maybe by your
> standards, but not by mine, or the others who follow this particular
> thread on bz and the forums.

-mm and -ck are both produced by extremely competent, and knowledgeable
kernel hackers. -nitro or whatever it's called these days is just a
bunch of random patches thrown together by someone who knows how to
munge patches without knowing their actual effect. It's actually not
terribly difficult to munge patches in code that you are unfamiliar with
(I have done it many times myself), but doing this in a kernel can
subtle cause breakages all over the system.

> There's lots of evil out there, but kernel sources are no worse than a pos
> application or alpha software.

Kernel sources can cause all sorts of breakages that normal software
can't. For example, there is no way for a random app to cause certain
strings of data to fail to be written to disk, or off-by-one errors
reading certain random files. Both of these are possible, along with
many other hard to detect and diagnose breakages in the kernel. The
kernel is _not_ just another program, its the main arbiter of system
resources and as such can break the system in ways that even the most
malicious user programs can only dream of.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Tue, 2006-06-13 at 13:29 -0400, Peter wrote:
> As an example, there is a kernel source build I've been playing with. I
> know, from the kernel team, it will never, repeat NEVER, get onto the
> portage tree. they want no part of it. However, the bug is widely
> followed, and if Sunrise were to be a home to it, then these bug readers
> would be able to continue to work on the project. Why should it just waste
> away on bz? See bug # 103354 started by Scott Jones who did most of the
> work on it. This kernel source is also tracked on the gentoo forums.

Using your example, if it will *never* make it into the tree, then what
is it doing on *.gentoo.org infrastructure?

The authors are more than welcome to host this on their own.  There's
absolutely zero reason for us to "support" it in any way, including our
infrastructure, if there's absolutely no way that it will *ever* make it
into the tree.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Michael Cummings]

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

Chris Gianelloni wrote:
> Using your example, if it will *never* make it into the tree, then what
> is it doing on *.gentoo.org infrastructure?

OK, I'll speak up. I plan on using overlay.gentoo.org for the perl team
overlay repository. dev-perl alone has 600+ ebuilds - we are at the
point where we are only adding those modules that have specific support
requirements (makes foo work, etc). But there are plenty of packages
we'd love to add, but don't have the manpower/resources to do it.
Catalyst comes to mind - awesome take on the rails phenom, but the size
and volume makes it tough to fit into our tree, and its one of the first
things I plan on putting up in the overlay. As for the next bit:

> 
> The authors are more than welcome to host this on their own.  There's
> absolutely zero reason for us to "support" it in any way, including our
> infrastructure, if there's absolutely no way that it will *ever* make it
> into the tree.
> 
I don't have the resources to support it somewhere, simply put. I don't
have a server somewhere I can point users to, or the kind of friends
that will run an open svn (or whatever) on their boxes and host my
overlays for me. Plus, this gives me/us a place to combine our
resources, our overlays, into a cohesive whole. Some of it may make it
in the tree one day; some not; some of it has too small an audience to
add the requirements of maintainership to it - but at least it would be
going somewhere.

Just my two cents. Not sure about sunrise, but I'm all behind the overlays.

~mcummings

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEjw6Zq1ztTp5/Ti4RAlBFAJ0TEsgWyNC1z0LoN1kipYOXWbZILQCgoqs0
UzZvAcL5AtQNU33yt1MZB5Y=
=NM8w
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Tue, 2006-06-13 at 15:14 -0400, Michael Cummings wrote:
> Just my two cents. Not sure about sunrise, but I'm all behind the overlays.

*sigh*

I have *never* argued that teams should not be able to run their own
project-specific overlays.  You are the perl team.  You are more than
welcome to run a perl overlay.  I never said you shouldn't be able to do
so, nor has anyone else that I have seen.

Hell, *I* (with ikelos) have an overlay for vmware stuff.

What we *are* arguing against is having something in a
non-project-specific overlay, that is not maintained by the project in
question, and has *specifically* been rejected by the project in
question.  This sort of thing should *never* make it into the sunrise
overlay, since it has been rejected.

An easy way to this about this is:

If the kernel team made an overlay and included it, it would be OK.  If
sunrise does so, it isn't.  Why?  Because the kernel team already
rejected it for inclusion.  We shouldn't be going against the wishes of
the Gentoo teams with an overlay like this.

Please people, be sure you're actually commenting on the issues at hand,
rather than just adding noise.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Stuart Herbert]

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

Hi Chris,

Chris Gianelloni wrote:
| What we *are* arguing against is having something in a
| non-project-specific overlay, that is not maintained by the project in
| question, and has *specifically* been rejected by the project in
| question.  This sort of thing should *never* make it into the sunrise
| overlay, since it has been rejected.

I don't agree that the principle you're putting forward here is one that
actually exists in Gentoo.

Packages are grouped into herds, which are managed by projects.  If a
package doesn't belong to a herd, then it doesn't belong to the project, and
other developers are free to take ownership of the package and include it
into the tree.

A great example of this are web-based applications.  The web-apps project
does not own all the web-based packages in the Portage tree.  There are many
such packages in the tree that are managed by developers that are not part
of the project.  The web-apps project gets to decide what happens to the
packages grouped in the web-apps herd, but we neither have the right (nor
the desire) to tell other developers that they can't add web-based packages
to the tree; nor do other developers require our permission before adding
packages to the tree.

What they _do_ need is our permission before dumping packages into the
web-apps herd.  If a developer doesn't want a package in our herd, then he
doesn't need our permission to add the package into the tree.

That said, there obviously has to been a level of pragmatism.  If a project
recommends that a package doesn't belong in the tree because it is dangerous
to users, then it would be irresponsible of developers to go against this
advice without good reason.

But otherwise, if you don't want a package in your project, it's no longer
your package to make decisions about.  You've declined stewardship of the
package, leaving others free to take on the package instead if they wish.

| Please people, be sure you're actually commenting on the issues at hand,
| rather than just adding noise.

Is that really fair?  What's noise to you isn't noise to everyone else.

Best regards,
Stu
- --
Stuart Herbert                                          stuart@gentoo.org
Gentoo Developer                                   http://www.gentoo.org/
~                                           http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEj0HFDC+AuvmvxXwRAhe4AKCWExHyIObPtLJn3coWZLag7FysTwCeIZD9
/tM0C92JOb/6AXHMyDLpiAI=
=hfRB
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Tue, 2006-06-13 at 23:52 +0100, Stuart Herbert wrote:
> Packages are grouped into herds, which are managed by projects.  If a
> package doesn't belong to a herd, then it doesn't belong to the project, and
> other developers are free to take ownership of the package and include it
> into the tree.

Umm... pretty much all of these packages would belong to a herd.  In
fact, I haven't seen a single package added to bugzilla that *doesn't*
belong to some herd.  Just because the maintaining *project* doesn't
want it doesn't mean it doesn't belong to that herd.

> A great example of this are web-based applications.  The web-apps project
> does not own all the web-based packages in the Portage tree.  There are many
> such packages in the tree that are managed by developers that are not part
> of the project.  The web-apps project gets to decide what happens to the
> packages grouped in the web-apps herd, but we neither have the right (nor
> the desire) to tell other developers that they can't add web-based packages
> to the tree; nor do other developers require our permission before adding
> packages to the tree.

Again, you are confusing herds and projects.

Here's another example of it done correctly.  If you add a game to the
tree, the herd should be listed as games.  Period.  Even if you are
going to be the sole maintainer of the package, games should be the
herd.  Why?  Because it is a game, silly.

There are quite a few packages under games-* that are completely
maintained by someone not on the games team, which means it is not
maintained by the games project.  That doesn't change the fact that it
is a game, and belongs in the games herd.

Herd == grouping of packages
Project == team of people

> What they _do_ need is our permission before dumping packages into the
> web-apps herd.  If a developer doesn't want a package in our herd, then he
> doesn't need our permission to add the package into the tree.

That simply seems a bit backwards from the idea of a herd being a
logical grouping of packages.  You've simply removed logic from the
equation and replaced it with permission.

> That said, there obviously has to been a level of pragmatism.  If a project
> recommends that a package doesn't belong in the tree because it is dangerous
> to users, then it would be irresponsible of developers to go against this
> advice without good reason.
> 
> But otherwise, if you don't want a package in your project, it's no longer
> your package to make decisions about.  You've declined stewardship of the
> package, leaving others free to take on the package instead if they wish.

Except I'm not arguing about abandoned packages.  I'm arguing about
things like kernel sources, that proponents of sunrise say should be in
the overlay, even after the kernel team says that it should *never* go
into the tree.  In this case, the sunrise proponents are explicitly
wanting to go against the wishes of the project.  This is not and can
not be acceptable, as it damages the *project* in question.  Remember
that people will *always* associate the kernel project with any kernels
we provide, even if we put a big fat warning label on it.  Warning
labels don't accomplish much with some users.

> | Please people, be sure you're actually commenting on the issues at hand,
> | rather than just adding noise.
> 
> Is that really fair?  What's noise to you isn't noise to everyone else.

It sure is fair.  So much so that mcummings even spoke with me and
apologized because he hadn't read what I had said correctly.  What he
said *was* absolutely correct, in the context to which he was writing.
However, it didn't add anything to *this* context, since it was out of
context and off-topic.  That is pretty much the definition of what noise
on a mailing list is.  ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

[gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Peter]

On Wed, 14 Jun 2006 09:13:34 -0400, Chris Gianelloni wrote:

big snip.....
> Except I'm not arguing about abandoned packages.  I'm arguing about things
> like kernel sources, that proponents of sunrise say should be in the
> overlay, even after the kernel team says that it should *never* go into
> the tree.  In this case, the sunrise proponents are explicitly wanting to
> go against the wishes of the project.  This is not and can not be
> acceptable, as it damages the *project* in question.  Remember that people
> will *always* associate the kernel project with any kernels we provide,
> even if we put a big fat warning label on it.  Warning labels don't
> accomplish much with some users.
> 

Please let me clarify. My using the kernel-sources as an example in no way
expresses any opinions by the Sunrise project, its leads, or members. I do
not speak for the project, but am (as a user) interested in it and
interested in participating in it.

And, I should also clarify what dsd said about the beyond-sources.
Basically, he was not issuing a judgement on whether or not the sources
were good or bad. He _was_ indicating that the kernel team did not have
the interest or manpower to maintain it, handle any bugs or problems with
it. For that matter, he also expressed an opinion that he wished the
ck-sources would go too! But, let me be clear, he was not saying the
kernel team would never add it to portage because it was bad. Just that
the kernel team did not want to because of manpower and support issues.

I was _trying_ to use it as an example of an orphaned package that would
benefit from Sunrise. Something which also was assigned to the kernel team
(not to maintainer wanted), but has been languishing in bz since August of
last year.

I am sure there are others which have been assigned and not acted on too.
This one, I had a personal interest in, which is why I brought it up. I
suppose I would have been better off using
http://bugs.gentoo.org/show_bug.cgi?id=125727, which is on hold because
there is a dependency issue with libexpat to be resolved by upstream, and
may not make it to the tree.

Either way, I was hoping to bring the user's perspective to this
discussion. It seems on the -devel ml, there are far too few users
comments. Just devs thinking they know what the users want and what is
best for users. As a user, I think that attitude is seriously incorrect.

For, as with every distro, once the install is complete, you lose control
over what the user may or may not add, how, or why. What they add through
portage, what they add to /usr/local manually, is out of your control.

I just wish that you (meaning all devs and council) consider user's
thoughts and needs a little more. Don't just consider how to protect
against every possible outcome or eventuality. Make Gentoo more open.
Speaking unofficially, IMVHO, Sunrise accomplishes that.

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Harald van Dijk]

On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote:
> > A great example of this are web-based applications.  The web-apps project
> > does not own all the web-based packages in the Portage tree.  There are many
> > such packages in the tree that are managed by developers that are not part
> > of the project.  The web-apps project gets to decide what happens to the
> > packages grouped in the web-apps herd, but we neither have the right (nor
> > the desire) to tell other developers that they can't add web-based packages
> > to the tree; nor do other developers require our permission before adding
> > packages to the tree.
> 
> Again, you are confusing herds and projects.
> 
> Here's another example of it done correctly.  If you add a game to the
> tree, the herd should be listed as games.  Period.  Even if you are
> going to be the sole maintainer of the package, games should be the
> herd.  Why?  Because it is a game, silly.

Why do no games' metadata.xml specify games@ as the maintainer? I
thought it was because <herd>games</herd> implies this already, but if
it doesn't, then dozens of games can be considered unmaintained right
now, and fair game for anyone to mess with without approval. Are you
sure you like this interpretation of 'herd'?

You're probably right that herd is supposed to mean what you say it
does, but existing practise, even by yourself, is very different from
it.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 15:54 +0200, Harald van Dijk wrote:
> On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote:
> > > A great example of this are web-based applications.  The web-apps project
> > > does not own all the web-based packages in the Portage tree.  There are many
> > > such packages in the tree that are managed by developers that are not part
> > > of the project.  The web-apps project gets to decide what happens to the
> > > packages grouped in the web-apps herd, but we neither have the right (nor
> > > the desire) to tell other developers that they can't add web-based packages
> > > to the tree; nor do other developers require our permission before adding
> > > packages to the tree.
> > 
> > Again, you are confusing herds and projects.
> > 
> > Here's another example of it done correctly.  If you add a game to the
> > tree, the herd should be listed as games.  Period.  Even if you are
> > going to be the sole maintainer of the package, games should be the
> > herd.  Why?  Because it is a game, silly.
> 
> Why do no games' metadata.xml specify games@ as the maintainer? I
> thought it was because <herd>games</herd> implies this already, but if
> it doesn't, then dozens of games can be considered unmaintained right
> now, and fair game for anyone to mess with without approval. Are you
> sure you like this interpretation of 'herd'?
> 
> You're probably right that herd is supposed to mean what you say it
> does, but existing practise, even by yourself, is very different from
> it.

Umm... no.

See, if there's no maintainer listed, it defaults to the maintaining
project *for that herd*...  Here's another good example.  Go and look at
herds.xml and you'll see this:

<herd>
  <name>games</name>
  <email>games@gentoo.org</email>
  <description>Gentoo Games Team</description>

<maintainingproject>/proj/en/desktop/games/index.xml</maintainingproject>
</herd>

As you can plainly see, the games team is the maintaining project for
applications within the games herd, except in cases where a maintainer
is explicitly listed.

That wasn't so hard, now, was it?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Harald van Dijk]

On Wed, Jun 14, 2006 at 05:13:48PM -0400, Chris Gianelloni wrote:
> On Wed, 2006-06-14 at 15:54 +0200, Harald van Dijk wrote:
> > On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote:
> > > > A great example of this are web-based applications.  The web-apps project
> > > > does not own all the web-based packages in the Portage tree.  There are many
> > > > such packages in the tree that are managed by developers that are not part
> > > > of the project.  The web-apps project gets to decide what happens to the
> > > > packages grouped in the web-apps herd, but we neither have the right (nor
> > > > the desire) to tell other developers that they can't add web-based packages
> > > > to the tree; nor do other developers require our permission before adding
> > > > packages to the tree.
> > > 
> > > Again, you are confusing herds and projects.
> > > 
> > > Here's another example of it done correctly.  If you add a game to the
> > > tree, the herd should be listed as games.  Period.  Even if you are
> > > going to be the sole maintainer of the package, games should be the
> > > herd.  Why?  Because it is a game, silly.
> > 
> > Why do no games' metadata.xml specify games@ as the maintainer? I
> > thought it was because <herd>games</herd> implies this already, but if
> > it doesn't, then dozens of games can be considered unmaintained right
> > now, and fair game for anyone to mess with without approval. Are you
> > sure you like this interpretation of 'herd'?
> > 
> > You're probably right that herd is supposed to mean what you say it
> > does, but existing practise, even by yourself, is very different from
> > it.
> 
> Umm... no.
> 
> See, if there's no maintainer listed, it defaults to the maintaining
> project *for that herd*...

So <herd>games</herd> implies "managed by the games team" sometimes but
not always? Meaning if the maintainer is "games team + X", then "games
team" must be explicitly listed as a maintainer in metadata.xml ?

If so, sorry, misunderstood you, and this is far less insane than what I
thought you were saying.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Paul de Vrieze]

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

On Thursday 15 June 2006 07:57, Harald van Dijk wrote:
> So <herd>games</herd> implies "managed by the games team" sometimes but
> not always? Meaning if the maintainer is "games team + X", then "games
> team" must be explicitly listed as a maintainer in metadata.xml ?
>
> If so, sorry, misunderstood you, and this is far less insane than what I
> thought you were saying.

RTFM.

Metadata.xml specifies a herd for a package. That means that when there is no 
individual maintainer (or he/she fails to do his duty) that package is 
maintained by whomever maintain the herd. In this case the project members of 
the games project maintain the games herd. This means that they will maintain 
the package if there is no named maintainer or he/she leaves, is unavailable, 
etc.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Jakub Moc]

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

Chris Gianelloni wrote:
> Again, you are confusing herds and projects.
> 
> Here's another example of it done correctly.  If you add a game to the
> tree, the herd should be listed as games.  Period.  Even if you are
> going to be the sole maintainer of the package, games should be the
> herd.  Why?  Because it is a game, silly.
> 
> There are quite a few packages under games-* that are completely
> maintained by someone not on the games team, which means it is not
> maintained by the games project.  That doesn't change the fact that it
> is a game, and belongs in the games herd.
> 
> Herd == grouping of packages
> Project == team of people

This new terminology plain sucks. If you are sticking games into <herd>
in metadata.xml, you are just confusing me and other people who are
assigning bugs. You'll get mis-assigned bugs. Either don't do it or find
another tag and get the DTD updated. <herd> is being used for assigning
bugs, you are using it as a placeholder for something else. Category
already tells us that it's a game, don't stick games into <herd> unless
you actually maintain it. Thanks.


-- 
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] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Stephen Bennett]

On Wed, 14 Jun 2006 20:01:04 +0200
Jakub Moc <jakub@gentoo.org> wrote:

> This new terminology plain sucks. If you are sticking games into
> <herd> in metadata.xml, you are just confusing me and other people
> who are assigning bugs. 

It's not new. If it confuses you, perhaps you should learn the
terminology used in metadata before you try to assign bugs based upon
it.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Jakub Moc]

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

Stephen Bennett wrote:
> On Wed, 14 Jun 2006 20:01:04 +0200
> Jakub Moc <jakub@gentoo.org> wrote:
> 
>> This new terminology plain sucks. If you are sticking games into
>> <herd> in metadata.xml, you are just confusing me and other people
>> who are assigning bugs. 
> 
> It's not new. If it confuses you, perhaps you should learn the
> terminology used in metadata before you try to assign bugs based upon
> it.

Sure... so, perhaps you have some suggestion how I can read assign bugs
otherwise than using the metadata.xml; perhaps I could learn to read
minds of the developers who dump irrelevant stuff into metadata.xml and
expect someone to know what they meant.

Meanwhile, I can just tell you that quite a bunch of people will
actually get pretty angry once you start to apply this new on not-so-new
terminology on stuff placed under their herd/project/whatever and will
be dumping stuff on them... Like, perl, apache or php for starters.
Because, they will get the bugs assigned, and they won't like it. And,
we yet lack another method of assigning bugs other than using
metadata.xml for this.


-- 
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] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Stephen Bennett]

On Wed, 14 Jun 2006 20:21:42 +0200
Jakub Moc <jakub@gentoo.org> wrote:

> Sure... so, perhaps you have some suggestion how I can read assign
> bugs otherwise than using the metadata.xml; perhaps I could learn to
> read minds of the developers who dump irrelevant stuff into
> metadata.xml and expect someone to know what they meant.

It's not irrelevant; you're just not reading it properly. You might
notice that metadata.xml contains tags other than <herd>, like, say,
<maintainer>. In the example that sparked this, <herd> is games and
<maintainer> the individual dev who maintains it. Simple enough, no?

A herd has always been a group of packages for as long as I can recall,
which is about two years now. It's nothing new at all. Packages in that
herd can be maintained by a developer or a project, or by the group of
herd maintainers if there are no specific arrangements.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Jakub Moc]

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

Stephen Bennett wrote:
> On Wed, 14 Jun 2006 20:21:42 +0200
> Jakub Moc <jakub@gentoo.org> wrote:
> 
>> Sure... so, perhaps you have some suggestion how I can read assign
>> bugs otherwise than using the metadata.xml; perhaps I could learn to
>> read minds of the developers who dump irrelevant stuff into
>> metadata.xml and expect someone to know what they meant.
> 
> It's not irrelevant; you're just not reading it properly. You might
> notice that metadata.xml contains tags other than <herd>, like, say,
> <maintainer>. In the example that sparked this, <herd> is games and
> <maintainer> the individual dev who maintains it. Simple enough, no?

Please, go through the tree and see at least so many metadata.xml files
as I have seen, before claiming something that simply doesn't reflect
current practice. There are many ebuilds with no <maintainer> tag and
<herd> only. Are you claiming that they are unmaintained? Well, that
obviously doesn't match the reality. So, if they actually _are_
maintained by the relevant herd, then you shouldn't dump stuff on that
herd without discussing it w/ them first. I'm pretty sure mcummings will
gladly explain to you what will happen if you do, as well as a bunch of
other devs... :P

To make it pretty clear and explicit - bugs gets assigned to
<maintainer> (if there's any in metadata.xml), and get CCed to <herd>
(if there's any in metadata.xml). If there's no <maintainer>, whoever is
in <herd> will get that bug assigned and can happily smack you butt once
they've find out you've dumped the package on them without their
knowledge... That's how the large part of current ~600 dev-perl/*
ebuilds has made it into the tree and that mistake doesn't need to be
repeated.



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

herding (was: Re: [gentoo-dev] Re: A heretical thought? project sunrise as an almost-fork.)

[Michael Cummings]

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

OK, when I get invoked by name, then I have to respond :) (obligatory
bah) Mind you, this conversation really deserves its own thread since my
comments stray far, far away from the sunset project (that's going to be
my project for retired ebuilds available still in an overlay...hey, i
was making that up, but suddenly it sounds like a nice idea....)

Jakub Moc wrote:
> So, if they actually _are_
> maintained by the relevant herd, then you shouldn't dump stuff on that
> herd without discussing it w/ them first. I'm pretty sure mcummings will
> gladly explain to you what will happen if you do, as well as a bunch of
> other devs... :P

The gripe in this respect is that we have developers (who don't respond
to emails, friendly or otherwise) that will dump packages into dev-perl,
copy a metadata.xml from another pkg, and leave it as is - and since we
(perl project folks) use a stock metadata.xml listing perl as the herd,
and perl@gentoo.org as maintainer, that means we get stuck with the
package. It sucks because you get bugs for badly written ebuilds and
your only trace of how it got there is either the ChangeLog (if you're
lucky) or the cvs log (had to resort to that once or twice too) - and in
the end, the bugger doesn't care who's package it is, they want it
fixed, and its not their fault for filing a bug, so you grind on and
take care of it.

Now getting all documented for a change, according to the Gentoo
Metadata page [1] every metadata file should contain at least one herd
subtag, and the maintenance of the package falls to that herd if there
is no maintainer also listed. (at least that's my interpretation of the
maintainer description, which says a package "[b]esides being a member
of a herd, can also be maintained directly." Even the examples in this
document direct the reader to believing that the herd listed is the
primary responsible party for the package, with the listed maintainer
being the alternate/additional maintainer. So when Jakub says:

> To make it pretty clear and explicit - bugs gets assigned to
> <maintainer> (if there's any in metadata.xml), and get CCed to <herd>
> (if there's any in metadata.xml). If there's no <maintainer>, whoever is
> in <herd> will get that bug assigned and can happily smack you <> once
> they've find out you've dumped the package on them without their
> knowledge...

he does appear to be correctly quoting the documentation on the site.
And we can't blame the bug wranglers for following this documentation -
we either update it or accept that that's what we have published to date.

's all I got. I may not be a lawyer - but I did ace my con law classes ;)

~mcummings

[1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEkHnfq1ztTp5/Ti4RAi0dAJ44LTeKhabjIpxCi042KxRDwVgAjACglINH
4eUmZ8TqmrwEGNUnPsPV/mU=
=dWd0
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: herding (was: Re: [gentoo-dev] Re: A heretical thought? project sunrise as an almost-fork.)

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 17:04 -0400, Michael Cummings wrote:
> The gripe in this respect is that we have developers (who don't respond
> to emails, friendly or otherwise) that will dump packages into dev-perl,
> copy a metadata.xml from another pkg, and leave it as is - and since we
> (perl project folks) use a stock metadata.xml listing perl as the herd,
> and perl@gentoo.org as maintainer, that means we get stuck with the
> package. It sucks because you get bugs for badly written ebuilds and
> your only trace of how it got there is either the ChangeLog (if you're
> lucky) or the cvs log (had to resort to that once or twice too) - and in
> the end, the bugger doesn't care who's package it is, they want it
> fixed, and its not their fault for filing a bug, so you grind on and
> take care of it.

That's the thing.  That developer is wrong, and has done something
wrong.  I see nothing wrong with listing perl as the herd, *only* if
they have themselves as the maintainer.

> Now getting all documented for a change, according to the Gentoo
> Metadata page [1] every metadata file should contain at least one herd
> subtag, and the maintenance of the package falls to that herd if there
> is no maintainer also listed. (at least that's my interpretation of the
> maintainer description, which says a package "[b]esides being a member
> of a herd, can also be maintained directly." Even the examples in this
> document direct the reader to believing that the herd listed is the
> primary responsible party for the package, with the listed maintainer
> being the alternate/additional maintainer. So when Jakub says:

Not exactly...

Notice it says that a package is a member of a herd, not a person.  A
herd can have one or more projects responsible for maintaining the
packages in it.  In *most* cases, the group of developers responsible
for a given herd either have an alias that matches the herd, or are a
project with a similar alias.

> > To make it pretty clear and explicit - bugs gets assigned to
> > <maintainer> (if there's any in metadata.xml), and get CCed to <herd>
> > (if there's any in metadata.xml). If there's no <maintainer>, whoever is
> > in <herd> will get that bug assigned and can happily smack you <> once
> > they've find out you've dumped the package on them without their
> > knowledge...
> 
> he does appear to be correctly quoting the documentation on the site.

That's where I disagree.  His practice is correct.  It should be
assigned to the maintainers of the herd, if no maintainer is listed, but
a herd is *not* a group of developers.  It is a group of packages, with
developers that maintain that group.

> And we can't blame the bug wranglers for following this documentation -
> we either update it or accept that that's what we have published to date.

Except that what I am saying is what the documentation says, and also
the intention of the documentation, as stated by some of the people who
wrote it, back when we had the whole "herds vs. teams" thread.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: herding (was: Re: [gentoo-dev] Re: A heretical thought? project sunrise as an almost-fork.)

[Paul de Vrieze]

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

On Wednesday 14 June 2006 23:50, Chris Gianelloni wrote:
> On Wed, 2006-06-14 at 17:04 -0400, Michael Cummings wrote:
> > The gripe in this respect is that we have developers (who don't respond
> > to emails, friendly or otherwise) that will dump packages into dev-perl,
> > copy a metadata.xml from another pkg, and leave it as is - and since we
> > (perl project folks) use a stock metadata.xml listing perl as the herd,
> > and perl@gentoo.org as maintainer, that means we get stuck with the
> > package. It sucks because you get bugs for badly written ebuilds and
> > your only trace of how it got there is either the ChangeLog (if you're
> > lucky) or the cvs log (had to resort to that once or twice too) - and in
> > the end, the bugger doesn't care who's package it is, they want it
> > fixed, and its not their fault for filing a bug, so you grind on and
> > take care of it.
>
> That's the thing.  That developer is wrong, and has done something
> wrong.  I see nothing wrong with listing perl as the herd, *only* if
> they have themselves as the maintainer.

Only with perl consent. The perl herd then gets the responsibility to take 
over if the maintainer leaves, is unavailable, etc.

>
> Not exactly...
>
> Notice it says that a package is a member of a herd, not a person.  A
> herd can have one or more projects responsible for maintaining the
> packages in it.  In *most* cases, the group of developers responsible
> for a given herd either have an alias that matches the herd, or are a
> project with a similar alias.
>
> > > To make it pretty clear and explicit - bugs gets assigned to
> > > <maintainer> (if there's any in metadata.xml), and get CCed to <herd>
> > > (if there's any in metadata.xml). If there's no <maintainer>, whoever
> > > is in <herd> will get that bug assigned and can happily smack you <>
> > > once they've find out you've dumped the package on them without their
> > > knowledge...
> >
> > he does appear to be correctly quoting the documentation on the site.
>
> That's where I disagree.  His practice is correct.  It should be
> assigned to the maintainers of the herd, if no maintainer is listed, but
> a herd is *not* a group of developers.  It is a group of packages, with
> developers that maintain that group.

Nowhere did I write (nor was it agreed then) that herd membership should be 
automatic. The bug wranglers seem to be doing the right thing. Assign to 
maintainer, CC the herd email address.

>
> > And we can't blame the bug wranglers for following this documentation -
> > we either update it or accept that that's what we have published to date.
>
> Except that what I am saying is what the documentation says, and also
> the intention of the documentation, as stated by some of the people who
> wrote it, back when we had the whole "herds vs. teams" thread.

The reason there should always be a herd is very simple. People leave, groups 
of people leave less, and can be replenished.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Stephen Bennett]

On Wed, 14 Jun 2006 22:34:55 +0200
Jakub Moc <jakub@gentoo.org> wrote:

> Please, go through the tree and see at least so many metadata.xml
> files as I have seen, before claiming something that simply doesn't
> reflect current practice. There are many ebuilds with no <maintainer>
> tag and <herd> only. Are you claiming that they are unmaintained?

No; read the second paragraph.

> To make it pretty clear and explicit - bugs gets assigned to
> <maintainer> (if there's any in metadata.xml), and get CCed to <herd>
> (if there's any in metadata.xml). If there's no <maintainer>, whoever
> is in <herd> will get that bug assigned and can happily smack you
> butt once they've find out you've dumped the package on them without
> their knowledge... 

...so packages marked with a herd and a maintainer have bugs against
them assigned to the maintainer. Sure, it would be polite to at least
talk to the relevant herd maintainers before adding a package, but that
holds regardless of whether you put it in the herd or not. Either way
the bugs will go to the specific maintainer, so herds having bugs
assigned to them that they don't care about isn't really an argument.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 22:34 +0200, Jakub Moc wrote:
> > It's not irrelevant; you're just not reading it properly. You might
> > notice that metadata.xml contains tags other than <herd>, like, say,
> > <maintainer>. In the example that sparked this, <herd> is games and
> > <maintainer> the individual dev who maintains it. Simple enough, no?
> 
> Please, go through the tree and see at least so many metadata.xml files
> as I have seen, before claiming something that simply doesn't reflect
> current practice. There are many ebuilds with no <maintainer> tag and
> <herd> only. Are you claiming that they are unmaintained? Well, that

Nobody said that they were unmaintained.  Again, why do people *insist*
on trying bullshit arguments like this?  "Are you claiming.."  No, he's
not claiming that, or he would have *said* that.

> obviously doesn't match the reality. So, if they actually _are_
> maintained by the relevant herd, then you shouldn't dump stuff on that
> herd without discussing it w/ them first. I'm pretty sure mcummings will
> gladly explain to you what will happen if you do, as well as a bunch of
> other devs... :P

A herd is a group of packages, not a listing of people.  When you get
information from the herds.xml, you are getting the listing of the
people that *maintain* that herd.  You are not getting a listing of the
people *in* the herd.

Please go back and read the herds project page[1] and try to understand
this.  It really is printed quite simply.


> To make it pretty clear and explicit - bugs gets assigned to
> <maintainer> (if there's any in metadata.xml), and get CCed to <herd>
> (if there's any in metadata.xml). If there's no <maintainer>, whoever is
> in <herd> will get that bug assigned and can happily smack you butt once
> they've find out you've dumped the package on them without their
> knowledge... That's how the large part of current ~600 dev-perl/*
> ebuilds has made it into the tree and that mistake doesn't need to be
> repeated.

You are correct.  This is *exactly* how it works.  Also, you'll notice
that nothing either I or Stephen has said contradicts this, if you
actually went back and contemplated what we both said.

[1] http://www.gentoo.org/proj/en/metastructure/herds/

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Dan Meltzer]

On 6/14/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> On Wed, 2006-06-14 at 22:34 +0200, Jakub Moc wrote:
> > > It's not irrelevant; you're just not reading it properly. You might
> > > notice that metadata.xml contains tags other than <herd>, like, say,
> > > <maintainer>. In the example that sparked this, <herd> is games and
> > > <maintainer> the individual dev who maintains it. Simple enough, no?
> >
> > Please, go through the tree and see at least so many metadata.xml files
> > as I have seen, before claiming something that simply doesn't reflect
> > current practice. There are many ebuilds with no <maintainer> tag and
> > <herd> only. Are you claiming that they are unmaintained? Well, that
>
> Nobody said that they were unmaintained.  Again, why do people *insist*
> on trying bullshit arguments like this?  "Are you claiming.."  No, he's
> not claiming that, or he would have *said* that.
>
> > obviously doesn't match the reality. So, if they actually _are_
> > maintained by the relevant herd, then you shouldn't dump stuff on that
> > herd without discussing it w/ them first. I'm pretty sure mcummings will
> > gladly explain to you what will happen if you do, as well as a bunch of
> > other devs... :P
>
> A herd is a group of packages, not a listing of people.  When you get
> information from the herds.xml, you are getting the listing of the
> people that *maintain* that herd.  You are not getting a listing of the
> people *in* the herd.

According to the devmanual [1]
"A herd is a collection of developers who maintain a collection of
related packages"

are you sure you are using the correct term?

[1] http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html
>
> Please go back and read the herds project page[1] and try to understand
> this.  It really is printed quite simply.
>
>
> > To make it pretty clear and explicit - bugs gets assigned to
> > <maintainer> (if there's any in metadata.xml), and get CCed to <herd>
> > (if there's any in metadata.xml). If there's no <maintainer>, whoever is
> > in <herd> will get that bug assigned and can happily smack you butt once
> > they've find out you've dumped the package on them without their
> > knowledge... That's how the large part of current ~600 dev-perl/*
> > ebuilds has made it into the tree and that mistake doesn't need to be
> > repeated.
>
> You are correct.  This is *exactly* how it works.  Also, you'll notice
> that nothing either I or Stephen has said contradicts this, if you
> actually went back and contemplated what we both said.
>
> [1] http://www.gentoo.org/proj/en/metastructure/herds/
>
> --
> Chris Gianelloni
> Release Engineering - Strategic Lead
> x86 Architecture Team
> Games - Developer
> Gentoo Linux
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEkIGskT4lNIS36YERAlg2AKCmitk2Pwd7XSP+ysarJDc1imbnUgCgt2wv
> OYJuhhIg+vG5wom7DRcwHEg=
> =Tprl
> -----END PGP SIGNATURE-----
>
>
>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Donnie Berkholz]

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

Dan Meltzer wrote:
> According to the devmanual [1]
> "A herd is a collection of developers who maintain a collection of
> related packages"
> 
> are you sure you are using the correct term?
> 
> [1]
> http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html

I guess it needs to get fixed, then. Proof that documentation isn't perfect.

Thanks,
Donnie


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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Stephen Bennett]

On Wed, 14 Jun 2006 20:54:21 -0400
"Dan Meltzer" <parallelgrapefruit@gmail.com> wrote:

> According to the devmanual [1]
> "A herd is a collection of developers who maintain a collection of
> related packages"
> 
> are you sure you are using the correct term?

He's right. The devmanual is not authoritative.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Ciaran McCreesh]

On Wed, 14 Jun 2006 20:54:21 -0400 "Dan Meltzer"
<parallelgrapefruit@gmail.com> wrote:
| According to the devmanual [1]
| "A herd is a collection of developers who maintain a collection of
| related packages"
| 
| are you sure you are using the correct term?

Ah, yes, we're back to the old "what is a herd?" thing again. There're
at least three equally valid definitions you can trot out depending
upon which suits your argument. There's the original metastructure
description, which was suitable in the old days but no matches the
realities of how things are developed (especially the dumping packages
part, which used to be standard practice and is now considered
extremely rude), there's the "herds are people" definition that matches
how the word is most usually used (and which was argued for earlier by
some of the people who are now arguing for the old metastructure
definition) and there's the pragmatic definition in the devmanual.
Really, anyone arguing purely on definition is missing the point...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Paul de Vrieze]

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

On Thursday 15 June 2006 02:54, Dan Meltzer wrote:

> According to the devmanual [1]
> "A herd is a collection of developers who maintain a collection of
> related packages"
>
> are you sure you are using the correct term?
>
> [1]
> http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html

The dev manual is *wrong*.
I should know too. I wrote the bloody herds.xml and metadata.xml formats and 
the page along. Indeed it does not clearly specify what herds are, but it is 
certainly implied in the format description of for example the maintainer 
tag.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Ciaran McCreesh]

On Thu, 13 Jul 2006 14:55:57 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| The dev manual is *wrong*.

No, the devmanual reflects what's actually being done, rather than an
impractical definition that was written years ago that no longer
matches the development model.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Paul de Vrieze]

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

On Thursday 13 July 2006 18:53, Ciaran McCreesh wrote:
> On Thu, 13 Jul 2006 14:55:57 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | The dev manual is *wrong*.
>
> No, the devmanual reflects what's actually being done, rather than an
> impractical definition that was written years ago that no longer
> matches the development model.

Then file a bug against the given definition. This only adds to the confusion.
As I remember however there have been discussions on this topic and they never 
came to any conclusion.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 20:21 +0200, Jakub Moc wrote:
> Sure... so, perhaps you have some suggestion how I can read assign bugs
> otherwise than using the metadata.xml; perhaps I could learn to read
> minds of the developers who dump irrelevant stuff into metadata.xml and
> expect someone to know what they meant.

It isn't irrelevant, at all.  It is a grouping of packages beyond what
is provided by the categories.  The idea was to have certain projects
responsible for certain herds, but that isn't a requirement.

> Meanwhile, I can just tell you that quite a bunch of people will
> actually get pretty angry once you start to apply this new on not-so-new
> terminology on stuff placed under their herd/project/whatever and will
> be dumping stuff on them... Like, perl, apache or php for starters.
> Because, they will get the bugs assigned, and they won't like it. And,
> we yet lack another method of assigning bugs other than using
> metadata.xml for this.

Umm... There's the maintainer tag that you seem to be either forgetting
or ignoring.  If I had $random_perl_library and it had the herd as perl,
yet me listed as the maintainer, who would get the bug?

Are you telling me now that bug wranglers ignore the maintainer field?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 20:01 +0200, Jakub Moc wrote:
> Chris Gianelloni wrote:
> > Again, you are confusing herds and projects.
> > 
> > Here's another example of it done correctly.  If you add a game to the
> > tree, the herd should be listed as games.  Period.  Even if you are
> > going to be the sole maintainer of the package, games should be the
> > herd.  Why?  Because it is a game, silly.
> > 
> > There are quite a few packages under games-* that are completely
> > maintained by someone not on the games team, which means it is not
> > maintained by the games project.  That doesn't change the fact that it
> > is a game, and belongs in the games herd.
> > 
> > Herd == grouping of packages
> > Project == team of people
> 
> This new terminology plain sucks. If you are sticking games into <herd>
> in metadata.xml, you are just confusing me and other people who are
> assigning bugs. You'll get mis-assigned bugs. Either don't do it or find
> another tag and get the DTD updated. <herd> is being used for assigning
> bugs, you are using it as a placeholder for something else. Category
> already tells us that it's a game, don't stick games into <herd> unless
> you actually maintain it. Thanks.

"New" terminology?  That is the definition of a herd.  If you're using
it incorrectly to mean something else, that doesn't mean I'm changing
anything.

The category doesn't tell you *anything* about who maintains it.  Take
dev-util/catalyst as an example, or app-misc/livecd-tools.  You can't
glean *any* maintainer information from the category.  It just happens
that all of the games are also in games-* categories.  However, there
are even some packages which are not in games-* that belong to the games
herd, and are maintained by the games team.

Also, we almost *never* get bugs assigned to us that don't belong,
except for in the cases where a maintainer is listed, yet games gets the
bug anyway.  These cases are simple cases of whomever is doing the
reassigning not checking the metadata, so any changes in behavior won't
make a bit of difference here.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Ned Ludd]

On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote:

> Just because the maintaining *project* doesn't
> want it doesn't mean it doesn't belong to that herd.

This is incorrect and you should not encourage people to add pkgs to 
a herd unless they get permission from that herd. If a herd does not 
want it you shall not shit in their home (it's rude).
When a package lists a herd then the responsibility is shared 
among the maintainer and the herd.

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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 14:47 -0400, Ned Ludd wrote:
> On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote:
> 
> > Just because the maintaining *project* doesn't
> > want it doesn't mean it doesn't belong to that herd.
> 
> This is incorrect and you should not encourage people to add pkgs to 
> a herd unless they get permission from that herd. If a herd does not 
> want it you shall not shit in their home (it's rude).

A herd doesn't *want* anything.  It is a group of packages.  Perhaps you
mean a maintaining project?

> When a package lists a herd then the responsibility is shared 
> among the maintainer and the herd.

Only if someone didn't list themselves as the maintainer, which would be
wrong.  Just because the games team doesn't maintain something doesn't
mean it isn't a game anymore.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Ned Ludd]

On Wed, 2006-06-14 at 17:25 -0400, Chris Gianelloni wrote:
> On Wed, 2006-06-14 at 14:47 -0400, Ned Ludd wrote:
> > On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote:
> > 
> > > Just because the maintaining *project* doesn't
> > > want it doesn't mean it doesn't belong to that herd.
> > 
> > This is incorrect and you should not encourage people to add pkgs to 
> > a herd unless they get permission from that herd. If a herd does not 
> > want it you shall not shit in their home (it's rude).
> 
> A herd doesn't *want* anything.  It is a group of packages.  Perhaps you
> mean a maintaining project?

Nope not at all see below.

> 
> > When a package lists a herd then the responsibility is shared 
> > among the maintainer and the herd.
> 


> Only if someone didn't list themselves as the maintainer, which would be
> wrong.  Just because the games team doesn't maintain something doesn't
> mean it isn't a game anymore.

I think you are confusing a category/ vs a herd.
But in the case of games@ only we can take your note and keep it in 
mind when adding new packages to the tree to go ahead and slap a 
games@ on it. But sorry not the rest of the tree.


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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Stuart Herbert]

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

Chris Gianelloni wrote:
> Here's another example of it done correctly.  If you add a game to the
> tree, the herd should be listed as games.  Period.  Even if you are
> going to be the sole maintainer of the package, games should be the
> herd.  Why?  Because it is a game, silly.

There _is_ no requirement that a package must belong to a herd.  It's very 
good advice, and it's good for Gentoo, but it's _not_ a requirement.  I'm 
sorry, but I think in this case what you are asserting isn't correct.

Why does this matter?  Why am I bringing this up?  You are asking for the 
ability to 'opt out' of Project Sunrise, to decide that certain types of 
packages are not added to the Project Sunrise overlay; specifically, that 
games are not added to the Sunrise overlay.

As I understand it, and I apologise if I'm wrong, these are packages that 
you (and your project) do not maintain at the moment - if you did, they 
would be in the tree.  You have already strongly asserted in this thread how 
you feel about things needing to be in the tree.

When I say I don't believe, I mean that I'm not aware of any Gentoo rule 
giving project leads any such dominion.I don't believe being the lead of any 
project (be it games, webapps, or anything else) gives _anyone_ the 
automatic right to suppress packages that you're not going to maintain - 
subject to the due diligence about dangerous packages and unmaintained 
packages that I mentioned earlier in this thread.  I believe that this is a 
right that you are claiming for yourself; I'm sure you're doing so with good 
intentions.

You've raised a lot of valid concerns about the plans of Project Sunrise, 
but here I think you're asking for too much, by trying to assert dominion 
over what simply isn't yours to control.

It's reasonable (and existing Gentoo practice) to say "hands off - we 
maintain that package".

Saying "hands off, but we are not going to maintain that package either" ... 
it may be good for you, but I can't see how it's good for Gentoo - unless 
the package is dangerous.

Best regards,
Stu
-- 
Stuart Herbert                                          stuart@gentoo.org
Gentoo Developer                                   http://www.gentoo.org/
                                            http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 20:15 +0100, Stuart Herbert wrote:
> Chris Gianelloni wrote:
> > Here's another example of it done correctly.  If you add a game to the
> > tree, the herd should be listed as games.  Period.  Even if you are
> > going to be the sole maintainer of the package, games should be the
> > herd.  Why?  Because it is a game, silly.
> 
> There _is_ no requirement that a package must belong to a herd.  It's very 
> good advice, and it's good for Gentoo, but it's _not_ a requirement.  I'm 
> sorry, but I think in this case what you are asserting isn't correct.

http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4

Specifically the listing for the herd tag.

Just because people are doing things *wrong* doesn't mean that there
isn't a defined manner in which things should be done.

> When I say I don't believe, I mean that I'm not aware of any Gentoo rule 
> giving project leads any such dominion.I don't believe being the lead of any 
> project (be it games, webapps, or anything else) gives _anyone_ the 
> automatic right to suppress packages that you're not going to maintain - 
> subject to the due diligence about dangerous packages and unmaintained 
> packages that I mentioned earlier in this thread.  I believe that this is a 
> right that you are claiming for yourself; I'm sure you're doing so with good 
> intentions.

Here's where you start making wild assumptions.  Who ever said that we
don't intend on maintaining *every* ebuild that gets submitted to us?

You are starting to put words into my mouth and making claims that I'm
not making.  Stop.

> You've raised a lot of valid concerns about the plans of Project Sunrise, 
> but here I think you're asking for too much, by trying to assert dominion 
> over what simply isn't yours to control.

The bugs is assigned to the games team.

Should I go and simply ACCEPT every single bug assigned to games in
bugzilla, including all of the bug spam that will be caused by it, just
to show that we *have* accepted these bugs, and are simply working
through them at our own pace?

> It's reasonable (and existing Gentoo practice) to say "hands off - we 
> maintain that package".

Correct.

> Saying "hands off, but we are not going to maintain that package either" ... 
> it may be good for you, but I can't see how it's good for Gentoo - unless 
> the package is dangerous.

I never said this.  Please don't try to use things that I never said as
an argument, especially putting them in quotes, as if to quote me.
You'll only serve to piss me off.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Stuart Herbert]

On 6/14/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4
>
> Specifically the listing for the herd tag.
>
> Just because people are doing things *wrong* doesn't mean that there
> isn't a defined manner in which things should be done.

>From the document you've referenced:

"The metadata.xml file has as its purpose to give extra information
about ebuilds. The metadata.xml file should exist in every package
directory. A skel file can be found as skel.metadata.xml in the
portage tree."

That clearly doesn't say that every package _requires_ a metadata.xml
file.  The word used is "should", not "must".  Also:

"<herd> There must at least be one herd subtag. The contents of this
tag should be the name of be a herd as specified in the herds.xml
file. It must occur at least once. "

Again, the word used is "should", and not "must".

I'm sorry, but I do feel that your interpretation of the rules, on
this point, isn't quite right.  There _is_ no requirement that games
added to the tree _have_ to be put into the games herd - just like
there's no requirement that all web-based apps _have_ to be put into
the webapps herd.

Also, see Solar's post in this thread confirming what I'm saying.

> The bugs is assigned to the games team.
>
> Should I go and simply ACCEPT every single bug assigned to games in
> bugzilla, including all of the bug spam that will be caused by it, just
> to show that we *have* accepted these bugs, and are simply working
> through them at our own pace?

Yes, that would be sufficient.  That shows that the package is yours,
and then the usual rule (that other developers should not mess with
your packages) would then apply.  That would be in keeping with how
Gentoo does things, and would remove the need for you to request that
there's a per-team opt-out clause in Project Sunrise.

It would also leave Project Sunrise (_if_ the Council decides that it
can go ahead) free to pick up any packages that end up in the
maintainer-wanted bucket, regardless of what type of package that is.

> You'll only serve to piss me off.

To refer once again to what you like to tell others, maybe you need to
grow a thicker skin? ;-)

In all seriousness, you're one of the two lead complainants about
Project Sunrise.  You've raised a number of points about Sunrise that
need debating; you were right to do so, and I don't think anyone feels
that they shouldn't have been raised.

If you're not going to participate in a debate about those concerns
without throwing your toys out of the pram, it undermines the
complaint that you're making.  That's plain enough to see by looking
at the reaction elsewhere in these threads to some of the postings
from the Sunrise project team, where they've behaved like that.

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Kevin F. Quinn]

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

On Thu, 15 Jun 2006 15:07:36 +0100
"Stuart Herbert" <stuart.herbert@gmail.com> wrote:

> On 6/14/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4
> >
> > Specifically the listing for the herd tag.
> >
> > Just because people are doing things *wrong* doesn't mean that there
> > isn't a defined manner in which things should be done.
> 
> From the document you've referenced:
> 
> "The metadata.xml file has as its purpose to give extra information
> about ebuilds. The metadata.xml file should exist in every package
> directory. A skel file can be found as skel.metadata.xml in the
> portage tree."
> 
> That clearly doesn't say that every package _requires_ a metadata.xml
> file.  The word used is "should", not "must".  Also:

However it does mean you need to have a very good reason for not
providing one.  Compare with "may" or "can".  "Can't be bothered" or
"don't want to" are not sufficient reasons.  I read the "should" as
implying that all new packages must have it, and packages existing
before the introduction of metadata should get it as and when
maintainer gets around to it (i.e. at least on the next bump).

> "<herd> There must at least be one herd subtag. The contents of this
> tag should be the name of be a herd as specified in the herds.xml
> file. It must occur at least once. "
> 
> Again, the word used is "should", and not "must".

So you'd better have a good excuse for violating the rule if you do
so.  Anyone adding a herd tag to meet the "shall", then putting garbage
in it that isn't the name of a defined herd for no good reason,
deserves to be spanked.

> I'm sorry, but I do feel that your interpretation of the rules, on
> this point, isn't quite right.  There _is_ no requirement that games
> added to the tree _have_ to be put into the games herd - just like
> there's no requirement that all web-based apps _have_ to be put into
> the webapps herd.

However common sense suggests that anyone adding games to the tree
should join the games team and add the game to the games herd (which
obviously means playing by the rules of the team) - not least to provide
consistency; but also to be in the loop for overall games issues and to
provide the most sensible backup maintainers.

In other words, you need to have a very good reason for avoiding the
games team and herd when adding a game to the tree.

> Also, see Solar's post in this thread confirming what I'm saying.
> 
> > The bugs is assigned to the games team.
> >
> > Should I go and simply ACCEPT every single bug assigned to games in
> > bugzilla, including all of the bug spam that will be caused by it,
> > just to show that we *have* accepted these bugs, and are simply
> > working through them at our own pace?
> 
> Yes, that would be sufficient.  That shows that the package is yours,
> and then the usual rule (that other developers should not mess with
> your packages) would then apply.  That would be in keeping with how
> Gentoo does things, and would remove the need for you to request that
> there's a per-team opt-out clause in Project Sunrise.
> 
> It would also leave Project Sunrise (_if_ the Council decides that it
> can go ahead) free to pick up any packages that end up in the
> maintainer-wanted bucket, regardless of what type of package that is.
> 
> > You'll only serve to piss me off.
> 
> To refer once again to what you like to tell others, maybe you need to
> grow a thicker skin? ;-)
> 
> In all seriousness, you're one of the two lead complainants about
> Project Sunrise.  You've raised a number of points about Sunrise that
> need debating; you were right to do so, and I don't think anyone feels
> that they shouldn't have been raised.
> 
> If you're not going to participate in a debate about those concerns
> without throwing your toys out of the pram, it undermines the
> complaint that you're making.  That's plain enough to see by looking
> at the reaction elsewhere in these threads to some of the postings
> from the Sunrise project team, where they've behaved like that.
> 
> Best regards,
> Stu


-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Stuart Herbert]

Hi Kevin,

On 6/15/06, Kevin F. Quinn <kevquinn@gentoo.org> wrote:
> I read the "should" as
> implying that all new packages must have it, and packages existing
> before the introduction of metadata should get it as and when
> maintainer gets around to it (i.e. at least on the next bump).

Chris's argument was that this doc _requires_ packages to belong to
herds (specifically, that all packages that are games automatically
belong to the games herd).  The document clearly doesn't support his
argument.

> So you'd better have a good excuse for violating the rule if you do
> so.  Anyone adding a herd tag to meet the "shall", then putting garbage
> in it that isn't the name of a defined herd for no good reason,
> deserves to be spanked.

?? Where has that come from?  Has there been a spate of people doing this?

> However common sense suggests that anyone adding games to the tree
> should join the games team and add the game to the games herd (which
> obviously means playing by the rules of the team) - not least to provide
> consistency; but also to be in the loop for overall games issues and to
> provide the most sensible backup maintainers.

As you say yourself, it's suggested, not mandatory - and it doesn't
have to be a specific herd.

> In other words, you need to have a very good reason for avoiding the
> games team and herd when adding a game to the tree.

That's your personal opinion, which I respect, and I understand how
you've come to that conclusion.  But it doesn't change the fact that,
if folks choose to maintain a game without joining the games herd,
they're prefectly entitled to do so.  And the same is true for
webapps, or anything else.  You simply can't go around clubbing people
over the head and saying "that's a <project> project ebuild, join our
team or it doesn't go into the tree", which is where this is leading.

What we _don't_ want are folks adding a package to a tree and dumping
it on a herd without their permission.  That always has been a big 'no
no' in Gentoo.

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Thu, 2006-06-15 at 19:18 +0100, Stuart Herbert wrote:
> Hi Kevin,
> 
> On 6/15/06, Kevin F. Quinn <kevquinn@gentoo.org> wrote:
> > I read the "should" as
> > implying that all new packages must have it, and packages existing
> > before the introduction of metadata should get it as and when
> > maintainer gets around to it (i.e. at least on the next bump).
> 
> Chris's argument was that this doc _requires_ packages to belong to
> herds (specifically, that all packages that are games automatically
> belong to the games herd).  The document clearly doesn't support his
> argument.

I said no such thing.

This is clearly a case of you trying to assume what I'm saying in such a
way that it matches with what you want me to say.

I said that all games in the tree should be in the games herd.  We like
it this way.  Trying to make it out like I said something that I didn't
does what for you, exactly?

> > So you'd better have a good excuse for violating the rule if you do
> > so.  Anyone adding a herd tag to meet the "shall", then putting garbage
> > in it that isn't the name of a defined herd for no good reason,
> > deserves to be spanked.
> 
> ?? Where has that come from?  Has there been a spate of people doing this?

Ever seen a "no-herd" package?

> That's your personal opinion, which I respect, and I understand how
> you've come to that conclusion.  But it doesn't change the fact that,
> if folks choose to maintain a game without joining the games herd,
> they're prefectly entitled to do so.  And the same is true for
> webapps, or anything else.  You simply can't go around clubbing people
> over the head and saying "that's a <project> project ebuild, join our
> team or it doesn't go into the tree", which is where this is leading.

Not at all... this is where the naysayers will lead you to *believe*
that it is leading.  How about this?  How about you ask tcort about what
happened the other day with the games package that he wanted to add?

He asked me if he could add it and he would maintain it.  I said yes.
He added it with games as the herd, and him as maintainer.

Where's the problem?

> What we _don't_ want are folks adding a package to a tree and dumping
> it on a herd without their permission.  That always has been a big 'no
> no' in Gentoo.

See, this is where you're mistaken in thinking that anyone says that you
can dump a package on someone else.  I *definitely* have said no such
thing.  If someone adds a game, they better damn well list themselves as
the maintainer.  The same should be true for all packages.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

[gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Duncan]

Chris Gianelloni <wolf31o2@gentoo.org> posted
1150396775.16946.100.camel@cgianelloni.nuvox.net, excerpted below, on 
Thu, 15 Jun 2006 14:39:35 -0400:

> On Thu, 2006-06-15 at 19:18 +0100, Stuart Herbert wrote:
>> Hi Kevin,
>> 
>> On 6/15/06, Kevin F. Quinn <kevquinn@gentoo.org> wrote:
>> > I read the "should" as
>> > implying that all new packages must have it, and packages existing
>> > before the introduction of metadata should get it as and when
>> > maintainer gets around to it (i.e. at least on the next bump).
>> 
>> Chris's argument was that this doc _requires_ packages to belong to
>> herds (specifically, that all packages that are games automatically
>> belong to the games herd).  The document clearly doesn't support his
>> argument.
> 
> I said no such thing.
> 
> This is clearly a case of you trying to assume what I'm saying in such a
> way that it matches with what you want me to say.

I'd take exception to that "clearly", as I don't see that being the case
at all, so it's "clearly as mudly", to coin a phrase.  <g>

> I said that all games in the tree should be in the games herd.  We like
> it this way.  Trying to make it out like I said something that I didn't
> does what for you, exactly?

To me (and evidently to Stuart H), those say exactly the same thing, that
is:

Stu H (arguing that this is what you said, but against the viewpoint):
>> this doc _requires_ packages to belong to herds (specifically, that
>> all packages that are games automatically belong to the games herd).

to me is so similar as to be equivalent to:

Chris G:
> I said that all games in the tree should be in the games herd.

It has long been my personal observation that many arguments aren't in
fact arguments at all, once the meaning assigned by the different sides to
each word is translated.  That may or may not be the case here, but it's
certainly true that I (and evidently Stu H) see no difference between the
the two statements above, while you vehemently argue there IS a
difference, and that in fact it's apparently so clear that someone must be
deliberately distorting your statement to make it into the other.  (OK,
that's what I read into "Trying to make it out like I said something I
didn't", but to be entirely fair, maybe you mean something different there
than the way I read it too?)

That being the case, perhaps if you could try to explain what you see as
the difference between the two statements, the discussion can progress
beyond this point.  It does (to me) seem useless to continue, if what
appears to be the very basic difference of whether the two above
statements are effectively equivalent cannot be resolved.  The arguments
are just going past each other, since the two sides apparently are arguing
different things due to differences in received meanings.

(General observation...  It generally does little to progress a
discussion, and much to heat it up, when someone accuses the other side of
deliberate distortion, when it may rather be a basic definitional
difference, and therefore not deliberate at all.  Even if there's no
conceivable way you can see that the opposing viewpoint makes sense, it's
generally far more conducive to progress to assume an honest attempt at
understanding on the part of the other side, an honest misunderstanding,
and try to find the definitional difference, than to heat up the
discussion by saying something is clear, when it's obviously not or the
statement wouldn't have been made in the first place.  That said, both
sides continued the discussion past the point where it was obvious this
was a sticking point, rather than stopping right there to address it, so
both sides are guilty. I just picked this point to step in and ask for the
clarification myself, since I honestly don't see the difference in the
two statements you say are so different, myself.)

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

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Duncan]

Chris Gianelloni <wolf31o2@gentoo.org> posted
1150234358.13805.51.camel@cgianelloni.nuvox.net, excerpted below, on  Tue,
13 Jun 2006 17:32:38 -0400:

> What we *are* arguing against is having something in a
> non-project-specific overlay, that is not maintained by the project in
> question, and has *specifically* been rejected by the project in
> question.  This sort of thing should *never* make it into the sunrise
> overlay, since it has been rejected.

But as Stuart Herbert pointed out, a project can be self-authorized, by
the current rules. Project Sunrise therefore didn't /need/ permission to
come into existence and set up its own overlay.  The announcement here,
while perhaps it /should/ have been discussed as a proposal first,
therefore didn't break the rules as they are now.

Meanwhile, the Project Sunrise overlay /is/ a project specific overlay,
and /is/ maintained by the project in question (Sunrise).  That has been
specifically stated in the Project Sunrise formulation.

Furthermore, there's specific allowance for competing projects, and as
Stuart again points out, ebuilds form herds which are maintained by
projects, and once a project rejects the ebuild, it can then be picked up
by another developer or project, in which case the project that rejected
it is no more responsible for it except that they can continue to refuse
that it be in that project.

-- 
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: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Ciaran McCreesh]

On Wed, 14 Jun 2006 08:52:37 +0000 (UTC) "Duncan"
<1i5t5.duncan@cox.net> wrote:
| But as Stuart Herbert pointed out, a project can be self-authorized,
| by the current rules. Project Sunrise therefore didn't /need/
| permission to come into existence and set up its own overlay.  The
| announcement here, while perhaps it /should/ have been discussed as a
| proposal first, therefore didn't break the rules as they are now.

The rules call for a GLEP for any wide ranging change. And funnily
enough, they do so to avoid exactly the kind of mess that Sunrise is.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20060614100903.310fae14@snowdrop.home, excerpted below, on  Wed, 14 Jun
2006 10:09:03 +0100:

> The rules call for a GLEP for any wide ranging change. And funnily
> enough, they do so to avoid exactly the kind of mess that Sunrise is.

Point valid.

-- 
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: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 10:09 +0100, Ciaran McCreesh wrote:
> On Wed, 14 Jun 2006 08:52:37 +0000 (UTC) "Duncan"
> <1i5t5.duncan@cox.net> wrote:
> | But as Stuart Herbert pointed out, a project can be self-authorized,
> | by the current rules. Project Sunrise therefore didn't /need/
> | permission to come into existence and set up its own overlay.  The
> | announcement here, while perhaps it /should/ have been discussed as a
> | proposal first, therefore didn't break the rules as they are now.
> 
> The rules call for a GLEP for any wide ranging change. And funnily
> enough, they do so to avoid exactly the kind of mess that Sunrise is.

Amen.

This is *exactly* what the GLEP process was created to prevent.  This
project has the potential to impact almost every team in Gentoo.  I'd
call that a wide-ranging change.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 08:52 +0000, Duncan wrote:
> But as Stuart Herbert pointed out, a project can be self-authorized, by
> the current rules. Project Sunrise therefore didn't /need/ permission to
> come into existence and set up its own overlay.  The announcement here,
> while perhaps it /should/ have been discussed as a proposal first,
> therefore didn't break the rules as they are now.

Abusing loopholes in the rules doesn't make something "right".

> Meanwhile, the Project Sunrise overlay /is/ a project specific overlay,
> and /is/ maintained by the project in question (Sunrise).  That has been
> specifically stated in the Project Sunrise formulation.

Correct.  However, it is attempting to work with ebuilds/packages that
are owned by other projects currently.  *This* is my objection.

> Furthermore, there's specific allowance for competing projects, and as
> Stuart again points out, ebuilds form herds which are maintained by
> projects, and once a project rejects the ebuild, it can then be picked up
> by another developer or project, in which case the project that rejected
> it is no more responsible for it except that they can continue to refuse
> that it be in that project.

The "competing projects" idea really is stupid.  Unfortunately, there's
nothing that I can do about that at this time except ask that the idea
be either clarified or rejected by the council.

Two projects "competing" to produce a similar product (like, say two
projects trying to come up with a next-generation genkernel) is one
thing.  Two "competing" projects maintaining the same herd space within
the portage tree is something else.  This creates animosity between the
projects, is completely against the ideas of fostering cooperation and
teamwork, and generally sticks it to our users due to a few egos.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

[gentoo-dev] Re: Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Duncan]

Chris Gianelloni <wolf31o2@gentoo.org> posted
1150292057.16946.21.camel@cgianelloni.nuvox.net, excerpted below, on  Wed,
14 Jun 2006 09:34:16 -0400:

> Abusing loopholes in the rules doesn't make something "right".

Agreed.  However, it then points out the need for a rules change.

>> Meanwhile, the Project Sunrise overlay /is/ a project specific overlay,
>> and /is/ maintained by the project in question (Sunrise).  That has been
>> specifically stated in the Project Sunrise formulation.
> 
> Correct.  However, it is attempting to work with ebuilds/packages that
> are owned by other projects currently.  *This* is my objection.

But if they aren't in the tree, they aren't part of a herd, and therefore
can't really be owned by a project, particularly if that project has had a
chance to put it in the tree and hasn't taken it (whether due to lack of
manpower or whatever).  Now, there's a difference between an active
rejection -- this is not fit for the tree nor can it be and here's why --
and a simple lack of manpower rejection, which is why giving the project
that  might normally take it over if it were to be in the tree dibs on
accepting/rejecting it is good, but a default to being available for
sunrise to sponsor if the project doesn't respond either way within a
reasonable time (which would indicate a lack of manpower  or interest in
doing so, thus leaving it available should others choose to do so) seems
reasonable within context.

Not that I have any immediate plans to use it at this time, but I could
conceivably use it for one or more single packages -- tho I expect I'll be
examining each individual ebuild as I merge and upgrade it if I do -- the
security issues are real to me too, and I'm not quite /that/ insane. =8^)

-- 
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: A heretical thought? Blessing project sunrise as an almost-fork.

[Stuart Herbert]

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

Michael Cummings wrote:
| Chris Gianelloni wrote:
|>> Using your example, if it will *never* make it into the tree, then what
|>> is it doing on *.gentoo.org infrastructure?
|
| OK, I'll speak up. I plan on using overlay.gentoo.org for the perl team
| overlay repository.

[snip]

You're not alone.

The webapps overlay contains ebuilds that may never make it into the tree.
We have a lot of packages that we maintain, but which don't pass our
upstream requirements [1] at this time.  We're doing our best to work with
$upstream on resolving such issues, but we're never going to achieve a 100%
success rate.

Chris: Gentoo infrastructure's there as a service to the Gentoo project as a
whole, not just the Portage tree.  If folks are running an authorised Gentoo
project (and, right now, the rules say that anyone can setup a project
without requiring anyone else's permission; i.e. folks can authorise their
own projects), and infra's able to provide what they're asking for, then I
can't see how it matters whether or not a project is using infrastructure to
host packages that'll never make it into the tree.

If you want to go down that route, then I think you should be working within
the project's processes (specifically, via GLEPs or Council resolutions) to
change our governing rules.

Until the rules change, I think this _specific_ argument against Project
Sunrise is _completely_ bogus.  You're entitled to your opinion, but folks
are equally entitled to totally ignore it.

I _do_ think it's reasonable to want to know that whatever's being done with
Gentoo infrastructure is being done responsibly.  That's the complaint Brix
brought to me, and it's what we're now waiting on the Council to resolve -
unless it can be resolved between yourselves and Project Sunrise before then.

[1] http://overlays.gentoo.org/proj/webapps/wiki/UpstreamRequirements

Best regards,
Stu
- --
Stuart Herbert                                          stuart@gentoo.org
Gentoo Developer                                   http://www.gentoo.org/
~                                           http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEjzoHDC+AuvmvxXwRAvrvAJsHqeOFGvEAUX93G7/xcBLKjTyw3ACglqu+
ofpkHxwdyG7o2xHlmurDI00=
=LZ3T
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Kevin F. Quinn]

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

On Tue, 13 Jun 2006 23:19:51 +0100
Stuart Herbert <stuart@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael Cummings wrote:
> | Chris Gianelloni wrote:
> |>> Using your example, if it will *never* make it into the tree,
> then what |>> is it doing on *.gentoo.org infrastructure?
> |
> | OK, I'll speak up. I plan on using overlay.gentoo.org for the perl
> team | overlay repository.
> 
> [snip]
> 
> You're not alone.
> 
> The webapps overlay contains ebuilds that may never make it into the
> tree. We have a lot of packages that we maintain, but which don't
> pass our upstream requirements [1] at this time.  We're doing our
> best to work with $upstream on resolving such issues, but we're never
> going to achieve a 100% success rate.

No-one is objecting to these project-local overlays.  The objection is
to a system-wide overlay.

To comment on the subject - as a system-wide overlay sunrise does look
a lot like a fork of the man tree.  This could be alleviated by banning
several things from the overlay; eclasses are already listed, but
I think it would be a good idea to include key system elements (e.g.
kernel, toolchain, baselayout - perhaps the sys-* categories) in the ban
for sunrise. Anything hacking around with such critical components
should be in their own specific overlay.  This is key to the
objections; that sunrise is system-wide, not local to a particular area.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 08:38 +0200, Kevin F. Quinn wrote:
> On Tue, 13 Jun 2006 23:19:51 +0100
> Stuart Herbert <stuart@gentoo.org> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Michael Cummings wrote:
> > | Chris Gianelloni wrote:
> > |>> Using your example, if it will *never* make it into the tree,
> > then what |>> is it doing on *.gentoo.org infrastructure?
> > |
> > | OK, I'll speak up. I plan on using overlay.gentoo.org for the perl
> > team | overlay repository.
> > 
> > [snip]
> > 
> > You're not alone.
> > 
> > The webapps overlay contains ebuilds that may never make it into the
> > tree. We have a lot of packages that we maintain, but which don't
> > pass our upstream requirements [1] at this time.  We're doing our
> > best to work with $upstream on resolving such issues, but we're never
> > going to achieve a 100% success rate.
> 
> No-one is objecting to these project-local overlays.  The objection is
> to a system-wide overlay.

Correct.

I would have *no problem* with an opt-in system.  Instead of using
"InOverlay" (which is a poor choice anyway... which overlay?) as some
sort of tag, instead, assign the package to the project which maintains
the herd the package belongs to.  If the project does not want it, then
they can add "SUNRISE" to Keywords (in bugzilla).  The Sunrise project
then has permission to do with the package as they see fit.  At *this*
point, you could use "InOverlay", since it would be pretty obvious which
overlay it means.

The real root of the problem is that packages that were once assigned to
teams/projects are now being assigned into a generic dumping ground and
being forgotten.  You're trying to resolve this problem by moving them
to another dumping ground, which I completely disagree with.  A better
solution would be to revert the broken behavior, and start assigning
packages back to the projects, as it used to be done.  Let the project
decide if they want the package or not.  If they don't, then they can
simply add a single keyword and Sunrise can have at it.

This pleases everyone, as packages can be maintained in Sunrise, and the
projects still get to decide about packages that would likely affect
them.  It changes the project to an opt-in project, rather than having
to track down things and opt-out.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Henrik Brix Andersen]

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

On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote:
> I would have *no problem* with an opt-in system.  Instead of using
> "InOverlay" (which is a poor choice anyway... which overlay?) as some
> sort of tag, instead, assign the package to the project which maintains
> the herd the package belongs to.  If the project does not want it, then
> they can add "SUNRISE" to Keywords (in bugzilla).  The Sunrise project
> then has permission to do with the package as they see fit.  At *this*
> point, you could use "InOverlay", since it would be pretty obvious which
> overlay it means.
> 
> The real root of the problem is that packages that were once assigned to
> teams/projects are now being assigned into a generic dumping ground and
> being forgotten.  You're trying to resolve this problem by moving them
> to another dumping ground, which I completely disagree with.  A better
> solution would be to revert the broken behavior, and start assigning
> packages back to the projects, as it used to be done.  Let the project
> decide if they want the package or not.  If they don't, then they can
> simply add a single keyword and Sunrise can have at it.
> 
> This pleases everyone, as packages can be maintained in Sunrise, and the
> projects still get to decide about packages that would likely affect
> them.  It changes the project to an opt-in project, rather than having
> to track down things and opt-out.

Except there is a flaw in your idea. As I see it, nothing prevents the
developers of Project Sunrise from joining each and every team
currently in existance and start marking enhancement requests
"SUNRISE", regardless of the general opinion of the team/project.

I am not in favor of an opt-in/opt-out system.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Alec Warner]

Henrik Brix Andersen wrote:
> On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote:
> 
>>I would have *no problem* with an opt-in system.  Instead of using
>>"InOverlay" (which is a poor choice anyway... which overlay?) as some
>>sort of tag, instead, assign the package to the project which maintains
>>the herd the package belongs to.  If the project does not want it, then
>>they can add "SUNRISE" to Keywords (in bugzilla).  The Sunrise project
>>then has permission to do with the package as they see fit.  At *this*
>>point, you could use "InOverlay", since it would be pretty obvious which
>>overlay it means.
>>
>>The real root of the problem is that packages that were once assigned to
>>teams/projects are now being assigned into a generic dumping ground and
>>being forgotten.  You're trying to resolve this problem by moving them
>>to another dumping ground, which I completely disagree with.  A better
>>solution would be to revert the broken behavior, and start assigning
>>packages back to the projects, as it used to be done.  Let the project
>>decide if they want the package or not.  If they don't, then they can
>>simply add a single keyword and Sunrise can have at it.
>>
>>This pleases everyone, as packages can be maintained in Sunrise, and the
>>projects still get to decide about packages that would likely affect
>>them.  It changes the project to an opt-in project, rather than having
>>to track down things and opt-out.
> 
> 
> Except there is a flaw in your idea. As I see it, nothing prevents the
> developers of Project Sunrise from joining each and every team
> currently in existance and start marking enhancement requests
> "SUNRISE", regardless of the general opinion of the team/project.

I would presume if the team is against that the hypothetical developer 
would find him(her)self in a sticky situation and perhaps even get 
kicked off of the team(s) in question.  Some teams actually talk to each 
other, have policy, etc.

> 
> I am not in favor of an opt-in/opt-out system.
> 
> Regards,
> Brix

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Wed, 2006-06-14 at 15:56 +0200, Henrik Brix Andersen wrote:
> On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote:
> > I would have *no problem* with an opt-in system.  Instead of using
> > "InOverlay" (which is a poor choice anyway... which overlay?) as some
> > sort of tag, instead, assign the package to the project which maintains
> > the herd the package belongs to.  If the project does not want it, then
> > they can add "SUNRISE" to Keywords (in bugzilla).  The Sunrise project
> > then has permission to do with the package as they see fit.  At *this*
> > point, you could use "InOverlay", since it would be pretty obvious which
> > overlay it means.
> > 
> > The real root of the problem is that packages that were once assigned to
> > teams/projects are now being assigned into a generic dumping ground and
> > being forgotten.  You're trying to resolve this problem by moving them
> > to another dumping ground, which I completely disagree with.  A better
> > solution would be to revert the broken behavior, and start assigning
> > packages back to the projects, as it used to be done.  Let the project
> > decide if they want the package or not.  If they don't, then they can
> > simply add a single keyword and Sunrise can have at it.
> > 
> > This pleases everyone, as packages can be maintained in Sunrise, and the
> > projects still get to decide about packages that would likely affect
> > them.  It changes the project to an opt-in project, rather than having
> > to track down things and opt-out.
> 
> Except there is a flaw in your idea. As I see it, nothing prevents the
> developers of Project Sunrise from joining each and every team
> currently in existance and start marking enhancement requests
> "SUNRISE", regardless of the general opinion of the team/project.

Sure there is.  That is what we would call an abuse of power and should
be met with the appropriate $smackdown on the developer who went and did
such actions.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Richard Fish]

On 6/13/06, Peter <pete4abw@comcast.net> wrote:
> As an example, there is a kernel source build I've been playing with. I
> know, from the kernel team, it will never, repeat NEVER, get onto the
> portage tree. they want no part of it.

My guess is that alternative kernels are probably the strongest
argument there is _in favor_ of having a user-supported overlay area.
It represents very little risk of wasting developers time on chasing
down false bug reports, since the kernel version shows up in the
emerge --info output.  Any bug report from a user running an
unsupported (whether in-tree or out-of-tree) kernel can simply be
closed with a "try again with a supported kernel, reopen if
necessary".

It does risk some extra iterations of problem solving on -user, since
we don't have a policy of requiring everybody posting a question to
supply their --info.  But I think that would be acceptable.

But this is a very specific case, and if it really needs to be on
*.gentoo.org, it could be handled with a "ricer-kernels.o.g.o"
overlay.  I don't see any great reason why such an overlay would need
to be hosted on o.g.o however.

And this single case doesn't serve as an adequate counter-argument to
the concerns about the broad scope of sunrise.

>
> This kernel source will not cause Armageddon to arrive, cause smoke to
> issue from your power supply, nor interfere with other ebuilds.
>

So I take this to mean you are supplying a warranty for this kernel?
Because AFAIK even the people who *wrote* the kernel are quite
explicit in the "no warranty" provisions of the license.  Not even if
it spins your hard drive backwards causing your entire mp3 collection
to be converted to Britney Spears songs!

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

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Ned Ludd]

On Tue, 2006-06-13 at 18:26 +0200, Henrik Brix Andersen wrote:

>  I have a problem with it being an official project hosted on
> *.gentoo.org, as I fear most users will think "hey, it's official,
> it's hosted on *.gentoo.org - it can't be that bad". Judging from the
> few users who have posted to the previous threads on this subject, my
> fear seems to be reasonable.
> 
> If the project was to be hosted on a non *.gentoo.org domain (I'll let
> infra comment on whether or not non *.gentoo.org domains can be hosted
> on infra hardware) my current issues with this project would be gone.

Would moving it from overlays.g.o to overlays.dev.g.o, 
overlays.experimental.dev.g.o help ? It could then be viewed 
officially unofficial as the tinderboxing repository's I've 
been working on.

Personally I know I would like to have a place to park 
pic, iconv, nls patches in testing, and embedded-kernels that are say 
vital for some devices but for one reason or another should not be in 
the official tree.

> If the project proves to be healthy and not affect the reputation of
> Gentoo in a bad way, we could consider adopting it as an official
> project after a period of time.

Or not?


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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Henrik Brix Andersen]

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

On Tue, Jun 13, 2006 at 02:15:12PM -0400, Ned Ludd wrote:
> Would moving it from overlays.g.o to overlays.dev.g.o, 
> overlays.experimental.dev.g.o help ? It could then be viewed 
> officially unofficial as the tinderboxing repository's I've 
> been working on.

It wouldn't be the ideal solution to me.

> Or not?

That's an option as well.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Peper]

> Would moving it from overlays.g.o to overlays.dev.g.o,
> overlays.experimental.dev.g.o help ? It could then be viewed
> officially unofficial as the tinderboxing repository's I've
> been working on.
I think it won't make a big difference. It's stated clearly that the sunrise 
overlay is experimental and unsupported. If some user is really that blind he 
won't read the link either. And overlays.experimental.dev.gentoo.org domain 
is a bit unfriendly, don't you think so? Next step would be 
sunrise.the.experimental.and.unsupported.overlay.hosted.on.dev.overlays.gentoo.org

> Personally I know I would like to have a place to park
> pic, iconv, nls patches in testing, and embedded-kernels that are say
> vital for some devices but for one reason or another should not be in
> the official tree.
Sunrise would be a good place i think ;]

-- 
Best Regards,
Peper
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Jakub Moc]

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

Ned Ludd wrote:
> On Tue, 2006-06-13 at 18:26 +0200, Henrik Brix Andersen wrote:
> 
>>  I have a problem with it being an official project hosted on
>> *.gentoo.org, as I fear most users will think "hey, it's official,
>> it's hosted on *.gentoo.org - it can't be that bad". Judging from the
>> few users who have posted to the previous threads on this subject, my
>> fear seems to be reasonable.
>>
>> If the project was to be hosted on a non *.gentoo.org domain (I'll let
>> infra comment on whether or not non *.gentoo.org domains can be hosted
>> on infra hardware) my current issues with this project would be gone.
> 
> Would moving it from overlays.g.o to overlays.dev.g.o, 
> overlays.experimental.dev.g.o help ? It could then be viewed 
> officially unofficial as the tinderboxing repository's I've 
> been working on.

I like the idea, helps to differentiate a bit. Though - frankly said I
don't really understand what's this paranoia about. You don't have
control over users' systems. There are tons of overlays users are using
daily [1] - but obviously according to some people the one like Sunrise
must definitely be the worst overlay ever, which will just make users
boxes massively explode in smoke, kill Gentoo, all its reputation and
half of the near universe. The main reason being that it's been hosted
on overlays.gentoo.org and hence it's obviously official and we must
guarantee that it will be 130% working and won't bring a single bad byte
on users' boxes, otherwise - wheeeeee kaboooom, the end of the world!

[1] http://gentoo-wiki.com/TIP_Overlays

> Personally I know I would like to have a place to park 
> pic, iconv, nls patches in testing, and embedded-kernels that are say 
> vital for some devices but for one reason or another should not be in 
> the official tree.

Erm, better host it somewhere else, you'll save yourself trouble and it
will be more effective.

>> If the project proves to be healthy and not affect the reputation of
>> Gentoo in a bad way, we could consider adopting it as an official
>> project after a period of time.
> 
> Or not?

Shrug... The question is whether the maintainers will be interested in
becoming an official project or if they'll just choose to save
themselves the trouble.

Getting tired of this thread, really. Talk about too much ado for
nothing. So, how about we stop wasting time, let people who are
interested to do something do it, and the rest of us can focus on more
important stuff than endless debates on mailing list and bothering
Gentoo Council - such as fixing current bugs and cleaning the dead cruft
in the tree, or fixing things not yet ported for modular X, or unported
for gcc-4.x, or whatever else?

Mailing list threads that don't fix one screen resolution suck, you can
expect another funding request from blubb any time soon, it seems. :P


-- 
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] A heretical thought? Blessing project sunrise as an almost-fork.

[Simon Stelling]

Jakub Moc wrote:
> Getting tired of this thread, really. Talk about too much ado for
> nothing. So, how about we stop wasting time, let people who are
> interested to do something do it, and the rest of us can focus on more
> important stuff than endless debates on mailing list and bothering
> Gentoo Council - such as fixing current bugs and cleaning the dead cruft
> in the tree, or fixing things not yet ported for modular X, or unported
> for gcc-4.x, or whatever else?

Damn liberal! [1]

SCNR

[1] http://dev.gentoo.org/~chriswhite/docs/flame.html#doc_chap1_pre1

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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

On Tue, 2006-06-13 at 11:10 -0500, Grant Goodyear wrote:
> Over the years we've had a fairly consistent stream of suggestions that
> we should open up the e-build maintaining process to users instead of
> just devs.  The main arguments against it are the security issues and an
> expectation that it would add to developer workloads.  The former is
> certainly a real problem, although signing (assuming a reasonable
> web-of-trust) could mitigate that some (at least we'd know who to
> blame).  The latter, however, is conjecture, and the only good way to
> verify it would be to actually try it and see what happens.  Oh, and
> there's also a very real fear that if things go horribly wrong, that
> Gentoo's reputation would suffer quite badly.  Perhaps I'm naive, but I
> tend to think that if we were to advertise project sunrise as
> experimental, temporary, use-at-your-own-risk, and
> might-break-your-system, and even put it on hardware without a
> gentoo.org address and add a portage hook that warns whenever the
> project sunrise overlay is used, then our reputation isn't really likely
> to suffer even if it's a complete disaster.
> 
> So, Chris, what have I failed to address that would make this a really
> bad idea?

Honestly, I'm not feeling the urge to retype everything I put into my
last email again, just because someone else asked it.

This has come up time and time again, and every time it gets shot down
for lots of reasons.  Why is it suddenly a good idea now, when it has
always been a bad idea before?  Is it just that now we have a lot of
developers who are willing to allow users to break their boxes?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[Peper]

> (...) Is it just that now we have a lot of
> developers who are willing to allow users to break their boxes?
Just tell me one thing, are you breaking your box everytime you use an 
overlay?

-- 
Best Regards,
Peper
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Stefan Schweizer]

Grant Goodyear wrote:
> Over the years we've had a fairly consistent stream of suggestions that
> we should open up the e-build maintaining process to users instead of
> just devs.  The main arguments against it are the security issues and an
> expectation that it would add to developer workloads.  The former is
> certainly a real problem, although signing (assuming a reasonable
> web-of-trust) could mitigate that some (at least we'd know who to
> blame).  The latter, however, is conjecture, and the only good way to
> verify it would be to actually try it and see what happens.  Oh, and
> there's also a very real fear that if things go horribly wrong, that
> Gentoo's reputation would suffer quite badly. Perhaps I'm naive, but I 
> tend to think that if we were to advertise project sunrise as
> experimental, temporary, use-at-your-own-risk, and
> might-break-your-system, 
That is already done.

> and even put it on hardware without a 
> gentoo.org address and add 
Sorry, we cannot do that. gentoo.org is an essential part of Sunrise and
even the reason it came into existance. Looking at the project page [1] I
can see multiple goals that would become hard if not impossible on
non-gentoo hardware.

"provide a central home for contributed ebuilds that do not (yet) find a
place in the portage tree"
It is hard to make it look like a central place if it is not on .gentoo.org

"get users to contribute their ebuilds to "gentoo" instead of a third-party
overlay"
This is particularly important to me, because I have delt with users having
problems with overlays. If the overlay-maintainer is unreachable and the
overlay is broken it harms gentoos reputation even if the overlay is not on
gentoo hardware. Overlays should be on gentoo as much as possible so that
we are able to fix breakage.
Users will not contribute or will be hard to persuade for a not gentoo.org
overlay.

> a portage hook that warns whenever the 
> project sunrise overlay is used, 
This came up already at the beginning of Sunrise and has of course been
taken care of [2}

> then our reputation isn't really likely 
> to suffer even if it's a complete disaster.
Sorry, I cannot see how this could turn into a complete disaster. It is all
controlled, controllable and access can be restricted, removed, it can be
modified, .. because it is on .gentoo.org even infra has the ability to
shut it down if things go bad.

[1] http://www.gentoo.org/proj/en/sunrise
[2] http://bugs.gentoo.org/136031

Regards,
Stefan


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[George Shapovalov]

I don't think this (the general idea) is a heretical thought, in fact it was 
around for quite some time. See #1523 for example, which actually came out of 
a similar thread back ?5? years ago.
(There were no GLEPs back then, for those of you who will wan't to go "why 
this isn't it glepped?" :). There were no overlays, even no KEYWORDS back 
then either, so be carefull if you read it - it is quite outdated (half of 
what is discussed there is already implemented in fact) and uses old 
terminology.)
But then I agree about many issues raised regarding the Sunrise project. The 
way it is pushed will not offload anything off the developers and is quite 
likely to do quite the contrary..

The main issue:
to make it fly and really make something useable (supported by users, *not* 
taking devs out of the loop and *not* loading them any more) one (at least) 
ingridient is missing IMNSHO. That is: some ranking system - for the ebuilds 
*and* for the users. It was referenced as voting system in that bug, we also 
had gentoo-stats project (now like what, 4 years ago?) which was not quite 
the same but addressing similar and more immediate issue.

This part of the process (the rankings), taken as an "entity in itself",  is 
not that straightforward (meaning a significant tossing of the design ideas 
would be necessary) and the benefits are not that vital. I think these were 
the main reasons it did not take off as a standalone project (e.g. 
gentoo-stats was restarted a few times, but eventually died). While it is 
nice to have some idea of package usage (which was the main goal of 
gentoo-stats) or get some fuzzy feeling on "I (user) rated holier than thou 
because of my superior ebuilding skills" (voting process in that bug), these 
are clearly not enough to create something sustained. And I am not talking 
about ethics here (this is re: ratings for users - this was actually 
mentioned a few times, so I'll address it right now). A general rule - if 
something is perceived worthy it will be done, no matter how unethical. Even 
if we (the devs) would ban this, nothing stopped the users to create 
something similar on their own (who knows, based around BMG, forums or 
whatever). The fact that this did not happen IMHO illustrates pretty well 
that this is a no-fly thing on its own.

On the other hand I think that just opening up the barrier and allowing users 
to easily bring stuff in is just the same no-fly-by-itself thingy. The 
reason: you have to provide some control over quality or you will get another 
BMG, and my understanding is (the Sunrise thread was pretty long, so I cannot 
be totally sure :)) that that was generally accepted. Now, we have two ways 
to add control:

1. Involve devs, directly or indirectly - this is what Sunrise is proposing 
and many devs strongly object. 

2. Involve users and leave it on their side. There were a few words said about 
how users would take care of it all, but I did not get a clear idea of a 
workflow..

First on #1. 
Sunrise proponents basically say: "we will take care of it all, nobody needs 
to care". Many devs object: "as long as it has anything-gentoo in its 
name/affiliations we *will* feel the consequences and *will* have to care". 
(and now Sunrise poeple basically said that without gentoo in affiliatio it 
is pointless). 
To that I'll add that in any case, bacause of the scale, there is just no way 
Sunrise people themselves are going to be able to keep up. Even if their 
involvement is reduced to the very basic stuff. (This was implied or shortly 
noted in some replies, but I wanted to clearly restate it now..)
But then, involving users without clear workflow and QC will just create 
another mess - "just another BMG" as some people called it.

So, here we go, its number 2 and it requires some structure.
The most fluid one I can think of is a rankings system. For the packages 
(based on reviews of the code, emerge success, usage testing. Can be a 
compound parameter or multidimentional. That bug has some details, but not 
much of those - needs serious redesign I'd say to bring it to present from 
the past..)
and for the submitters/editors - based on the ratings of their submissions 
perhaps (the most straightforwards one), possibly on a few more factors.



So, to summarise:
1. I do agree that in general that (ease of user-side care) is a good thing, 
however this requires (quite) a bit more work than just setting up an 
overlay..

2. (at least) two things - the ease of submission/access to packages and 
QC/ratings are quite tied together and have to be designed/implemented at the 
same time. (And there is some empirical evidence to back this up - BMG and 
gentoo-stats for one) .

George

вівторок, 13. червень 2006 18:10, Grant Goodyear Ви написали:
> Over the years we've had a fairly consistent stream of suggestions that
> we should open up the e-build maintaining process to users instead of
> just devs.  The main arguments against it are the security issues and an
> expectation that it would add to developer workloads.  The former is
> certainly a real problem, although signing (assuming a reasonable
> web-of-trust) could mitigate that some (at least we'd know who to
> blame).  The latter, however, is conjecture, and the only good way to
> verify it would be to actually try it and see what happens.  Oh, and
> there's also a very real fear that if things go horribly wrong, that
> Gentoo's reputation would suffer quite badly.  Perhaps I'm naive, but I
> tend to think that if we were to advertise project sunrise as
> experimental, temporary, use-at-your-own-risk, and
> might-break-your-system, and even put it on hardware without a
> gentoo.org address and add a portage hook that warns whenever the
> project sunrise overlay is used, then our reputation isn't really likely
> to suffer even if it's a complete disaster.
>
> So, Chris, what have I failed to address that would make this a really
> bad idea?
>
> -g2boojum-

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Steev Klimaszewski]

On Tue, 13 Jun 2006 20:30:27 +0200, Henrik Brix Andersen <brix@gentoo.org> wrote:
> On Tue, Jun 13, 2006 at 02:14:24PM -0400, Peter wrote:
>> I did. Sources don't affect anything. The ck-sources are in the tree,
> and
>> there is dire warning associated with them. Only the -mm sources have
> any
>> sort of warning. If a user CHOOSES to use a hacked up kernel, then they
>> obviously choose to. Just like, if a user chooses to try out reiserfs-4,
>> they get what they pay for. Sources don't affect anything.
> 
> I rest my case.
> 
> ./Brix

I fail to understand your case, and I will admit to not having followed this thread extremely closely due to the fact that we are getting ready to roll out our 2.0 release, you are saying that people should, or should not have the choice?  Or that people are free to have the choice as long as it isn't on infra controlled Gentoo hardware?  Emerging the kernel sources, as far as I understand it, doesn't affect anything (except perhaps external drivers, but then again, what doesn't - you have some wireless drivers that require some options be set in the kernel, and others not be set, and it gets worse when you are trying to test both pieces of hardware at the same time as they refuse to co-exist due to the way the drivers are being written these days)

The way I see it, this could be a huge step forward, and bug reports should have the emerge --info in them anyways, and you would see they are using sunrise there.  So is the real issue that people would use the overlay or that the overlay is hosted on Gentoo hardware and that makes it bad?  I really wish I could follow this thread better.  Can someone summarize?

-- 
gentoo-dev@gentoo.org mailing list