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 (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? > > > > >
There is a large discussion on the Spark mailing list right now about having groups of maintainers for different areas: http://apache-spark-developers-list.1001551.n3.nabble.com/VOTE-Designating-maintainers-for-some-Spark-components-td9115.html I'm not sure how relevant that is, but it's interesting. My own viewpoint is that there should be no individual maintainers; packages should be assigned on a herd level, and the herds can self-regulate and know who has expertise with each package. Just my two cents; best to not have a single point of failure. Alec
