On Thu, 15 Jun 2006 15:07:36 +0100
"Stuart Herbert" <[EMAIL PROTECTED]> wrote:

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

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

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

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

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

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

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

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


-- 
Kevin F. Quinn

Attachment: signature.asc
Description: PGP signature

Reply via email to