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 (Hmmmmmmmmmmmmmmmmm) 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 <snip> 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?
