Re: [gentoo-dev] Sunrise contemplations

[Tobias Klausmann]

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@g.o mailing list