Re: [gentoo-dev] Please use land-misc herd where appropriate! No no-herd madness!!!

[Ned Ludd]

First thank you for your in depth explanation. 
Unfortunately I don't think we are any closer to being able to solve the
problem of when an ebuild does not fit into any existing herds or when a
maintainer is not apart of what would perhaps be a fitting herd. 

So I'd like to semi (un)officially like to propose a new herd called
'no-herd' in which either every dev automatically becomes apart of or
that nobody is apart of. Said herd will not have a bugzilla email alias
or a mailing list unless we have a maintainers motivated enough to
actually want to get mail for no-herd. no-herd will have no lead and
would simply become the official preferred placeholder for metadata.xml
files till such time as a fitting herd is found, or if a fitting herd
exists but a maintainer is not apart of the existing herd and or a dev
does not want to be apart of a herd for the sake of an ebuild or two
which (s)he can maintain better than an existing herd.

As we saw on (I think) this mailing list not so long ago devs were
assigning ebuilds to herds which they were not apart of and this caused
problems for people of those herds.

Not having this placeholder herd in my minds would result in less
metadata files being added to the tree or more devs declaring themselves
as the herd.

On Fri, 2004-10-08 at 02:33, George Shapovalov wrote:
> Ok, to ease this off I should state up front that, while I strongly feel that
> we should adhere to existing regulations and common sense as much as
> possible, practical considerations (see end of this message) do not allow to
> just outright kill no-herd entries which we accumulated plenty already. Thus
> please observe the wording I used in my original message:
> > > This is a big fat reminder that no-herd is really against the policy and
> > > should not be used
> > > *if you can find appropriate herd*!!
> (see the emphasis)
>
>
> However since this is such a hot topic I believe a short historical excurse is
> in order.
>
> > Where is this policy? (url please!)
> The policy originated way back when metadata were only discussed. I believe
> most general and strict formulation was in one of Daniel (Robbins)'s emails
> back then. Unfortunately many procedural "regulations" were not properly
> written down (glep's were not around either), so best coverage would be in
> the mailing list archives which we don't have, least for gmane.org ones if
> they go that far back.
>
> This particular point, however, is covered in devrel handbook, metadata page:
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4#doc_chap2
>
> Particular citation (skipping tags):
> "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. Besides being member of a herd, a package can also be maintained
> directly."
>
> In other words:
> every package *must* belong to a herd (and may belong to multiple herds)
> Additionally a package *may* have a maintainer
>
> The rationale being (and that was touched upon in those old discussions
> multiple times) that there always is a fall-back. Thus strictly speaking
> no-herd is against the policy as this is not a valid herd (or even not a herd
> at all).
>
> Observe also that no-herd is nowhere to be found on that page. This is not an
> omission but rather a "simptome". There was no mention of no-herd entries
> when the policy was developed and metadata format worked out. no-herd entries
> started to appear later on without much fuss. They were noticed and the issue
> brought up and according to what I remember no real decision was made on
> them. The general feeling I have is that they were "tolerated" by more strict
> policy followers with the understanding that this is a temporary measure and
> we should try to minimize their use and get rid of them whenever possible.
>
> Of course nothing is more permanent than a temporary solution :). So, these
> are the practical considerations I cited in the opening. One possible way to
> avoid no-herd entries is to create a more generic herd that would accommodate
> various "smaller breads" that did not warrant a herd of their own. Multiple
> developers may sign up. Individual involvement may be regulated by the <role>
> tags in herds.xml and/or <maintainer> entries in metadata.xml (observe
> and/or, this does not involve data duplication).
>
> Again, issue at stake here is insuring that no package remains unsupported in
> the case of its maintainer departure, - a holy grail of our herding attempt
> which, sadly, is not likely to be finished any time soon.
>
> Ok, I hope this explains situation a bit. To completely close the issue I just
> want to (again) note that main emphasis of my original message was to bring
> attention of maintainers of packages that could fall under lang-misc.
> I modified metadata of a few such packages replacing no-herd with lang-misc
> (of the latest erlang comes to mind) and removing maintainer entry listing
> myself (I am on that herd). However I left the 2nd maintainer entry intact
> and did not add these devs to lang-misc in herds.xml (which I would though
> moderately suggest ;), although I believe this should be at the discretion of
> the involved dev).
>
> George
>
>
>
> --
> gentoo-dev@g.o mailing list
-- 
Ned Ludd <solar@g.o>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer