| 1 |
On 6/14/06, Chris Gianelloni <wolf31o2@g.o> wrote: |
| 2 |
> http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4 |
| 3 |
> |
| 4 |
> Specifically the listing for the herd tag. |
| 5 |
> |
| 6 |
> Just because people are doing things *wrong* doesn't mean that there |
| 7 |
> isn't a defined manner in which things should be done. |
| 8 |
|
| 9 |
>From the document you've referenced: |
| 10 |
|
| 11 |
"The metadata.xml file has as its purpose to give extra information |
| 12 |
about ebuilds. The metadata.xml file should exist in every package |
| 13 |
directory. A skel file can be found as skel.metadata.xml in the |
| 14 |
portage tree." |
| 15 |
|
| 16 |
That clearly doesn't say that every package _requires_ a metadata.xml |
| 17 |
file. The word used is "should", not "must". Also: |
| 18 |
|
| 19 |
"<herd> There must at least be one herd subtag. The contents of this |
| 20 |
tag should be the name of be a herd as specified in the herds.xml |
| 21 |
file. It must occur at least once. " |
| 22 |
|
| 23 |
Again, the word used is "should", and not "must". |
| 24 |
|
| 25 |
I'm sorry, but I do feel that your interpretation of the rules, on |
| 26 |
this point, isn't quite right. There _is_ no requirement that games |
| 27 |
added to the tree _have_ to be put into the games herd - just like |
| 28 |
there's no requirement that all web-based apps _have_ to be put into |
| 29 |
the webapps herd. |
| 30 |
|
| 31 |
Also, see Solar's post in this thread confirming what I'm saying. |
| 32 |
|
| 33 |
> The bugs is assigned to the games team. |
| 34 |
> |
| 35 |
> Should I go and simply ACCEPT every single bug assigned to games in |
| 36 |
> bugzilla, including all of the bug spam that will be caused by it, just |
| 37 |
> to show that we *have* accepted these bugs, and are simply working |
| 38 |
> through them at our own pace? |
| 39 |
|
| 40 |
Yes, that would be sufficient. That shows that the package is yours, |
| 41 |
and then the usual rule (that other developers should not mess with |
| 42 |
your packages) would then apply. That would be in keeping with how |
| 43 |
Gentoo does things, and would remove the need for you to request that |
| 44 |
there's a per-team opt-out clause in Project Sunrise. |
| 45 |
|
| 46 |
It would also leave Project Sunrise (_if_ the Council decides that it |
| 47 |
can go ahead) free to pick up any packages that end up in the |
| 48 |
maintainer-wanted bucket, regardless of what type of package that is. |
| 49 |
|
| 50 |
> You'll only serve to piss me off. |
| 51 |
|
| 52 |
To refer once again to what you like to tell others, maybe you need to |
| 53 |
grow a thicker skin? ;-) |
| 54 |
|
| 55 |
In all seriousness, you're one of the two lead complainants about |
| 56 |
Project Sunrise. You've raised a number of points about Sunrise that |
| 57 |
need debating; you were right to do so, and I don't think anyone feels |
| 58 |
that they shouldn't have been raised. |
| 59 |
|
| 60 |
If you're not going to participate in a debate about those concerns |
| 61 |
without throwing your toys out of the pram, it undermines the |
| 62 |
complaint that you're making. That's plain enough to see by looking |
| 63 |
at the reaction elsewhere in these threads to some of the postings |
| 64 |
from the Sunrise project team, where they've behaved like that. |
| 65 |
|
| 66 |
Best regards, |
| 67 |
Stu |
| 68 |
-- |
| 69 |
gentoo-dev@g.o mailing list |
Archives