From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 170F3138825 for ; Fri, 7 Nov 2014 00:13:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5ABF5E0AD3; Fri, 7 Nov 2014 00:13:43 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 244DFE0A5F for ; Fri, 7 Nov 2014 00:13:41 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DC8332063E for ; Thu, 6 Nov 2014 19:13:39 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 06 Nov 2014 19:13:39 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=gKbEWuBhFjnMI5ZOPKAIwA mZsdI=; b=P3zPZzPWBJwz2sScPWVqdZVcuJIaAOc9pwKsYjPEDh0z3gnHffeSFg Al1IGTMluNqcvOGCA+mKmRze+BM+WxgXNq52/RyBcoqfsaBW7MK5GlD+JMWn48z3 Q/teuSjgd71Rtg3CrXiw3PlySceCTsM2/x7/lgUI3CsNVeI6mENIc= X-Sasl-enc: FVc+ZDJv8ZDLLoBatspuZnkfquyPln85WlfpZoL4PeDe 1415319219 Received: from [35.2.101.222] (unknown [35.2.101.222]) by mail.messagingengine.com (Postfix) with ESMTPA id 9E1ADC00011 for ; Thu, 6 Nov 2014 19:13:39 -0500 (EST) Message-ID: <545C0EB3.3010501@alectenharmsel.com> Date: Thu, 06 Nov 2014 19:13:39 -0500 From: Alec Ten Harmsel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] The end of "Herds" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 66db1794-e384-4af8-9b07-3e46e621bcc1 X-Archives-Hash: 8c852256ba64fcd1a95fdecc2e74a688 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 > > > > 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