Hi! I'm not a dev (just someone donating 10GB of traffic per day from his private server to Gentoo), but that's exactly why I think I need to chime in.
On Mon, 31 Jul 2006, 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. You're kidding, right? I for one simply can't spare the time to become involved as a dev. Now before you're starting to say that I'm a freeloader and I should just deal with what's there, a few remarks: - I *do* contribute. My private rsync-server has served over a terabyte of data since I've been running it for Gentoo (somewehre in 2002? Years ago, in any case) - I do contribute to other F/OSS projects. Do I have to contribute to any project where I'd like to see a change? Isn't a enhancement reuqest a kind of contribution (as long as it's beyond "this sucks, change it!") > 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. It's about user experience. I'm not saying any and all M-W ebuilds should get into the tree, but I have a strong feeling that *more* should go in - in unison with stale stuff being removed. But the latter is another project: treecleaners (at least from what I've read). I think Gentoo has a sort-of Debianesque problem: the tree is ever growing which results in growing pains (Debian has other pains but the problem is growth, still). I don't know any other remedy than to keep the tree lean - but not only by being wary of too many new ebuilds. Old ones have to go, too. As a result, a question: how many Gentoo users need to voice interest in an ebuild/package to make it "wortwhile"? I initially provided an ebuild for a package I maintain. I also provide a new ebuild for every new version. For this, proxy maintainership is the thing to do, IMO. > 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. What about those that are able to put together a dead simple ebuild and just want it submitted and *not* rot in Bugzilla? I can understand that some people go for sunrise because some of their ebuild submissions just went stale and then started to rot in bgo. As for official vs. non-official: I don't care either which way. I think it's mostly about truth in advertising: If it's treated by the majority as being official, it's official. As for URLs: how do you think phishing works? People (mostly) don't look too closely at URLs. The layout/logos etc of a page are an entirely different matter. Just my EUR0.02 > 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. Well, I think having more candidates will not only result in more "rejects" but also in more acceptable devs. As for the entry step: maybe it's too high now and with Sunrise one could find out where the sweet spot for it lies? Also: do you really want to have junior devs that are only in it for the influence? > 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. So? Then Sunrise is a training ground. I don't see harm in that. > 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. Being a dev is three things I'd say: create, maintain, remove. Some may lean more to any of the three (we're humans, after all). The major part of the "workforce" should do maintenance, though. This is independent of portage, btw, most other projects would fall into the three-fold as well. As for the ebuilds in Sunrise: Think of it as an ebuild checker which is at least theoretically more capable than any automated system: There are humans involved that are willing to check it. People who use Sunrise as an overlay and then come whining to bgo about their failed ebuild can be told. Idea: should it be more obvious in emerge --info and ebuild failure that an overlay is involved? If it's obvious enough, I don't see a problem. Also, a command that lists all installed packages that come from an overlay might be useful (maybe even a sa part of --info). > * The rise of project Sunrise > > Now for the second big point concerning Sunrise : how it came into > being. On this, I can hardly comment because I know very little of the lifecycle of Gentoo projects. Also: if an idea is good, it may be stained a bit if it's put through with the wrong measures. That doesn't make it a *bad* idea out of the blue, though. > * 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. This might be alleviated with the more prominent warning display in --info as I noted above. > 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. I do understand this. There's little more frustrating than trying to fix one's own stuff and after hours of running into walls finding out that the problem was caused in some completely different part of the world. > 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. Again: if you can be sure of the overlay-status of packages, this might be less of a nightmare. > This is can be really demotivating, which is probably the worst > thing about it. That I agree on: if it's a motivation killer, it should be bound to a rock and dumped in a lake. I just think that it can be improved enough to not be such a dev nightmare. But then, I'm just a user and a server admin. Regards, Tobias -- You don't need eyes to see, you need vision. -- gentoo-dev@gentoo.org mailing list
