On Sat, Sep 27, 2014 at 6:13 PM, Tom Wijsman <tom...@gentoo.org> wrote: > The question becomes "does every herd want to become a (sub)project?". >
So, there was some discussion on -dev, apparently some discussion I wasn't a part of, and some that I was (such is the nature of IRC). I think it would make sense to take a step back and ask what we'd do if we were starting with a blank slate. Aliases, herds, and projects are all ways of grouping people, but they are used in different ways, sometimes. My real problem with herds isn't the idea of having more than one way to group people. My real issue is that we have several ways of grouping people and no consistent way of doing so. You have to look in different places to find out who is on an alias/herd/project. We have cases where more than one of these are loosely associated, but membership is inconsistent. We have inactive examples of all three. So, let's step back and think about why developers would want to be part of a group, forget about what we call these groups, and then figure out what kind of model makes the most sense and how to get there. In the final design we might want to not split groupings up all over the place (wiki vs herds.xml vs alias files that nobody but devs can read). So, one level of association might be registering an interest - such as what is sometimes done with a mail alias. A developer, or even a non-developer, might want to be informed about what is going on with a package or group of packages, but they are not making any kind of commitment to actually taking care of them. The opposite would be a project as defined in GLEP 39. This is a formal association of developers that elects a lead, and acts as a unit. The project could establish policies and it is generally expected that they be followed (we can escalate to the Council if there is a problem). This is especially valuable for core dependencies like toolchain, frameworks, etc where good planning makes everybody's lives easier. Then you have groups of people who sort-of maintain peripheral packages, which is what I think is what many herds are (but their use is totally inconsistent, so this isn't true everywhere). My issue with this sort of thing is that it is really hard to tell if a package is actually maintained. Devs basically drop-in to scratch an itch and then abandon things. Emails to aliases get ignored, since nobody in particular is in charge. That is my main issue with herds - they're dumping grounds for bugs that nobody seems to care about, at least in some cases. With a project you can at least ask "have you selected a lead in the last year" and get some kind of pulse on activity. Herds are nice from the standpoint that they cost nothing to maintain, but that also means that there is no way to gauge commitment. Having an election is a big like some proposals to charge $1 to register a copyright renewal - it isn't about the cost so much as just making somebody actually do something to prevent de-listing. I guess my question is when is something like a herd the best solution to a problem, and what is that problem? I don't want to change for the sake of change. If we stay the same I'd like it to be because what we're doing actually makes sense. If we do keep something like herds, I'd still consider some way to consolidate herd/project membership lists so that tools can scan a single location. Whether a group is a herd/project/alias could be an attribute. This is no different than not having separate ldap servers for devs vs staff vs infra, and so on. -- Rich
