public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Robin H. Johnson" <robbat2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] The Dreaded herd tag
Date: Fri, 27 Oct 2006 23:46:52 -0700	[thread overview]
Message-ID: <20061028064652.GC7140@curie-int.orbis-terrarum.net> (raw)
In-Reply-To: <200610280811.37656.george@gentoo.org>

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

On Sat, Oct 28, 2006 at 08:11:37AM +0200, George Shapovalov wrote:
> One of the reasons herds were introduced was to explicitly see what packages 
> lack maintenance. It is possible for the ebuild to be in the herd, but be 
> supported by the developer not on the herd. See the <role> tag. Also, there 
> can be one-dev herds.
I have a number of specialized packages that I maintain, such as
sys-block/qla-fc-firmware, that cannot be classified as any existing
herd, and are specialized enough inventing a new herd for them would not
really help.

The point of herds as I saw it originally, was to capture packages that
do NOT have any explicit maintainer. 
	
I've also lost bugs in the past on my packages where I'm not in the
herd, but I am the actual maintainer, because the bug was assigned to
the herd alias, and I didn't see it until several months later, when
somebody finally asked me directly, or reassigned it to me.

For no-herd, I say we should add it to the valid herds list, and
validate all metadata files, and require that if no-herd is used, an
explicit maintainer is present (using the active list of developers).

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

  reply	other threads:[~2006-10-28  6:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-28  2:46 [gentoo-dev] The Dreaded herd tag Alec Warner
2006-10-28  3:17 ` Mike Frysinger
2006-10-28  6:01   ` Doug Goldstein
2006-10-28  6:28     ` George Shapovalov
2006-10-30 16:09       ` Chris Gianelloni
2006-10-30 17:54         ` Jim Ramsay
2006-10-28  3:23 ` David Shakaryan
2006-10-28  6:11   ` George Shapovalov
2006-10-28  6:46     ` Robin H. Johnson [this message]
2006-10-28  7:05       ` Mike Frysinger
2006-10-30 16:16         ` Chris Gianelloni
2006-10-30 16:40           ` George Shapovalov
2006-10-30 16:49             ` Olivier Crete
2006-10-30 17:05               ` George Shapovalov
2006-10-28 18:52     ` Paul de Vrieze
2006-10-29  2:43 ` [gentoo-dev] The (lack of) use of herds Marius Mauch
2006-10-29  3:00   ` Mike Frysinger
2006-10-29  5:26     ` Marius Mauch
2006-10-29  4:27       ` Mike Frysinger
2006-10-29  5:49         ` Alec Warner
2006-10-29 19:11   ` Richard Fish
2006-10-30 10:26     ` Elfyn McBratney
2006-10-30 10:34       ` Roy Marples

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061028064652.GC7140@curie-int.orbis-terrarum.net \
    --to=robbat2@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox