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

[gentoo-dev] Re: Did portage 2.1 change default use flags?

[Duncan]

Peter <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on  Tue, 13
Jun 2006 12:57:08 -0400:

> On Tue, 13 Jun 2006 18:08:03 +0200, Bo Ørsted Andresen wrote:
> 
>> On Monday 12 June 2006 12:57, Bo Ørsted Andresen wrote:
>>> On Monday 12 June 2006 12:42, Peter wrote:
>>> > All of a sudden, emerge -uD --newuse world is showing dozens of
>>> > ebuild that are replaced due to removed use flags.
>>>
>>> Look at the first section of[:]
>>> http://www.gentoo.org/news/en/gwn/20060116-newsletter.xml
>> 
>> As far as I can see this is not mentioned in either this weeks GWN, the
>> portage 2.1 release notes or the 2.1 news page [references]. I'm sure a
>> lot of people running stable don't remember the GWN from January.
>> Shouldn't this be mentioned somewhere now?

Valid point.  An informed Gentoo sysadmin is an effective Gentoo sysadmin.
Now sometimes I think Gentoo users (which are by another name Gentoo
sysadmins) shirk their responsibility to stay informed, but this wouldn't
seem to be one of those cases.  Sure, it was there in January, but
forget the folks who forgot, what about folks who started on Gentoo since
then?  The change should at a minimum be in the release notes.  Additional
coverage would be good, but a responsible admin will certainly read the
release notes for a non-micro upgrade of something as central to system
administration as a package manager, and as this is a non-trivial change,
it should at the very minimum be there.

Or put it this way.  If it was in the release notes and I failed to see
it, I'd consider it my problem (I get to keep the pieces, as  the saying
goes). If things start changing out from under me without notice despite my
reading of such documentation, the problem is with the package and its
documentation, and should be considered a bug.

(FWIW, as a responsible sysadmin, I dealt with the changes when they were
first covered, back in January, so I could rest easy that the changes when
they occurred in the portage I was using wouldn't cause any issues.  See
below.  However, as mentioned, that doesn't do a thing for the poor guy,
responsible or not, who started with Gentoo in February and is still
getting his Gentoo legs under him, only to see all this change without any
warning.)

> And, from a user pov, these changes are difficult to assess. It is not
> obvious what removing mysql, or db, or idn, or gmp might mean,
> especially if the user never put them there in the first place! And, how
> to you explain that openoffice-bin now has -java instead of java? Or,
> why gnupg lost bzip2?

Here I can't agree.  A responsible Gentoo admin will be verifying the USE
flags using --pretend or --ask before every package merge.  As such, (s)he
should be reasonably familiar with them.  Sure, (s)he may not know
specifically what each one does on every package that uses it, but he
should have no more trouble here than with the whole Gentoo concept and
use of USE flags in general.  Portage does a good job of flagging changed
flags in bright yellow.  If an admin isn't familiar with that particular
flag, a quick euse -i  (euse is part of gentoolkit) will reveal both
its purpose, and whether it's a global or local USE flag (and if local,
how common its use is, global can be assumed to be quite commonly used
or it wouldn't be global). From there, it's the bog standard process of
deciding whether you want the flag on or off in make.conf, and dealing
with exceptions as they come up in package.use.  As I said, any
responsible Gentoo sysadmin (that is, Gentoo user by another name) should
be comfortable with this process.  If they aren't, there's the entirely
logical question of why they are using Gentoo in the first place.

> Too many things occurred without explanation.

Agreed.

> What _I_ ended up doing was hacking make.conf and essentially put back
> all the changed -use flags until I could examine this further.

Well, aside from the fact that a responsible sysadmin (well, if he had
been here since January to have read the coverage back then) would have
already verified his USE flags without the benefit of use.default  (I long
ago did a search on all such files in the tree, deleted the ones I knew
weren't going to be part of my profile, backed up the others, and did an
emerge --pretend --newuse to figure out what I needed to fix, then after
fixing them added them to the rsync-exclude list so syncs wouldn't be
bringing them back), what you did was basically what any sane Gentoo admin
would have done.  No big deal.  Dealing with USE flags, both with the
initial merge of the package, and when any change, is simply part of the
job.  IMO, a Gentoo admin unprepared to deal with that part of the job
should be asking himself serious questions about why he's using Gentoo in
the first place, and if another distribution wouldn't be better suited to
his wanting the distribution to make those decisions for him.  There are
certainly many distributions out there willing to do so, but part of
Gentoo's

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

[Duncan]

Chris Gianelloni <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], 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: A heretical thought? Blessing project sunrise as an almost-fork.

[Richard Fish]

On 6/13/06, Peter <[EMAIL PROTECTED]> 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

[gentoo-dev] Re: backups: remove Portage cruft?

[Duncan]

Chris Gianelloni <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on  Tue,
13 Jun 2006 09:38:42 -0400:

> You don't need to backup any of it.  Everything under /usr/portage can
> be regained with an "emerge --sync" except distfiles, and those are
> redownloaded the next time you merge a package that requires it.

... And package files, if in the default location.  Someone using
FEATURES=buildpkg could understandably be rather peeved if due to failure
to back that up (because it wasn't said to be necessary), it wasn't there
when it actually came time to use that backup.



-- 
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 + (UTC) "Duncan"
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], 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] 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

[gentoo-dev] Maintainer wanted for app-text/wv2

[Sune Kloppenborg Jeppesen]

app-text/wv2 is without an active maintainer and has an open security bug 
#136759

https://bugs.gentoo.org/show_bug.cgi?id=136759

Anyone willing to take care of this package in the future, please update 
metadata/herd info and CC yourself on the bug.

-- 
Sune Kloppenborg Jeppesen (Jaervosz)
Gentoo Linux Security Team
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Maintainer wanted for app-text/wv2

[Martin Ehmsen]

Sune Kloppenborg Jeppesen wrote:
app-text/wv2 is without an active maintainer and has an open security bug 
#136759


https://bugs.gentoo.org/show_bug.cgi?id=136759

Anyone willing to take care of this package in the future, please update 
metadata/herd info and CC yourself on the bug.


This seems like a package that is easy to maintain, and since the 
security bug is easily dealt with by a version bump and stabilization, I 
guess text-markup absorbs it.


Martin Ehmsen
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Did portage 2.1 change default use flags?

[Alec Warner]

Duncan wrote:

Peter <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on  Tue, 13
Jun 2006 12:57:08 -0400:



On Tue, 13 Jun 2006 18:08:03 +0200, Bo Ørsted Andresen wrote:



On Monday 12 June 2006 12:57, Bo Ørsted Andresen wrote:


On Monday 12 June 2006 12:42, Peter wrote:


All of a sudden, emerge -uD --newuse world is showing dozens of
ebuild that are replaced due to removed use flags.


Look at the first section of[:]
http://www.gentoo.org/news/en/gwn/20060116-newsletter.xml


As far as I can see this is not mentioned in either this weeks GWN, the
portage 2.1 release notes or the 2.1 news page [references]. I'm sure a
lot of people running stable don't remember the GWN from January.
Shouldn't this be mentioned somewhere now?



Maybe this corrected an error from prior ebuilds or portage versions.
But, from where I sit, the cure seems worse than the original problem.



How so?  It's making Gentoo more Gentoo-like.  Taking a decision that
/was/ being made and changed arbitrarily based on what was merged, by the
distribution, and putting that decision back squarely in the hands of the
folks who have, by making the Gentoo choice in the first place, signified
that they WANT the choice of making that decision, AND the responsibility
for doing so.

As I've said, this absolutely should be in the release notes, and
preferably should be in other coverage of the  portage 2.1 changes as
well.  There is IMO no excuse for it not being there.  However, also
IMO, it shouldn't be a problem for any responsible Gentoo sysadmin, other
than asking the very reasonable question of why the change isn't covered
in the documentation.  Other than that, it's simply doing the bog-standard
coping with routine USE flag changes, only there's a few more of them to
deal with than "routine" in this case.

This was an oversight on our part.  I have added a snippet to the 
release notes:


For the lazy.
* autouse (use.defaults) has been deprecated by specifying USE_ORDER in 
make.defaults.  Users may still turn this back on by specifying 
USE_ORDER="env:pkg:conf:auto:defaults" in make.conf.  Interested in 
figuring out what use flags were turned off?  Check out 
/usr/portage/profiles/base/use.defaults and other use.defaults files 
that correspond to your profile.


If I have some spare time I will add a FAQ question on the project page 
as well.  Once again I apologize for this.  It was actually done quite 
some time ago (January?) and no one ever added it and it was basically 
forgotten.

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

Re: [gentoo-dev] Re: Did portage 2.1 change default use flags?

[Wernfried Haas]

On Wed, Jun 14, 2006 at 09:42:48AM -0400, Alec Warner wrote:
> I have added a snippet to the release notes: [..]

Thank you.

cheers,
Wernfried

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


pgpLyJMbWNneJ.pgp
Description: PGP signature

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

[Chris Gianelloni]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Did portage 2.1 change default use flags?

[Bo Ørsted Andresen]

On Wednesday 14 June 2006 14:42, Alec Warner wrote:
> * autouse (use.defaults) has been deprecated by specifying USE_ORDER in
> make.defaults.  Users may still turn this back on by specifying
> USE_ORDER="env:pkg:conf:auto:defaults" in make.conf.  Interested in
> figuring out what use flags were turned off?  Check out
> /usr/portage/profiles/base/use.defaults and other use.defaults files
> that correspond to your profile.

I'm sorry, but that doesn't make a lot of sense. use.defaults hasn't been 
deprecated. The January GWN [1] specified this much more clearly. Also 
checking out the use.defaults files won't tell you what was turned off unless 
you have an old version to diff it against. 'emerge -uvpDN world' will, 
however.

[1] http://www.gentoo.org/news/en/gwn/20060116-newsletter.xml

-- 
Bo Andresen


pgp8UyshCu0GR.pgp
Description: PGP signature

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

[Chris Gianelloni]

On Wed, 2006-06-14 at 08:38 +0200, Kevin F. Quinn wrote:
> On Tue, 13 Jun 2006 23:19:51 +0100
> Stuart Herbert <[EMAIL PROTECTED]> 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


signature.asc
Description: This is a digitally signed message part

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

[Chris Gianelloni]

On Wed, 2006-06-14 at 08:52 +, 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


signature.asc
Description: This is a digitally signed message part

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

[Chris Gianelloni]

On Wed, 2006-06-14 at 10:09 +0100, Ciaran McCreesh wrote:
> On Wed, 14 Jun 2006 08:52:37 + (UTC) "Duncan"
> <[EMAIL PROTECTED]> 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


signature.asc
Description: This is a digitally signed message part

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

[Henrik Brix Andersen]

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 <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpFtgAb8bneR.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Did portage 2.1 change default use flags?

[Alec Warner]

Bo Ørsted Andresen wrote:

On Wednesday 14 June 2006 14:42, Alec Warner wrote:


* autouse (use.defaults) has been deprecated by specifying USE_ORDER in
make.defaults.  Users may still turn this back on by specifying
USE_ORDER="env:pkg:conf:auto:defaults" in make.conf.  Interested in
figuring out what use flags were turned off?  Check out
/usr/portage/profiles/base/use.defaults and other use.defaults files
that correspond to your profile.



I'm sorry, but that doesn't make a lot of sense. use.defaults hasn't been 
deprecated. The January GWN [1] specified this much more clearly. Also 
checking out the use.defaults files won't tell you what was turned off unless 
you have an old version to diff it against. 'emerge -uvpDN world' will, 
however.


No, we didn't change the use.defaults files at all, they are the same 
and will stay the same for quite some time.  However we no longer add 
those use flags to the USE stack, ergo, look in use.defaults to see what 
could be affecting you.  I think people already know to use newuse to 
see use flag changes, but this tells them why there are changes.




[1] http://www.gentoo.org/news/en/gwn/20060116-newsletter.xml




--
gentoo-dev@gentoo.org mailing list

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

[gentoo-dev] Re: Re: Did portage 2.1 change default use flags?

[Peter]

On Wed, 14 Jun 2006 10:59:12 -0400, Alec Warner wrote:

> Bo Ørsted Andresen wrote:
>> On Wednesday 14 June 2006 14:42, Alec Warner wrote:
>> 
>>>* autouse (use.defaults) has been deprecated by specifying USE_ORDER in
>>>make.defaults.  Users may still turn this back on by specifying
>>>USE_ORDER="env:pkg:conf:auto:defaults" in make.conf.  Interested in
>>>figuring out what use flags were turned off?  Check out
>>>/usr/portage/profiles/base/use.defaults and other use.defaults files
>>>that correspond to your profile.
>> 
>> 
>> I'm sorry, but that doesn't make a lot of sense. use.defaults hasn't
>> been deprecated. The January GWN [1] specified this much more clearly.
>> Also checking out the use.defaults files won't tell you what was turned
>> off unless you have an old version to diff it against. 'emerge -uvpDN
>> world' will, however.
> 
> No, we didn't change the use.defaults files at all, they are the same and
> will stay the same for quite some time.  However we no longer add those
> use flags to the USE stack, ergo, look in use.defaults to see what could
> be affecting you.  I think people already know to use newuse to see use
> flag changes, but this tells them why there are changes.
> 

The use.default file in default-linux is now empty. The one in base gives
you nothing to compare it against. Was there another file you meant?

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Did portage 2.1 change default use flags?

[Alec Warner]

Peter wrote:

On Wed, 14 Jun 2006 10:59:12 -0400, Alec Warner wrote:



Bo Ørsted Andresen wrote:


On Wednesday 14 June 2006 14:42, Alec Warner wrote:



* autouse (use.defaults) has been deprecated by specifying USE_ORDER in
make.defaults.  Users may still turn this back on by specifying
USE_ORDER="env:pkg:conf:auto:defaults" in make.conf.  Interested in
figuring out what use flags were turned off?  Check out
/usr/portage/profiles/base/use.defaults and other use.defaults files
that correspond to your profile.



I'm sorry, but that doesn't make a lot of sense. use.defaults hasn't
been deprecated. The January GWN [1] specified this much more clearly.
Also checking out the use.defaults files won't tell you what was turned
off unless you have an old version to diff it against. 'emerge -uvpDN
world' will, however.


No, we didn't change the use.defaults files at all, they are the same and
will stay the same for quite some time.  However we no longer add those
use flags to the USE stack, ergo, look in use.defaults to see what could
be affecting you.  I think people already know to use newuse to see use
flag changes, but this tells them why there are changes.




The use.default file in default-linux is now empty. The one in base gives
you nothing to compare it against. Was there another file you meant?



There is no comparison, use.defaults IS the file.  Look at it.

USE Flagpackage implies USE
---
aalib   media-libs/aalib
acl sys-apps/acl
adnsnet-libs/adns
afs net-fs/openafs
alsamedia-libs/alsa-lib
artskde-base/arts
audiofile   media-libs/audiofile
bash-completion app-shells/bash-completion

and so on.  If package is installed, the corresponding flag is turned on 
"automatically" hence autouse.  This no longer occurs in 2.1.


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

Re: [gentoo-dev] Re: Did portage 2.1 change default use flags?

[Zac Medico]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alec Warner wrote:
> Interested in
> figuring out what use flags were turned off?  Check out
> /usr/portage/profiles/base/use.defaults and other use.defaults files
> that correspond to your profile.

It's probably easier to let portage do the work and run `env USE_ORDER=auto 
portageq envvar USE`.  On Sunday I added an einfo to the ebuild that recommends 
this.  I also posted the information in a forums thread:

http://forums.gentoo.org/viewtopic-p-3380763.html

Zac 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEkEGz/ejvha5XGaMRAnqOAKDqqAYYKCEtQJSVeOJoF06MlZRfYQCgk1oP
XTo2MZkiP+uIUPSm9j95OKk=
=GqK8
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Did portage 2.1 change default use flags?

[Bo Ørsted Andresen]

On Wednesday 14 June 2006 18:40, Alec Warner wrote:
> There is no comparison, use.defaults IS the file.  Look at it.
>
[SNIP]
>
> and so on.  If package is installed, the corresponding flag is turned on
> "automatically" hence autouse.  This no longer occurs in 2.1.

Ah, now I get it. I didn't realize that. The FAQ question you mentioned on the 
project page would be a good idea, if you get the time. And thanks for adding 
it. :)

-- 
Bo Andresen


pgpmie6bTp5Dc.pgp
Description: PGP signature

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

[Jakub Moc]

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 
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.  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  unless
you actually maintain it. Thanks.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 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   ;)



signature.asc
Description: OpenPGP digital signature

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 <[EMAIL PROTECTED]> wrote:

> This new terminology plain sucks. If you are sticking games into
>  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]

Stephen Bennett wrote:
> On Wed, 14 Jun 2006 20:01:04 +0200
> Jakub Moc <[EMAIL PROTECTED]> wrote:
> 
>> This new terminology plain sucks. If you are sticking games into
>>  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:[EMAIL PROTECTED]
 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   ;)



signature.asc
Description: OpenPGP digital signature

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 <[EMAIL PROTECTED]> 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 , like, say,
. In the example that sparked this,  is games and
 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.

[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 <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Duncan]

Chris Gianelloni <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], 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]

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



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Re: Did portage 2.1 change default use flags?

[Duncan]

Peter <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on  Wed, 14
Jun 2006 11:29:06 -0400:

> The use.default file in default-linux is now empty. The one in base gives
> you nothing to compare it against. Was there another file you meant?

You don't /need/ another file to compare it against.  That you seem to
think you do implies you don't quite understand how the thing worked,
which explains why you don't see the problem with it.

use.defaults consists of a list of pairs of (normally unset, therefore off)
USE flags and packages.  If the corresponding package is merged and
defaults is in the USE.ORDER list, the flag will now default to on instead
of off.  (As it is normally last in the USE.ORDER list, specific settings
higher in the list, including those made by the user, will of course
override this, as one might expect.)

Thus, you don't need another file to compare use.defaults against, as if
the package triggering the USE flag is merged, the default is on, while if
it's not, the default is off.  Thus, there is no other file to compare it
against, only the list of your merged packages.  The use.defaults file(s)
simply list the packages that trigger the USE flags.  That's all.

The problem with this approach is that the USE flags end up changing
unexpectedly under a user's nose (sound familiar?  understand why that's a
problem?  THOUGHT so!) based on what's merged.  Note that USE flags are
only for OPTIONAL dependencies.  Thus, we have a scenario where a bunch of
packages with OPTIONAL dependencies on something, thus with it as a USE
flag, are merged, then something comes along with a NON-OPTIONAL
dependency on the same package and merges it.  Suddenly and without user
intervention, the USE flag changes from OFF by default to ON by default,
and all those previous packages merged with it off now show up in --newuse
to be remerged!

The most direct solution to the problem is to take defaults out of
USE.ORDER, so use.defaults is no longer factored in.  Altho there's going
to be a bit of initial pain for users who hadn't examined their use flags
(as I contend a responsible admin will have done), for new users and after
the initial adjustment by old users, USE flags will now actually be
normally deterministic -- they'll only change when a user changes them (or
when a profile has reason to do so, and that happens only for a very good
reason with existing profiles, so it would normally only happen when a
user changed his profile).  MUCH better, as the user doesn't have to worry
about USE flags changing out from underneath him.  Given your complaint
about the changes you experienced, I think you'll agree that having them
change out from underneath you isn't all that pleasant, so this is a
needed change.  The only problem was that it wasn't properly documented,
but that  has been taken care of now as well.



-- 
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: Did portage 2.1 change default use flags?

[Peter]

On Wed, 14 Jun 2006 19:47:42 +, Duncan wrote:

> Peter <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on  Wed, 14
> Jun 2006 11:29:06 -0400:
> 
>> The use.default file in default-linux is now empty. The one in base
>> gives you nothing to compare it against. Was there another file you
>> meant?
> 
> You don't /need/ another file to compare it against.  That you seem to
> think you do implies you don't quite understand how the thing worked,
> which explains why you don't see the problem with it.
> 

I responded to this sentence:
>>Interested in
>>figuring out what use flags were turned off?  Check out
>>/usr/portage/profiles/base/use.defaults and other use.defaults files
>>that correspond to your profile.

I read that to mean "compare the base use.default with the other
use.defaults file and note the differences." It could also read "look at
the base use.default as well as the other use.default files." It was a
case of semantics and an ambiguously worded sentence, not my inability to
comprehend use.defaults.


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

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

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

[Jakub Moc]

Stephen Bennett wrote:
> On Wed, 14 Jun 2006 20:21:42 +0200
> Jakub Moc <[EMAIL PROTECTED]> 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 , like, say,
> . In the example that sparked this,  is games and
>  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  tag and
 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
 (if there's any in metadata.xml), and get CCed to 
(if there's any in metadata.xml). If there's no , whoever is
in  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:[EMAIL PROTECTED]
 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   ;)



signature.asc
Description: OpenPGP digital signature

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 <[EMAIL PROTECTED]> 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 
> tag and  only. Are you claiming that they are unmaintained?

No; read the second paragraph.

> To make it pretty clear and explicit - bugs gets assigned to
>  (if there's any in metadata.xml), and get CCed to 
> (if there's any in metadata.xml). If there's no , whoever
> is in  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

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 [EMAIL PROTECTED] 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
>  (if there's any in metadata.xml), and get CCed to 
> (if there's any in metadata.xml). If there's no , whoever is
> in  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: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.

[Chris Gianelloni]

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


  games
  [EMAIL PROTECTED]
  Gentoo Games Team

/proj/en/desktop/games/index.xml


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


signature.asc
Description: This is a digitally signed message part

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

[Chris Gianelloni]

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


signature.asc
Description: This is a digitally signed message part

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

[Chris Gianelloni]

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


signature.asc
Description: This is a digitally signed message part

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

[Chris Gianelloni]

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


signature.asc
Description: This is a digitally signed message part

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

[Chris Gianelloni]

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


signature.asc
Description: This is a digitally signed message part

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

[Chris Gianelloni]

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


signature.asc
Description: This is a digitally signed message part

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

[Chris Gianelloni]

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 , like, say,
> > . In the example that sparked this,  is games and
> >  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  tag and
>  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
>  (if there's any in metadata.xml), and get CCed to 
> (if there's any in metadata.xml). If there's no , whoever is
> in  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


signature.asc
Description: This is a digitally signed message part

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 <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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 [EMAIL PROTECTED] 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
> >  (if there's any in metadata.xml), and get CCed to 
> > (if there's any in metadata.xml). If there's no , whoever is
> > in  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


signature.asc
Description: This is a digitally signed message part

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

[Dan Meltzer]

On 6/14/06, Chris Gianelloni <[EMAIL PROTECTED]> 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 , like, say,
> > . In the example that sparked this,  is games and
> >  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  tag and
>  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
>  (if there's any in metadata.xml), and get CCed to 
> (if there's any in metadata.xml). If there's no , whoever is
> in  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]

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



signature.asc
Description: OpenPGP digital signature

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" <[EMAIL PROTECTED]> 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"
<[EMAIL PROTECTED]> 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

[gentoo-dev] Herds suck, fix them

[Alec Warner]

So apparently they suck, anyone have a new shiny idea on how to group
packages and maintaining developers?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Mike Frysinger]

On Monday 12 June 2006 08:23, Chris Gianelloni wrote:
> On Sat, 2006-06-10 at 19:56 -0400, Mike Frysinger wrote:
> > On Saturday 10 June 2006 10:29, Chris Gianelloni wrote:
> > > On Fri, 2006-06-09 at 18:34 -0400, Mike Frysinger wrote:
> > > > On Friday 09 June 2006 16:35, Chris Gianelloni wrote:
> > > > > This is the "official" (hehe) request for comments on making a
> > > > > policy of how to handle ebuilds than can be used for either client
> > > > > or server and how to allow for building client-only.
> > > >
> > > > rather than moving to some sort of policy that satisfies no one
> > > > completely and we'll have to back out of later, why dont we wait
> > > > until portage can give us proper support for USE=client/server
> > >
> > > Got an ETA?
> > >
> > > The situation we have now is confusing, at best, to our users, and
> > > something really should be done to resolve it.
> >
> > sure, dont add support for the flags at all at this point, problem solved
>
> You apparently missed that there already are packages in the tree using
> these flags, as well as minimal.

not really ... i'm fully aware of USE=server since ive used it myself

USE=client however doesnt exist, so you'd be incorrect there

> This inconsistent usage is what I was trying to solve in the first
> place.

with a stop gap measure ... i dont think this stop gap effort is worth the 
extra time, especially since it'll be simply backed out of down the road
-mike


pgpMPLCpqCra8.pgp
Description: PGP signature

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Mike Frysinger]

On Saturday 10 June 2006 10:42, Ciaran McCreesh wrote:
> On Sat, 10 Jun 2006 10:56:48 +0200 Patrick Lauer <[EMAIL PROTECTED]>
> | >  When someone contacts GWN to have
> | > something corrected, it would be appreciated were the GWN staff to
> | > at least deign to acknowledge receipt, even if for some reason they
> | > choose not to honour the corrections or post a retraction (although
> | > refusing to publish corrections is extremely insulting to those
> | > wronged).
> |
> | The reason for that is that the GWN is mostly sent out by mail. This
> | makes corrections a bit more difficult, but I think having a sane
> | policy for that would be helpful.
>
> Publish a 'corrections' section in the next edition?

and fix the original
-mike


pgpfL0MzqlxZ7.pgp
Description: PGP signature

Re: [gentoo-dev] Herds suck, fix them

[Lance Albertson]

Alec Warner wrote:
> So apparently they suck, anyone have a new shiny idea on how to group
> packages and maintaining developers?

I suggest we create a murder of developers! Then we can be cool and not
suck! :-)

/me goes back into lurking mode

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

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

[Mike Frysinger]

On Monday 12 June 2006 09:28, Henrik Brix Andersen wrote:
> On Thu, Jun 01, 2006 at 11:02:46AM +, Mike Frysinger wrote:
> > This is your monthly friendly reminder !  Same bat time (typically the
> > 2nd Thursday once a month), same bat channel (#gentoo-council @
> > irc.freenode.net) !
>
> I've learned that the Gentoo Council meeting has been pushed to the
> 3rd Thursday of June - meaning 2006-06-15. At which time will the
> meeting be held? 1900 UTC or 2000 UTC?

1900 UTC (1400 EST)
-mike


pgpFoIk943LNb.pgp
Description: PGP signature

Re: [gentoo-dev] backups: remove Portage cruft?

[Mike Frysinger]

On Monday 12 June 2006 19:28, Alec Warner wrote:
> Joerg Plate wrote:
> >>Do make sure you back up the base /var/cache/edb/
> >
> > Why? Anything in /var/cache doesn't need to be in a backup,
> > because it can be generated when necessary (in theory...)
>
> in theory, yes;

in practice, this needs to be a yes too

> in practice there are a couple of files you may not want 
> to destroy (mtimedb, counter)

those files are very helpful sure, but portage needs to be able to sanely 
recover if they go bye bye
-mike


pgpaF7y79APCR.pgp
Description: PGP signature

Re: [gentoo-dev] Herds suck, fix them

[Mike Frysinger]

On Thursday 15 June 2006 00:31, Alec Warner wrote:
> So apparently they suck, anyone have a new shiny idea on how to group
> packages and maintaining developers?

they work just fine for me
-mike


pgpyOk8hXaUzk.pgp
Description: PGP signature

Re: [gentoo-dev] Profiles Part 2

[Mike Frysinger]

On Monday 12 June 2006 16:58, Stephen Bennett wrote:
> I am also aware that this falls roughly under what the Council was
> asked to discuss in its June meeting, but since that seems to have not
> happened, I'm bringing it up anyway, since I would like to get
> something done here.

we meet Jun 15th this month
-mike


pgpg27LR2RpBW.pgp
Description: PGP signature

Re: [gentoo-dev] Profiles Part 2

[Mike Frysinger]

On Monday 12 June 2006 17:15, Brian Harring wrote:
> B) council
> outcome tomorrow (no point in changing it till they've weighed in on
> the whole enchilada).

not really

it makes people dropping in their own stuff easier and doesnt adversely affect 
the portage tree in any way
-mike


pgpouPWaF83iL.pgp
Description: PGP signature

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 games 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 games 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] Herds suck, fix them

[Kevin F. Quinn]

On Thu, 15 Jun 2006 00:31:41 -0400
Alec Warner <[EMAIL PROTECTED]> wrote:

> So apparently they suck, anyone have a new shiny idea on how to group
> packages and maintaining developers?

We could be boring and change "herd" to "packagegroup".

We could require that a herd mail alias be maintained for every herd,
with the same name as the herd, such that the herd alias lists the
maintainers of all packages in the herd.  The list could include
project aliases and/or individuals. Then bug-wranglers can assign to
the relevant herd alias if no maintainer is listed in metadata, and let
the herd maintainers re-assign amongst themselves if appropriate.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Herds suck, fix them

[Mike Frysinger]

On Thursday 15 June 2006 02:33, Kevin F. Quinn wrote:
> We could require that a herd mail alias be maintained for every herd,
> with the same name as the herd, such that the herd alias lists the
> maintainers of all packages in the herd.

this would be useful regardless
-mike


pgpNaJsppizDH.pgp
Description: PGP signature