Re: [gentoo-dev] Sunrise contemplations

[Kevin F. Quinn]

On Mon, 31 Jul 2006 19:25:20 +0200
foser <foser@g.o> 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.
>
> * The rise of project Sunrise
>
> 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
>
> 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.

-- 
Kevin F. Quinn