Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Tue, 9 Sep 2014 21:45:49 +0200 Michał Górny mgo...@gentoo.org wrote: Let's keep it short: I think herds don't serve any special purpose nowadays. Their existence is mostly resulting in lack of consistency and inconveniences. Resurrecting this thread per the last council decision: The council is in favor of retiring herds, allowing non-maintainer aliases to exist, and having a way to distinguish between individuals, projects, and non-maintainer aliases in metadata.xml. The details of how to implement this will be worked out in the lists before the next meeting. Whether this gets worked out before the next meeting remains to be seen. However, the council is certainly interested in proposals and discussion. So, herds are going to go away. That leaves maintainers (who can be projects), and aliases (who are NOT maintainers, but can be listed in addition to maintainers). My proposal: For the steady state: 1. For the maintainer tag in metadata, have a type attribute that can be developer, project, or proxy. 2. Add a contacts tag in metadata that takes an email. 3. Package without maintainers (individuals or projects - regardless of presence of aliases) get assigned to maintainer-needed and get treecleaned as usual. I'm also fine with normalizing this and just switching to a contact tag that can have a type of developer, project, proxy, or contact. That is a bigger change. However, it would probably simplify scripting and be a bit cleaner for the long-term. For the transition to the steady state: a. We generate a list of all current herds and email their aliases to see if they want to be converted to a non-maintainer alias, or be disbanded entirely. One reply to the email is enough to keep the alias around, no replies means retirement. b. Anybody in Gentoo can start a project already by following GLEP 39. It is encouraged for these projects to take over existing aliases where they feel it is appropriate. There is no need for all aliases to have a project - just ones that want some kind of structure (ie this is strictly voluntary). When this is done the project will remove the herd from metadata and add the project alias as a maintainer with the agreed-upon tagging. c. We generate a list of all current packages that do not have a maintainer (either one or more individuals or projects (NOT herds)). That gets posted so that individuals can claim them. I suggest not doing the usual treecleaning email since there could be a LOT of them. Or we could do it herd-by-herd over time to ease the load. d. We remove all herds from the existing packages. Where aliases were kept in (a) above they are converted to aliases with appropriate tagging. If no maintainer exists the package is handled per the result of (c). Comments, alternatives, etc? -- Rich
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sun, 28 Sep 2014 00:21:43 +0200 Michał Górny mgo...@gentoo.org wrote: I don't know if you know it but setting up the project wiki page takes less time than reaching into depths of CVS and editing herds.xml. Editing and committing a change to herds.xml takes me less characters than this quoted paragraph, done in under a minute; in comparison, a project wiki page involves a browser, waiting time and more characters. Otherwise, we'll never going to get out of the dumb distinction what project and herd is and isn't, and when one or the other, or both should be used. The documentation and GLEP(s) are pretty clear about that; as for how to use it, that are semantics that are up for the projects and herds. This has worked fine for ages, point me to old threads discussing this if you claim that to not be the case. Recent assumptions make it look like it is a problem, but a history of experience tell us otherwise...
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
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
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Tue, 9 Sep 2014 21:45:49 +0200 Michał Górny mgo...@gentoo.org wrote: Hello, Let's keep it short: I think herds don't serve any special purpose nowadays. Their existence is mostly resulting in lack of consistency and inconveniences. In particular: 1. We have two different tags in metadata.xml that serve a similar purpose -- herd/ and maintainer/, with herd/ being less descriptive. For this reason, sometimes herd's associated e-mail is listed as maintainer/, and sometimes even the same thing is listed using both tags. Herds are groups of people that the Gentoo Project knows about. There may be other aliases, but these particular ones are bound to a @gentoo.org alias. That is what the herd tags convey. In April 2008 we came to some sort of agreement about the way bugs are assigned (first maintainer is assignee, rest is CC'd, first herd is assignee when no maintainer is mentioned) and that works quite well (especially because the assignee is now not the person blamed for a bug report). A herd is a group of people, and a maintainer is not. If a new developer Devon comes along and is allowed to choose a nick like gentoo-devs (he considers himself a member of Gentoo (wat?) and Devs is what everyone already calls him), then the difference in tags should make a clear distinction: herdgentoo-devs/herd !-- This is a group of people -- maintaineremailgentoo-devs/email/maintainer !-- This speaks for itself -- If there is any lack of clarity here, herd members should clear up which is which. As the way herd and maintainer tags are listed in metadata.xml is important, people have got creative with that format, and that's how we ended up reading this thread. We could change that first, and simply change the rules for bug assignment: 1) First herd or maintainer is the Assignee. 2) The rest is CC'd. People will still insist on adding comments and attributes that state exceptions, but that's fine. 2. The common use of herd/ and maintainer/ thingies forces a particular maintainership model. In particular, we always assume maintainer/ comes first, and herd/ serves as a backup. You can't properly say otherwise using both tags. How is that an inconvenience (since it is done consistently)? It's good to know whether you are addressing a single individual or a group. Conversely it is already good practice to not post to mailing lists and use the bug tracker in the name of a whole team (there have been instances where someone was accidentally logged in under a herd title - that's a bad thing). 3. The project member and herd member lists are constantly outdated. In fact, most of the herds don't even list members -- just point out to outdated project pages :). So these should be automagically updated to reflect the alias' list of real e-mail addresses? Sure, it's inconvenient the way it is now (and has been for years), but that doesn't mean we should drop herds altogether. 4. The whole indirection is just irritating. You can't assign a bug using metadata.xml without fetching herds.xml that's in a different CVS repo. I seem to recall lamenting the lack of a proper link between the two years ago, arguing that either a) bugzilla should automatically expand herd with @gentoo.org (which fails when projects inexplicably choose username strings that are different from the respective herd strings), or that b) in metadata.xml the full e-mail address should be used instead of a keyword that needs to be looked up. What do you think? Right now, CC'ing a single alias is inconvenient, but under your proposal, you might need to CC a dozen or more people instead of that alias. Herd aliases (and e-mail aliases in general) are convenient in that you don't need to constantly update who is CC'd on mail and bugzilla. You haven't shown a convenient alternative for that. If herds are just that - aliases - and nothing more, then I say we keep them and fix the indirection in herd = alias instead of dropping the whole concept. jer
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sat, 27 Sep 2014 06:25:28 -0400 Rich Freeman ri...@gentoo.org wrote: On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers j...@gentoo.org wrote: Right now, CC'ing a single alias is inconvenient, but under your proposal, you might need to CC a dozen or more people instead of that alias. That is incorrect. Herds would be replaced with projects, not with lists of individual (non-)maintainers. No, it's entirely correct. Killing herd but keeping maintainer with its current denotation and connotation would mean listing separate actual maintainers. Luckily we can instead choose to replace the contents of herd with the alias listed in herds.xml. We would then be changing the meaning of maintainer in addition to removing herd. It all depends on how you interpret the using the alias in the original thread starter, I guess. I don't think that anybody thinks that having groups of devs isn't useful. The problem is that we have two different mechanisms for having groups of people, and one of them seems to make more sense than the other. Right. And nobody was contesting that. jer
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sat, 27 Sep 2014 09:11:57 -0400 Rich Freeman ri...@gentoo.org wrote: Is there some policy that says that a project cannot be a maintainer? I guess you missed an interesting discussion on #gentoo-dev today. jer
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sat, 27 Sep 2014 06:25:28 -0400 Rich Freeman ri...@gentoo.org wrote: On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers j...@gentoo.org wrote: Right now, CC'ing a single alias is inconvenient, but under your proposal, you might need to CC a dozen or more people instead of that alias. That is incorrect. Herds would be replaced with projects, not with lists of individual (non-)maintainers. I don't think that anybody thinks that having groups of devs isn't useful. The problem is that we have two different mechanisms for having groups of people, and one of them seems to make more sense than the other. Answer this: 5 developers want to maintain a group of packages together. Should they form a herd, or a project? Under what circumstances should they choose one vs the other? I don't think the distinction is particularly useful, and projects at least have a straightforward governance model. -- Rich Herds cannot be replaced by projects, because projects can contain multiple herds; iotw, there's no one-to-one mapping between them. I don't think having multiple mechanisms to form groups is a problem; from my previous paragraph, it becomes clear that it is a solution. Answer: The project model has some concepts that herds do not have. I don't think discussing this is useful, projects are documented.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sat, 27 Sep 2014 09:11:57 -0400 Rich Freeman ri...@gentoo.org wrote: Is there some policy that says that a project cannot be a maintainer? Is there some policy that says that a herd cannot be a herd?
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
Am Samstag, 27. September 2014, 23:41:04 schrieb Tom Wijsman: On Sat, 27 Sep 2014 09:11:57 -0400 Rich Freeman ri...@gentoo.org wrote: Is there some policy that says that a project cannot be a maintainer? Is there some policy that says that a herd cannot be a herd? Only for sufficiently small values of 1/0. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On 09/27/14 17:35, Tom Wijsman wrote: On Sat, 27 Sep 2014 06:25:28 -0400 Rich Freeman ri...@gentoo.org wrote: On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers j...@gentoo.org wrote: Right now, CC'ing a single alias is inconvenient, but under your proposal, you might need to CC a dozen or more people instead of that alias. That is incorrect. Herds would be replaced with projects, not with lists of individual (non-)maintainers. I don't think that anybody thinks that having groups of devs isn't useful. The problem is that we have two different mechanisms for having groups of people, and one of them seems to make more sense than the other. Answer this: 5 developers want to maintain a group of packages together. Should they form a herd, or a project? Under what circumstances should they choose one vs the other? I don't think the distinction is particularly useful, and projects at least have a straightforward governance model. -- Rich Herds cannot be replaced by projects, because projects can contain multiple herds; iotw, there's no one-to-one mapping between them. The hardened project has two herds: hardened and hardened-kernel, the former for toolchain related stuff and the latter for the kernel. We really need to keep that distinction. So mapping herds to projects doesn't work. But, mapping hardened/hardened-kernel to our *subprojects* structure does. Perhaps that might be a more natural solution in general, not just for hardened. We might proceed by associating each herd to a project, and then letting them decide whether to absorb the herd(s) into their project level, or break it down to subprojects. So as another example, ppc and ppc64 teams are merging into one team (powerpc) with one lead (currently jmorgan). There also we want to keep two herds for the two different arches for keywording/stabilizing requests. If we just say ppc and ppc64 herds belong to powerpc team, then it will be easy to change herd to subproject requiring nothing more than just a webpage put up if it doesn't already exist. I don't think having multiple mechanisms to form groups is a problem; from my previous paragraph, it becomes clear that it is a solution. Answer: The project model has some concepts that herds do not have. I don't think discussing this is useful, projects are documented. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
Dnia 2014-09-28, o godz. 00:13:15 Tom Wijsman tom...@gentoo.org napisał(a): On Sat, 27 Sep 2014 17:54:48 -0400 Anthony G. Basile bluen...@gentoo.org wrote: The hardened project has two herds: hardened and hardened-kernel, the former for toolchain related stuff and the latter for the kernel. We really need to keep that distinction. So mapping herds to projects doesn't work. But, mapping hardened/hardened-kernel to our *subprojects* structure does. Perhaps that might be a more natural solution in general, not just for hardened. We might proceed by associating each herd to a project, and then letting them decide whether to absorb the herd(s) into their project level, or break it down to subprojects. So as another example, ppc and ppc64 teams are merging into one team (powerpc) with one lead (currently jmorgan). There also we want to keep two herds for the two different arches for keywording/stabilizing requests. If we just say ppc and ppc64 herds belong to powerpc team, then it will be easy to change herd to subproject requiring nothing more than just a webpage put up if it doesn't already exist. Yes, if you do create a one-on-one mapping then it becomes possible. The question becomes does every herd want to become a (sub)project?. Ideally, they should! Theoretically, there is no problem. Practically, for some herds it'll involve extra work setting up the project related stuff and so on when there is no need for it. Example: If I were to create a MATE herd, that doesn't mean I want a MATE project; documentation wise, the Gentoo Wiki article suffices. I don't know if you know it but setting up the project wiki page takes less time than reaching into depths of CVS and editing herds.xml. You just convinced me that we should definitely drop herds. Otherwise, we'll never going to get out of the dumb distinction what project and herd is and isn't, and when one or the other, or both should be used. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
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
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sun, 28 Sep 2014, Tom Wijsman wrote: Yes, if you do create a one-on-one mapping then it becomes possible. The question becomes does every herd want to become a (sub)project?. Another example: The Emacs project maintains two herds emacs and xemacs, for GNU Emacs and XEmacs related packages, respectively. Otherwise, most resources (like overlay and wiki documentation) are shared. There certainly is no need to split the project into further (third-level) subprojects, which would unsettle our project pages in the wiki, and some of which would have only a single dev as a member. OTOH, emacs and xemacs herds should be kept separate, because these are clearly separated groups of packages, and because of assignment of bugs in bugzilla. Ideally, they should! Theoretically, there is no problem. Practically, for some herds it'll involve extra work setting up the project related stuff and so on when there is no need for it. +1 Not everything (or everyone) needs a project, says GLEP 39. If the extra work will add no value, then there should be no project. Ulrich pgp7pS66FH2Ct.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Wed, Sep 24, 2014 at 12:31 PM, W. Trevor King wk...@tremily.us wrote: On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote: 4. A mail alias that is not project :). For example, we have clang@ for easily aggregating all clang-related build failures and other bugs but it isn't a formal team. As an incremental solution, what about a watcher tag in metadata.xml with the same format as maintainer except that being a watcher doesn't imply a willingness to *do* anything about a project, it just means you want to be notified of changes and added to the CC list. I'd given some thought to this as well, but didn't think it was a good idea. First, you can already create queries in bugzilla. Second, if we wanted something more robust than being interested in a package isn't something that is limited to devs. If you're just going to look at bugs but not do anything about them, then you are really just a user who might happen to also have commit access. Do we really need to have a developer-only way of getting bug CC's for people who don't actually want to fix the bugs? Or, would it make more sense to find a way for anybody to follow issues in packages, assuming bugzilla queries aren't enough? Now, if something like clang@ isn't a formal team but does consist of people who are actually doing something, why not just make it a project? After all, a group of people interested in actually doing something basically is the definition of a project. Being a project isn't some kind of huge commitment. and I think it makes sense to just have devs and groups of devs instead of having 12 different kinds of groups of devs and we can't keep straight which kinds of groups do (or more typically don't do) what. -- Rich
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Thu, Sep 25, 2014 at 11:00:32AM -0400, Rich Freeman wrote: On Wed, Sep 24, 2014 at 12:31 PM, W. Trevor King wrote: On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote: 4. A mail alias that is not project :). For example, we have clang@ for easily aggregating all clang-related build failures and other bugs but it isn't a formal team. As an incremental solution, what about a watcher tag in metadata.xml with the same format as maintainer except that being a watcher doesn't imply a willingness to *do* anything about a project, it just means you want to be notified of changes and added to the CC list. I'd given some thought to this as well, but didn't think it was a good idea. First, you can already create queries in bugzilla. Not all package activity has an associated bugzilla entry, but maybe enough of it does? Or, would it make more sense to find a way for anybody to follow issues in packages, assuming bugzilla queries aren't enough? What about a list entry in metadata.xml that points people to the suggested mailing list for discussing a package? Bugzilla could automatically add the list to its CC list, and both devs and non-devs could join the list without adding a lot of email addresses to the tree. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote: Dnia 2014-09-10, o godz. 07:53:31 Rich Freeman napisał(a): On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos wrote: Personally I would vote for simply have a maintainer tag pointing to the alias but we would still need to keep a list of real maintainers for that alias as usually not all people listed in the alias are willing to maintain the packages. I think the solution to this is that maintainers can be either: 1. Devs - identified by their email address. (simple enough) or 2. Projects - identified by their email alias. or 3. A proxy maintainer identified by email address (in which case either a dev or project must also be listed, potentially including the proxy maintainer project). 4. A mail alias that is not project :). For example, we have clang@ for easily aggregating all clang-related build failures and other bugs but it isn't a formal team. As an incremental solution, what about a watcher tag in metadata.xml with the same format as maintainer except that being a watcher doesn't imply a willingness to *do* anything about a project, it just means you want to be notified of changes and added to the CC list. Then devs can sign up to maintain or watch packages without using herds. Folks who find herds convenient can continue to use them with as implied maintainers [1] (or implied watchers, I don't really care). Folks who don't find herds convenient can leave them and just add their maintainer/watcher tags directly. Then reap herds if/when they go empty. I don't see the need for a dramatic change here, or even one that requires much consensus building. Or is a watcher tag controversial? I'm not sure how the bugzilla CC lists are generated, maybe it would be terribly complicated to iterate over maintainers + watchers? Cheers, Trevor [1]: http://article.gmane.org/gmane.linux.gentoo.devel/92877 id:1410348781.5850.7.ca...@gentoo.org -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Thu, 11 Sep 2014 21:00:16 +0100 Markos Chandras hwoar...@gentoo.org wrote: please do not go offtopic discussing the recruitment process. I simply mentioned one of the designated ways we have to ask for help. If you don't like it, propose a better method. Please do not go offtopic about your own getting people on board. I simply suggested improvements to one of the designated ontopic problems that can be seen in herds. If you don't like it, write a better reply.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Wed, 10 Sep 2014 21:21:24 +0100 Markos Chandras hwoar...@gentoo.org wrote: On 09/10/2014 03:01 PM, Tom Wijsman wrote: +1; to summarize my thoughts: Herds misrepresent manpower. true and false. More true than false. undertakers often remove dead herds. How often? What is considered dead? How about semi-dead? How about the misrepresented ones? Are metrics like commit and bug ratios considered? Relevant: http://www.gossamer-threads.com/lists/gentoo/dev/258463 And herds in need for more people should really make use of this wiki page https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs They do and don't. Those that do, are drowned in a long list that rarely attracts new devs; those that don't, don't have time for it as they are drowned in work. The recruitment process is too lengthy compared to the amount of people that can actively recruit new developers; as a result, this contributes to the rarity of attracting new developers to that list. This lengthy process is also unattractive to new recruiters; whom are not kept in the loop when showing interest, eg. I've watched a few sessions and then heard nothing (because there barely are recruiters?). If we want to thrive, both the student and recruiter recruitment processes need to be revised; at this moment, 13 students are in the queue. Some of them have been waiting for weeks or months... how do you expect to get more people on board if you don't make it known where help is actually needed? This acknowledges that the herds concept hides where help is needed; but as revealed in the last paragraphs, that's not the only problem.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/11/2014 07:30 PM, Tom Wijsman wrote: On Wed, 10 Sep 2014 21:21:24 +0100 Markos Chandras hwoar...@gentoo.org wrote: On 09/10/2014 03:01 PM, Tom Wijsman wrote: +1; to summarize my thoughts: Herds misrepresent manpower. true and false. More true than false. undertakers often remove dead herds. How often? What is considered dead? How about semi-dead? How about the misrepresented ones? Are metrics like commit and bug ratios considered? Relevant: http://www.gossamer-threads.com/lists/gentoo/dev/258463 And herds in need for more people should really make use of this wiki page https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs They do and don't. Those that do, are drowned in a long list that rarely attracts new devs; those that don't, don't have time for it as they are drowned in work. The recruitment process is too lengthy compared to the amount of people that can actively recruit new developers; as a result, this contributes to the rarity of attracting new developers to that list. This lengthy process is also unattractive to new recruiters; whom are not kept in the loop when showing interest, eg. I've watched a few sessions and then heard nothing (because there barely are recruiters?). If we want to thrive, both the student and recruiter recruitment processes need to be revised; at this moment, 13 students are in the queue. Some of them have been waiting for weeks or months... how do you expect to get more people on board if you don't make it known where help is actually needed? This acknowledges that the herds concept hides where help is needed; but as revealed in the last paragraphs, that's not the only problem. please do not go offtopic discussing the recruitment process. I simply mentioned one of the designated ways we have to ask for help. If you don't like it, propose a better method. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUEf9QXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z5S4H/RzX++Z/slhMjpYwGqu4zA1P DgByLHnINhQPFpNYIxfgvAFCjVp+drCllRvzvE3IdCdfR1HsLUYeLNMDby8SQlAr axHklrtQGeSXK9rd9leYvfa/lCzNahFj5PWbPeJFco1j7V7BDJCYKS1FxQpQhAyg H5MiBFDRZK403qt8U4JsOCGEpI5Uy+US+xTAXHTV0u0YKW0u8S/znju6TM2WVWy2 qFTTQvH4vNf38zj6+UVzFa16xw5wYeIajMHLm7cTg98pDU4UcVEbeeZ0vEUX6DS8 XSlGO93haF9E4v4giMaQXXHtRmJzhHXdx78mnir4u1tdIfqG3Q8bjGnNVmu7GWU= =UyIv -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
El mar, 09-09-2014 a las 21:45 +0200, Michał Górny escribió: [...] I believe it would be benfiicial to just deprecate and eventually drop herd/ in favor of explicit maintainer/ using the alias. I don't know if someone has other use of herds.xml but it the contents are either outdated or redundant. Therefore, I would suggest eventually getting rid of that file as well. What do you think? I agree with this but we would need to cover the case of people being in a determined mail alias but don't really wanted to be considered a maintainers of the involved packages as they are in the alias to keep track on that issues. This problem has usually raised when a herd starts to become inactive as no one is really maintaining that packages. We can erroneously think that the herd is still active because there are people in the alias... but they are really not taking care of them at all. We discussed this in the past (I think it was a gentoo-dev ML thread related with media-optical herd being empty) and we agreed on only considering people listed in herds.xml as maintainers, not people in mail alias. Personally I would vote for simply have a maintainer tag pointing to the alias but we would still need to keep a list of real maintainers for that alias as usually not all people listed in the alias are willing to maintain the packages.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Tue, Sep 9, 2014 at 6:54 PM, Kent Fredric kentfred...@gmail.com wrote: On 10 September 2014 10:23, Michał Górny mgo...@gentoo.org wrote: I don't understand your concern. I'm only saying we should stop relying on that stupid out-of-repository herds.xml file and put the e-mail address directly in metadata.xml. Bugzilla and bug assignment would work pretty much the same -- except that you wouldn't have to scan one more file to get the e-mail you're looking for. That sounds less like you're trying to deprecate the use of herds, and more like you're trying to deprecate the use of herds /in metadata.xml/. The latter strikes me as an easier sell, just the markup is more effort. If it was possible to write herdperl/herd and have some process that automatically upscaled that to a maintainer tag, that'd be cool. If the only thing we're using herds for is as a way to populate the maintainer field, then they really should go away. I'd think that the whole point of having herds is so that you could group packages together in a way OTHER than by maintainer. We already have the maintainer attribute to track who maintains a package. Herds were supposed to be about grouping related packages together (like a herd), and not keeping track of who the cattle rustlers were. IMHO herds aren't working because: 1. They're basically being used as another form of project, so in addition to mail alias members and project pages it is yet another version of who is working on what which differs from the other ways of finding out who is working on what. 2. They're supposed to be used to group related packages together, but we already have categories, and there isn't just one true way to group packages together anyway. It sounds like they're a 1:many form of tagging. -- Rich
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos pa...@gentoo.org wrote: Personally I would vote for simply have a maintainer tag pointing to the alias but we would still need to keep a list of real maintainers for that alias as usually not all people listed in the alias are willing to maintain the packages. I think the solution to this is that maintainers can be either: 1. Devs - identified by their email address. (simple enough) or 2. Projects - identified by their email alias. or 3. A proxy maintainer identified by email address (in which case either a dev or project must also be listed, potentially including the proxy maintainer project). A project must have: 1. A mail alias. Anybody can monitor if the project is OK with it, but it isn't the definitive member list. 2. A project page on the wiki with a member list. This is the definitive list of who is a member. 3. An annually-elected lead. The lead should clean up the member list from time to time. An inactive project should be treated the same as an inactive dev as far as maintainership goes - target for cleanup. Special projects like archs/infra/comrel/etc should probably be escalated to council if they appear dead. Herds are just collections of packages - a package being in a herd says nothing about whether it is maintained, just as a package being in a category says nothing about it being maintained. -- Rich
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Tue, 9 Sep 2014 21:45:49 +0200 Michał Górny mgo...@gentoo.org wrote: Let's keep it short: I think herds don't serve any special purpose nowadays. Their existence is mostly resulting in lack of consistency and inconveniences. +1; to summarize my thoughts: Herds misrepresent manpower.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
Dnia 2014-09-10, o godz. 07:53:31 Rich Freeman ri...@gentoo.org napisał(a): On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos pa...@gentoo.org wrote: Personally I would vote for simply have a maintainer tag pointing to the alias but we would still need to keep a list of real maintainers for that alias as usually not all people listed in the alias are willing to maintain the packages. I think the solution to this is that maintainers can be either: 1. Devs - identified by their email address. (simple enough) or 2. Projects - identified by their email alias. or 3. A proxy maintainer identified by email address (in which case either a dev or project must also be listed, potentially including the proxy maintainer project). 4. A mail alias that is not project :). For example, we have clang@ for easily aggregating all clang-related build failures and other bugs but it isn't a formal team. It's hard if such a thing has proper member list. But in any case, is there a reason for needing to have definitive member list? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Wed, Sep 10, 2014 at 10:18 AM, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-09-10, o godz. 07:53:31 Rich Freeman ri...@gentoo.org napisał(a): On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos pa...@gentoo.org wrote: Personally I would vote for simply have a maintainer tag pointing to the alias but we would still need to keep a list of real maintainers for that alias as usually not all people listed in the alias are willing to maintain the packages. I think the solution to this is that maintainers can be either: 1. Devs - identified by their email address. (simple enough) or 2. Projects - identified by their email alias. or 3. A proxy maintainer identified by email address (in which case either a dev or project must also be listed, potentially including the proxy maintainer project). 4. A mail alias that is not project :). For example, we have clang@ for easily aggregating all clang-related build failures and other bugs but it isn't a formal team. It's hard if such a thing has proper member list. But in any case, is there a reason for needing to have definitive member list? I don't think we should allow #4 in the absence of #1-2, because mail aliases shouldn't be maintainers. What #4 says is I'd like to know what is going on with a package, but don't look at me if it breaks. The challenge is that people are going to fail to distinguish between these aliases and ones that belong to projects, because they look the same. Why should we have a clang email alias if there isn't a clang project? Why not just make it into a project? It sounds like you have a bunch of devs who want to stay on top of clang so that it is well-supported in the tree, and that is basically the definition of a project. You don't need to have meetings, agendas, minutes, and bylaws to be a project - just a common purpose. I'm not opposed to finding better ways to keep people informed. I just don't want to equate a desire to be informed with a commitment to maintain something - which we've already identified as a problem. Also, you spoke about clang-related build failures. You probably wouldn't be tagging packages with that alias in that case - you'd just have it as a CC alias on bugs. You're more interested in specific bugs than specific packages. -- Rich
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/10/2014 03:01 PM, Tom Wijsman wrote: On Tue, 9 Sep 2014 21:45:49 +0200 Michał Górny mgo...@gentoo.org wrote: Let's keep it short: I think herds don't serve any special purpose nowadays. Their existence is mostly resulting in lack of consistency and inconveniences. +1; to summarize my thoughts: Herds misrepresent manpower. true and false. undertakers often remove dead herds. And herds in need for more people should really make use of this wiki page https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs how do you expect to get more people on board if you don't make it known where help is actually needed? - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUELLEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z1WAIAKW0Q1KipbiIGsOZ/R9vjgIQ fA7gJx5D+YcFyJdqPQUm5qt9WqxQv8p8TD5tacihxIF13WCS8BnMxDUf3BbErWJF 8RBPR2/T2L303YJ3xq/hTsdI2MoEiaKaOSUSDIbT18pNyLLNRabIBDLpM8jRPl0i cLK70yUwkht70y8tI8NiCQCtSk6dMZpzgvq9JFNyDO+jPlSt3NMMIO6KsCg7ZfH1 8pqiAUW9T3BwrX0nWGWgnUguuZ6+Q5UJXVvELWtHDeyuVq02MNdJqPLfTEeo9U+6 SMCquUU7/Owg2cXLCVG0arrEeJEgoWR7qtPMZqkxmIH1c1OlS81WEHoH/29uqAQ= =Dijl -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny mgo...@gentoo.org wrote: Let's keep it short: I think herds don't serve any special purpose nowadays. Their existence is mostly resulting in lack of consistency and inconveniences. The original design was that packages belong to herds, and developers belong to projects. Projects might maintain a herd. The problem is that this isn't followed with 100% rigor, and the extra level of indirection probably doesn't make bug things easier. I'm not sure what we lose by getting rid of herds vs just listing projects as maintainers. Maybe herds are useful as a form of tag, but if we really wanted that it would make more sense to just have tags of some kind. -- Rich
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On 09/09/14 15:56, Rich Freeman wrote: On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny mgo...@gentoo.org wrote: Let's keep it short: I think herds don't serve any special purpose nowadays. Their existence is mostly resulting in lack of consistency and inconveniences. The original design was that packages belong to herds, and developers belong to projects. Projects might maintain a herd. The problem is that this isn't followed with 100% rigor, and the extra level of indirection probably doesn't make bug things easier. I'm not sure what we lose by getting rid of herds vs just listing projects as maintainers. Maybe herds are useful as a form of tag, but if we really wanted that it would make more sense to just have tags of some kind. I can live with collapsing herds into projects as long as we keep some system where groups of packages come under the care of groups of developers. Eg. coreutils is maintained by base-system, or drupal is maintained by web-app, etc. But we do loose something. I like being on the bugzilla cc list of lots of herd where I'm not really a member of the project taking care of that herd. I'm on both base-system@ and web-app@ aliases, but I'm not a member of base-system while I am a member of web-app. -- Rich -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
Dnia 2014-09-09, o godz. 16:46:29 Anthony G. Basile bluen...@gentoo.org napisał(a): On 09/09/14 15:56, Rich Freeman wrote: On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny mgo...@gentoo.org wrote: Let's keep it short: I think herds don't serve any special purpose nowadays. Their existence is mostly resulting in lack of consistency and inconveniences. The original design was that packages belong to herds, and developers belong to projects. Projects might maintain a herd. The problem is that this isn't followed with 100% rigor, and the extra level of indirection probably doesn't make bug things easier. I'm not sure what we lose by getting rid of herds vs just listing projects as maintainers. Maybe herds are useful as a form of tag, but if we really wanted that it would make more sense to just have tags of some kind. I can live with collapsing herds into projects as long as we keep some system where groups of packages come under the care of groups of developers. Eg. coreutils is maintained by base-system, or drupal is maintained by web-app, etc. But we do loose something. I like being on the bugzilla cc list of lots of herd where I'm not really a member of the project taking care of that herd. I'm on both base-system@ and web-app@ aliases, but I'm not a member of base-system while I am a member of web-app. I don't understand your concern. I'm only saying we should stop relying on that stupid out-of-repository herds.xml file and put the e-mail address directly in metadata.xml. Bugzilla and bug assignment would work pretty much the same -- except that you wouldn't have to scan one more file to get the e-mail you're looking for. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On 10 September 2014 10:23, Michał Górny mgo...@gentoo.org wrote: I don't understand your concern. I'm only saying we should stop relying on that stupid out-of-repository herds.xml file and put the e-mail address directly in metadata.xml. Bugzilla and bug assignment would work pretty much the same -- except that you wouldn't have to scan one more file to get the e-mail you're looking for. That sounds less like you're trying to deprecate the use of herds, and more like you're trying to deprecate the use of herds /in metadata.xml/. The latter strikes me as an easier sell, just the markup is more effort. If it was possible to write herdperl/herd and have some process that automatically upscaled that to a maintainer tag, that'd be cool. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
