[gentoo-dev] Sunrise contemplations

[foser <foser@gentoo.org>]

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