[gentoo-user] The end of "Herds"
Hello, If you follog gentoo-dev you can see Rich's summary interpretation (which I do agree with) posted at the bottom of this thread. Recently I was asked to help clean up some of the Java bugs. OK, as a non-maintainer I agreed. I went through over 100 java bugs, mostly pre 2010, as to make a dent in the backlog of ~500 java bugs that would probably be the easiest to clean up. Sure enough, there were only a few that were still relevant (Hm) So I proposed, to one of the Java Herd members we blast out a few emails notifying everyone that if folks did not "reaffrim" these (very old) java bugs, they would be mass-closed. If you look at those (old bugs) most would agree with my assessment. However, I listed a few as blatant examples that needed to be closed. It seems there is no "closer" for java bugs. Nobody around with the authority (will?) to close any old Java bugs. The herd is descimated, on furlog or just burnt out and non-responsive. So all of my work and effort was for nothing. Over the years, I have made at least 3 attemps to use java on gentoo; all resulted in using other linix distros. For me, java is a reality that cannot be wished away. What I have learn in the last few months is that Java on Gentoo is alive and properous; folks with Java ebuilds just do not bother with getting them into Gentoo because of the morass of apathy the gentoo java hers has become. So now is the time for folks to read and post to gentoo-dev on thread: :" Deprecating and killing the concept of herds" if you have any issues with herds being removed from Gentoo. Ideas on how to best organize bug_cleaning is also welcome. I think there will be an uptake in proxy-maintainers, if the gentoo-dev club is sincere about treating these proxy maintainers with respect and mutual professionalism. I think the concept of "Projects" will persist, but herds have to become active and request to become "Projects" as defined on the gentoo wiki or they will be erased. Like many others, I have been burned in the past with trying to get directly involved with Gentoo (been here since 2004). That's all water under the bridge. So I am "tip_toeing" behind the scenes willing to be a grunt and clean up some of the java mess, participate in clustering and contribute to the science project. We'll see just how long it lasts before I get "bitch_slapped" like my previous attempts That's why I named by current /usr/local/portage "jackslap". We shall see what happens. I see the enabling of user patches directly into ebuilds in the tree (EAPI 6) and the cleansing of the irresponsible amongst the herds with exclusive control over bugs as a very positive sign that the gentoo dev community is one again dedicated to making Gentoo an excellent platform. Whatever your experiences have been, I hope you read, post and give direct participation in Gentoo your deepest consideration. James My (rich) 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?
Re: [gentoo-user] The end of "Herds"
On 11/04/2014 03:13 PM, James wrote: > Hello, > > > If you follog gentoo-dev you can see Rich's summary > interpretation (which I do agree with) posted at the > bottom of this thread. > > > Recently I was asked to help clean up some of the Java > bugs. > > ... > So I proposed, to one of the Java Herd members we blast out > a few emails notifying everyone that if folks did not > "reaffrim" these (very old) java bugs, they would be mass-closed. > If you look at those (old bugs) most would agree with my > assessment. However, I listed a few as blatant examples > that needed to be closed. It seems there is no "closer" for > java bugs. Nobody around with the authority (will?) to close > any old Java bugs. The herd is descimated, on furlog or just > burnt out and non-responsive. So all of my work and > effort was for nothing. This is exactly the problem we're trying to solve (and I'm sorry to hear it, many of us have been in a similar position). Herds as a group of developers have always been very poorly-defined. As I've heard it repeated, originally packages were supposed to belong to herds, and developers were supposed to belong to projects. But herds almost always had an associated email address, so people who cared about groups of packages would add themselves to the herd to get on the email alias. But projects were there all along, too, and we wound up with a bunch of people in herds who were never going to fix bugs and some smaller number of people in projects (who might fix bugs) that weren't in the herds. It was all very confusing, so the council is voting to replace them with something that makes sense. Basically we want to fix the situation we have right now where it's impossible to tell who is actually working on Java packages. Once herds are replaced, you should be able to get an accurate reading out of metadata.xml and/or the wiki page. (And I'm sure anyone actually working on Java would appreciate your help.) For you personally, I would try to find one or two people on the Java project (actually working on Java right now) and explain to them that you'd like to help close old bugs. Then you can CC or reassign the Java bugs to those people. When bug mail gets sent to a herd or project, it's too easy to say "screw it, someone else will deal with it." Bugs addressed to me personally get attention much sooner, even if only for psychological reasons. So reassigning those to a single person might prompt action sooner than you'd get otherwise.
Re: [gentoo-user] The end of "Herds"
On 11/04/2014 03:13 PM, James wrote: > Hello, > > > If you follog gentoo-dev you can see Rich's summary > interpretation (which I do agree with) posted at the > bottom of this thread. > > > Recently I was asked to help clean up some of the Java > bugs. OK, as a non-maintainer I agreed. I went through > over 100 java bugs, mostly pre 2010, as to make a dent > in the backlog of ~500 java bugs that would probably > be the easiest to clean up. Sure enough, there were > only a few that were still relevant (Hm) > > > So I proposed, to one of the Java Herd members we blast out > a few emails notifying everyone that if folks did not > "reaffrim" these (very old) java bugs, they would be mass-closed. > If you look at those (old bugs) most would agree with my > assessment. However, I listed a few as blatant examples > that needed to be closed. It seems there is no "closer" for > java bugs. Nobody around with the authority (will?) to close > any old Java bugs. The herd is descimated, on furlog or just > burnt out and non-responsive. So all of my work and > effort was for nothing. Over the years, I have made > at least 3 attemps to use java on gentoo; all resulted in > using other linix distros. For me, java is a reality > that cannot be wished away. What I have learn in the last few > months is that Java on Gentoo is alive and properous; folks with > Java ebuilds just do not bother with getting them into Gentoo > because of the morass of apathy the gentoo java hers has become. > > So now is the time for folks to read and post to gentoo-dev on > thread: :" Deprecating and killing the concept of herds" if > you have any issues with herds being removed from Gentoo. > Ideas on how to best organize bug_cleaning is also welcome. > I think there will be an uptake in proxy-maintainers, if the > gentoo-dev club is sincere about treating these proxy maintainers > with respect and mutual professionalism. > > I think the concept of "Projects" will persist, but herds have > to become active and request to become "Projects" as defined > on the gentoo wiki or they will be erased. Like many others, > I have been burned in the past with trying to get directly involved > with Gentoo (been here since 2004). That's all water under the bridge. > So I am "tip_toeing" behind the scenes willing to be a grunt > and clean up some of the java mess, participate in clustering and > contribute to the science project. We'll see just how long it lasts > before I get "bitch_slapped" like my previous attempts > > > That's why I named by current /usr/local/portage "jackslap". > We shall see what happens. > > > I see the enabling of user patches directly into ebuilds in the tree > (EAPI 6) and the cleansing of the irresponsible amongst the herds > with exclusive control over bugs as a very positive sign that the gentoo > dev community is one again dedicated to making Gentoo an excellent platform. > Whatever your experiences have been, I hope you read, post > and give direct participation in Gentoo your deepest consideration. > > > James > > > > My (rich) 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
