On Sat, 27 Sep 2014 18:45:12 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> 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). Knowledge codification is nice; otherwise, this is just-another-thread. > 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. Looking at a blank slate hides the origin of these ways. Aliases set up mails on the infrastructure. Herds assign multiple relevant maintainers to multiple packages. Projects are a need for serious organization. This is what we have ended up with starting from that blank slate. > 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. Aliases are there to support herds or projects, it shouldn't be seen as a separate way to group people. The other groups are straight froward; herds for groups that maintains packages, projects for groups that take on a serious project. Projects that take on packages have created herds (eg. proxy-maintainers, ...); so, this is or can be consistent. > We have inactive examples of all three. Yes, they capture inactivity; iotw, what's in a herd/project name? :) > 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). If read and compared correctly, the origin paragraph is a TL;DR to this. > 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. +1, as some of us revealed; but note that projects can also hide abandoned efforts, eg. the Council recently cleaning old dead projects. > 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. There are projects which haven't selected a new lead for years ... > 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. ... thus it only works when some entity external to the project forces new lead elections; as otherwise, projects have no such $1 ping-pong. > I guess my question is when is something like a herd the best solution > to a problem, and what is that problem? Unnecessary stuff: Organization, knowledge codification, time, work, ... > 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. It made sense to me from day #1 of contributing to Gentoo; it surprises me that this all of the sudden is assumed to be a problem, it makes me rather skeptic about whether a structure change is needed. > 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. That would be nice.
