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 1G7bZ0-0001Gn-2y for garchives@archives.gentoo.org; Mon, 31 Jul 2006 17:28:22 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k6VHRRtr005365; Mon, 31 Jul 2006 17:27:27 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k6VHPURk015848 for ; Mon, 31 Jul 2006 17:25:31 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 442F26469C for ; Mon, 31 Jul 2006 17:25:30 +0000 (UTC) Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24513-18 for ; Mon, 31 Jul 2006 17:25:22 +0000 (UTC) Received: from castor.warande.net (castor.sshunet.nl [145.97.192.41]) by smtp.gentoo.org (Postfix) with ESMTP id 4B36F645A3 for ; Mon, 31 Jul 2006 17:25:21 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by castor.warande.net (Postfix) with ESMTP id AC50357C01F for ; Mon, 31 Jul 2006 19:25:20 +0200 (CEST) Received: from castor.warande.net ([127.0.0.1]) by localhost (castor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05105-02 for ; Mon, 31 Jul 2006 19:25:20 +0200 (CEST) Received: from rivendell (216pc222.sshunet.nl [145.97.222.216]) by castor.warande.net (Postfix) with ESMTP for ; Mon, 31 Jul 2006 19:25:20 +0200 (CEST) Subject: [gentoo-dev] Sunrise contemplations From: foser To: gentoo-dev Content-Type: text/plain Date: Mon, 31 Jul 2006 19:25:20 +0200 Message-Id: <1154366720.17142.126.camel@rivendell> 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 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Status: No, score=-2.002 required=5.5 tests=[AWL=0.462, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] X-Spam-Score: -2.002 X-Spam-Level: X-Archives-Salt: e83c2327-b771-48bc-965d-1c940aabf8fa X-Archives-Hash: 9877ae35e63ffc67500883d2dc7646a9 Hello, since I've not really been involved in the whole Sunrise discussion I'd like to give my view in a condensed form, instead of spreading it out over 20 replies in the ongoing discussion. Also I hope to summarize the main points a bit, but I know this mail is far from objective and as such not much of good summary. There are really 2 big discussion points in the whole Sunrise discussion as far as I can see. First there is the purpose of Sunrise and how that ties into Gentoo and secondly there's how it came into being. I would also like to discuss how I think Sunrise will influence the work of developers. Let's tackle them one by one. * The purpose of Sunrise The purpose of Sunrise as far as I can distill them from their goals : 1. Make stale ebuilds in bugzilla accessible 2. Provide some level of QA for user contributed ebuilds in bugzilla 3. Lower the step to becoming a developer Let's handle them. 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. As far as I know most maintainer-wanted stuff just belongs in the category WONTFIX, but the real problem is telling that to the user who sweated on it. I think most of the devs have gone trough a close-reopen cycle on some ebuilds that really added nothing useful to the tree and know how uncomfortable this can make you feel. Then what is a solution to these ebuilds ? I for one would like to see them go upstream, like rpm's and deb's . That would make it clear that these ebuilds are not Gentoo approved, but would provide a starting point for the user who would want to use such a package. I think that was always the main idea when overlays got introduced to portage. Sunrise just lowers the step to get these often mediocre ebuilds, people can get them right now, just not as easy. 2. QA for ebuilds is not just a question of making a package build, but also knowing what it does and how it would tie into Gentoo. The fact that some ebuild is semantically correct doesn't mean it is doing the right thing. Very few of the newly proposed ebuilds I handled and eventually committed was actually without major flaws. This was because the submitters lacked specific knowledge of either the eclasses to use and the environment it belonged in. In my case : any gnome ebuild fits in a larger set of applications/libraries that got more complex as time went by, it is not trivial to understand all the interactions that take place. Even Gentoo developers not in the gnome team make serious mistakes in this sense in my experience. 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. 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'. 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. As a developer I would not really think of Sunrise developers any different than someone coming 'fresh' to Gentoo developing. 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. 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. That aspect of Sunrise is not at all tackled in its goals. What are the longterm prospects of ebuilds in the Sunrise tree ? 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. * The rise of project Sunrise Now for the second big point concerning Sunrise : how it came into being. I checked back on the initial announcement, where it Sunrise was made public as an official Gentoo project without any prior discussion. The announcement actually stated 'This is an announcement - No flamewars allowed'. I guess the creators were already aware of the feelings of some other developers on this issue and decided to just go ahead instead of going through the proper channels (GLEP?) and do things as they wished. As we all know this can be very effective, but this particular time one of the largest and longest ongoing 'discussions' in Gentoo's history ensued. If you know it's flamewar material, why do you go ahead so bluntly with your project ? Why not go trough the proper channels and discuss it beforehand in a public place ? 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. * The implications of sunrise What will Sunrise mean to the general developer ? Again here I can share my experiences with a similar project, the infamous BMG was created with similar goals and turned out to be a serious nightmare for the gnome team. At a certain point in time every bug we got had to be double checked for possible overlay problems. I cannot count the times I had to spend hours on an unexplainable problem to find out in the end that it was caused by BMG ebuilds. This is incredibly destructive for my mood, not to mention the time wasted which could've been spent on real problems. The other side of the medal is that there are false-positives where you think it's BMG, but it really isn't and I can tell you that is not a nice experience for the user and dev alike. BMG was mainly gnome oriented, so a lot of devs may never have noticed such problems, but they surely existed for the gnome team. Another exponent of the BMG tree were the infamous love-sources which also caused inexplicable problems left and right, which may ring a bell with much more devs. 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. regards, Marinus -- gentoo-dev@gentoo.org mailing list