From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1G7uy3-0003kv-GC for garchives@archives.gentoo.org; Tue, 01 Aug 2006 14:11:31 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k71E9K6x002645; Tue, 1 Aug 2006 14:09:20 GMT Received: from MIUMMR0MT03.um.ced.h3g.it ([62.13.171.111]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k71E69Mt023225 for ; Tue, 1 Aug 2006 14:06:09 GMT Received: from c1358217.kevquinn.com (miumgu0vp03.um.ced.h3g.it [10.216.57.163]) by MIUMMR0MT03.um.ced.h3g.it (MOS 3.5.5-GR) with ESMTP id APS87576; Tue, 1 Aug 2006 16:06:01 +0200 (CEST) Date: Tue, 1 Aug 2006 16:05:31 +0200 From: "Kevin F. Quinn" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Sunrise contemplations Message-ID: <20060801160531.67a8f654@c1358217.kevquinn.com> In-Reply-To: <1154366720.17142.126.camel@rivendell> References: <1154366720.17142.126.camel@rivendell> X-Mailer: Sylpheed-Claws 2.3.0 (GTK+ 2.8.12; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_1baZAPinnQt=JuQQyhqtuHj"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 49da00ec-7bb2-4ff2-8da1-a454a1fbaa08 X-Archives-Hash: e2e74f0d2363251e096ea3bba837349c --Sig_1baZAPinnQt=JuQQyhqtuHj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 31 Jul 2006 19:25:20 +0200 foser wrote: > [...] > 1. Stale ebuilds are often stale for a reason, there is obviously not > enough interest to add and maintain them. Not just on the developer > side, but also on the user side. If someone really cared enough > he/she would go trough the process of becoming a dev. I think most users would see becoming a dev as a long-term commitment. We certainly want that to be the case - we don't want people becoming a dev just to bump a package that they want in a particular moment just to then disappear. The situation for such stale ebuilds is that there may be no active devs who are interested - even if there are many users who are. Sunrise does provide a place where users can work with the Sunrise project to get what they want into the overlay, perhaps ultimately into the tree. These users can contribute for the period they want to, then forget about it, leaving it to the Sunrise developers follow it up. Such follow-up could be: 1) Maintain the ebuild in the sunrise overlay 2) Take the package on themselves, and integrate it into the main tree 3) Find another dev willing to take the package on (e.g. by asking the herd alias), hand it over for maintenance in the main tree. 4) Drop it. Sunrise can also help gauge how much user interest there is in a package. > [...] > Sunrise just lowers the step to get these often mediocre ebuilds, > people can get them right now, just not as easy. I hope the intention is that Sunrise would be improving these mediocre ebuilds to the point where they would be acceptable in the tree, as far as technical quality is concerned. > 2. [...] Therefore I do not believe that QA for a tree that is as > extensive as Sunrise done by a few 'official' developers amounts to > much real world quality. I would expect that over time, the Sunrise developers will learn more and more how to write quality ebuilds (as hopefully do we all). Since they'll be working with a diverse set of stuff, they could become better than most devs at this. Remember that since they have custody of the stuff in the Sunrise overlay, they will be hit with whatever issues arise from their work. > 3. Although I agree Sunrise may lower the step to becoming a dev, I > doubt it will have a serious positive impact on our developer base > and as such there is no reason to support Sunrise officially. I think > the people attracted to Sunrise development are the ones that fall in > the category 'want to be there, but don't really have the > time/skills'. That would certainly be true for many. There may also be people who would be happier with the proving ground that Sunrise provides, gaining confidence before attempting to become a dev. > Those people will not evolve to real developers; they > either will stick it out in Sunrise for a short while or keep to a > very small subset of it. My prediction is that Sunrise will see a > high turnover of 'developers', either because they are there for one > specific package (probably fresh and included in the main tree when > mature) or find out they lack the time to really invest in learning > the full extent of ebuilding. Also 'junior' devs on Sunrise might not > take that extra step towards devhood because they got the influence > they want, as such we might lose out on devs that never develop > beyond Sunrise contributors. I'd be wary of encouraging people who don't want to go further than bunging something into Sunrise becoming devs. If they're not prepared to maintain their stuff in Sunrise, then they don't really want to be a dev (which is largely about maintenance). > As a developer I would not really think > of Sunrise developers any different than someone coming 'fresh' to > Gentoo developing. What it does give you is a track record you can look through - in much the same way you might have watched what someone did on bugzilla or IRC. Indeed I'd suggest that the history in Sunrise SVN would be useful to indicate whether someone is learning how to write ebuilds properly, or just continues to make the same errors. > I would still require them to work on real bugs > for a good while to see their intentions/devotion over time before I > would even consider submitting them for real developership. In that > sense Sunrise would only lengthen the time a wannabe dev has to spend > in the no-mans land between active user and official developer. I don't think anyone is suggesting that all future devs prove themselves in Sunrise first, so I don't see that it lengthens the time a wannabe dev has to spend, since they can always take the approach we currently use and avoid Sunrise altogether. I expect Sunrise would hope that contributors hang around to do their own maintenance in the Sunrise overlay, in which case they'll get to understand what maintenance means, how much effort is involved and thereby understand better the commitment expected of them should they decide to go for dev-ship. > In conclusion these 3 points come together here : being a dev is not > about adding new ebuilds to the tree, it is about maintaining what is > already there. Dealing with bugs and users. 100% with you there. Anyone can knock up an ebuild - it takes effort to maintain it, and that's the lions share of the work of most devs. > That aspect of Sunrise is > not at all tackled in its goals. What are the longterm prospects of > ebuilds in the Sunrise tree ? Is this not in their documentation? From the project name, I would expect they hope that stuff either rises fully (i.e. to end up in the tree with proper maintainership) or would wither and die depending on how much effort is put in by those who want the package. > That is what QA is about, providing a > stable base to work on. I do not think that devs who mainly add > ebuilds and new packages to the tree are good devs, the real job is > maintenance and bughandling. In that sense Sunrise might be giving > the wrong impression to wannabe devs. >=20 > * The rise of project Sunrise >=20 > Now for the second big point concerning Sunrise : how it came into > being. This was certainly handled very badly. However I think that's history now, and there's not much to be gained from going back over it. > [...] > Anyway, the project after the initial announcement got a 'temporarily > removed' status from gentoo.org . The problem here in my opinion is > not so much that the people who support the project needed to defend > it, but that people who are more conscious about the project need to > prove it is wrong. This had to happen in a mere 2 months where the > project has had hardly any impact. If you want to properly evaluate > such an extensive project it needs to be given much more time. The > project should prove itself before it should be allowed to 'join' > Gentoo, not the other way around. I have seen no tangible benefits > from Sunrise so far, aside from the fact that developers have left > over it and the developer community is seriously divided these days. > As such Sunrise has been one big mistake, the possible benefits at > this point in time do not outweigh the havoc it has caused. Beyond the mailing list wars (I won't call them flamewars because I think most combatants are sincere with their concerns), I don't think there has been any significant detrimental effect - for the same reason; i.e. it's only been around for a couple of months so hasn't had time to produce any of the problems that some people are worried will occur. > * The implications of sunrise >=20 > What will Sunrise mean to the general developer ? > [...] > In short, from my experience Sunrise will only result in more work for > the general developer with little benefits. This may not happen often, > but every single time is one time too much. This is can be really > demotivating, which is probably the worst thing about it. I think as long as Sunrise steers clear of core system packages, essentially focusing on "leaf" packages, the sorts of problem you encountered with BMG can be avoided. Certainly I would expect Sunrise not to be providing alternate versions of stuff already in the tree, and not to be modifying eclasses that exist in the tree - this sort of change is for managed dev overlays. --=20 Kevin F. Quinn --Sig_1baZAPinnQt=JuQQyhqtuHj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEz1+z9G2S8dekcG0RAiFoAJ4gCffJwqTtJ/xQuUOhzngJYc1o9gCbBIm/ TsPfLLbN3/hlyP8CV7n+Ys8= =K8Pq -----END PGP SIGNATURE----- --Sig_1baZAPinnQt=JuQQyhqtuHj-- -- gentoo-dev@gentoo.org mailing list