Sunrise contemplations

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-devgentoo.org mailing list

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-devgentoo.org mailing list

On Tue, 1 Aug 2006 10:21:53 +0200
Tobias Klausmann <klausmanschwarzvogel.de> wrote:

> 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).

emerge --info can easily be forged. I've seen people asking
for help on
#gentoo do it a few too many times (some even refuse to
provide it),
and have wasted precious minutes not just wondering what the
error
messages meant, but also whether I could trust the user.

Having to do the latter of these could hardly be called
"supportive" of
Gentoo's user base, yet every so often you have to
investigate whether
a user has been absolutely truthful about his or her
problem. Sometimes
users have built their entire system using -fomg-fastwoah
only to see
the system collapse at the NNth package, sometimes they've
copied some
ebuilds/eclasses from an overlay. Sometimes they don't even
use Gentoo
but go for the massive numbers of users and guess that
someone in
#gentoo ought to be able to help them with their home-built
packages.

The only way to have people submit emerge --info properly
and reliably
would be to set up an online ticketing system - something
like this:


# emerge --submit-info

* sys-apps/portage generates emerge --info output and
uploads it
relatively tamper-proof to tickets.g.o, and

* returns a ticket to the user, a unique number that he or
she can
communicate to developers and active users through a URL
like
http://tickets.g.o
/#ticket-number.

* --submit-info includes information about the emerge
commandline that
was run last and what category/package/version emerge was
building/installing at the time.


This not only makes it a lot easier to find the causes of
any bugs or
other problems, which helps Gentoo get the user entry level
down,
in chime with efforts like the Gentoo Linux Installer
project, it
might also help ensure that bug reports will in all
likelihood not have
been tampered with, since tampering with the info would
require
tampering with sys-apps/portage.

Now, do I appear to sound mistrustful of Gentoo users?
Perhaps. Perhaps,
this --submit-info stuff reminds you of Product Activation
routines
used by closed source software vendors. Perhaps you think I
am being
paranoid. Maybe you think that FOSS should be a free-for-all
exchange
of meaningful information, which I would whole-heartedly
agree with -
the information would be meaningless if could not trust it.

All I know is that too many bugs on bugs.g.o and too many
questions on
#gentoo remain unsolved or unanswered because of a lack of
reliable
information. --submit-info would not only help improve bug
handling,
but would also give the Gentoo Project useful feedback about
its users.
Developers could require such a ticket to resume or even to
start
analysing a bug.

It's a far cry from what Gentoo originally was supposed to
be, I admit.
I am not even going to argue that this ticket system is
necessary or
should be adopted by all developers once it has been
implemented - it is
a means to an end, or perhaps several ends, none of which
are required
to further develop Gentoo.


Kind regards,
     JeR
-- 
gentoo-devgentoo.org mailing list

Hi! 

On Tue, 01 Aug 2006, Jeroen Roovers wrote:
> On Tue, 1 Aug 2006 10:21:53 +0200
> > 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).
> 
> emerge --info can easily be forged. I've seen people
asking for
> help on #gentoo do it a few too many times (some even
refuse to
> provide it), and have wasted precious minutes not just
> wondering what the error messages meant, but also
whether I
> could trust the user.

I don't doubt your claim, yet I find it incredible. I'm
constantly amazed at how stupid some people are. Not to
mention
how many idiotic assholes are out there.

> The only way to have people submit emerge --info
properly and reliably
> would be to set up an online ticketing system -
something like this:
> 
> 
> # emerge --submit-info
> 
> * sys-apps/portage generates emerge --info output and
uploads it
> relatively tamper-proof to tickets.g.o, and
> 
> * returns a ticket to the user, a unique number that he
or she can
> communicate to developers and active users through a
URL like
> http://tickets.g.o
/#ticket-number.
> 
> * --submit-info includes information about the emerge
commandline that
> was run last and what category/package/version emerge
was
> building/installing at the time.

I think this is a very good idea. Better than mine.

> Now, do I appear to sound mistrustful of Gentoo users?
Perhaps.
> Perhaps, this --submit-info stuff reminds you of
Product
> Activation routines used by closed source software
vendors.
> Perhaps you think I am being paranoid. Maybe you think
that
> FOSS should be a free-for-all exchange of meaningful
> information, which I would whole-heartedly agree with -
the
> information would be meaningless if could not trust it.

I think it's critical how you sell this: don't say
"this is
because we can not trust you" but "this is
because it makes it
easier for you to send all relevant info". While it
may seem
phone-home-ish, the contained info is clearly traceable and
everybody can see that there's nothing sensitive in there.

Feedback agents to which I can have the source are much less
suspicious than binary blobs that send gobs and gobs of
binary
info to their home.

> It's a far cry from what Gentoo originally was
supposed to be,
> I admit.  I am not even going to argue that this ticket
system
> is necessary or should be adopted by all developers
once it has
> been implemented - it is a means to an end, or perhaps
several
> ends, none of which are required to further develop
Gentoo.

Yet I think it's a good idea. Just don't misuse it as a
tool to
spy on users. *Don't* turn it into something that pulls
more info
than gentoo-stats (and then some).

Regards,
Tobias
-- 
You don't need eyes to see, you need vision.
-- 
gentoo-devgentoo.org mailing list

On 8/1/06, Jeroen Roovers <jergentoo.org> wrote:
> # emerge --submit-info
>
> * sys-apps/portage generates emerge --info output and
uploads it
> relatively tamper-proof to tickets.g.o, and
>
> * returns a ticket to the user, a unique number that he
or she can
> communicate to developers and active users through a
URL like
> http://tickets.g.o
/#ticket-number.
>
> * --submit-info includes information about the emerge
commandline that
> was run last and what category/package/version emerge
was
> building/installing at the time.

Like you, I'm not sure this is necessary, but I like it. I
like it
even more when I think that the flags and other
configuration options
that are in make.conf at the time you 'emerge --info' are
not
necessarily the same as those you used when, maybe a long
time ago,
you emerged the dependencies of the package that breaks.
Let's imagine
we have :

# emerge --submit-info package-that-breaks

If that creates a compressed tarball of all (or selected
relevant)
data in /var/db/pkg concerning all packages that
package-that-breaks
depends on, I like it a lot. This will give more useful
information
than 'emerge --info'. And I'm not only thinking of forged
'emerge
info', but also of those users and developers that play
with flags
because they like it or have to, and then forget to revert
to safe
flags. I'm sure there are many legitimate ways to make such
mistakes.
You end up having some parts of your system built with
stupid flags,
and you don't feel guilty about it because you don't even
know (this
happened to me already).

So yes, I'd love to see something like this someday. And
I'd love to
help implementing it if such a decision was taken. But the
question
remains : it obviously looks useful, but do we need it ?

Denis.
-- 
gentoo-devgentoo.org mailing list

On Mon, 31 Jul 2006 19:25:20 +0200
foser <fosergentoo.org> 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

foser wrote:

> 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 ?

That's just the way to do it.

Excerpt from the metastructure model, chosen by the majority
of devs
last year (and not my model):

htt
p://www.gentoo.org/proj/en/glep/glep-0039.html
=================================================
A project is a group of developers working towards a goal
(or a set of
goals).

* A project exists if it has a web page at
www.g.o/proj/en/whatever that
is maintained. ("Maintained" means that the
information on the page is
factually correct and not out-of-date.) If the webpage
isn't maintained,
it is presumed dead.

* It may have one or many leads, and the leads are selected
by the
members of the project. This selection must occur at least
once every 12
months, and may occur at any time.

* It may have zero or more sub-projects. Sub-projects are
just projects
that provide some additional structure, and their web pages
are in the
project's space.

* Not everything (or everyone) needs a project.

* Projects need not be long-term.

* Projects may well conflict with other projects. That's
okay.

* Any dev may create a new project just by creating a new
page (or, more
realistically, directory and page) in
gentoo/xml/htdocs/proj/en.
=================================================

So you can create projects by creating a directory in
gentoo/xml/htdocs/proj/en, you don't have to announce it
(but it's
polite to do so), and it may well conflict with other
projects, that's okay.

You can't blame them for following the right rule. You can
blame the
rule, though.

-- 
Koon
-- 
gentoo-devgentoo.org mailing list

On Wed, 02 Aug 2006 12:00:56 +0200 Thierry Carrez
<koongentoo.org>
wrote:
| So you can create projects by creating a directory in
| gentoo/xml/htdocs/proj/en, you don't have to announce it
(but it's
| polite to do so), and it may well conflict with other
projects,
| that's okay.
| 
| You can't blame them for following the right rule. You
can blame the
| rule, though.

You're forgetting the other rule about GLEPs being required
for changes
that impact lots of people...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-devgentoo.org mailing list

Ciaran McCreesh wrote:
> On Wed, 02 Aug 2006 12:00:56 +0200 Thierry Carrez
<koongentoo.org>
> wrote:
> | So you can create projects by creating a directory in
> | gentoo/xml/htdocs/proj/en, you don't have to
announce it (but it's
> | polite to do so), and it may well conflict with other
projects,
> | that's okay.
> | 
> | You can't blame them for following the right rule.
You can blame the
> | rule, though.
> 
> You're forgetting the other rule about GLEPs being
required for changes
> that impact lots of people...

One could argue that since the metastructure policy was
approved more 
recently, anything in it that contradicts previous rules
takes 
precedence. "Freedom to make new projects
anytime" beats "must use GLEP 
for significant new feature."

Thanks,
Donnie
-- 
gentoo-devgentoo.org mailing list

On Wed, 02 Aug 2006 07:07:31 -0700 Donnie Berkholz
<dberkholzgentoo.org> wrote:
| One could argue that since the metastructure policy was
approved more 
| recently, anything in it that contradicts previous rules
takes 
| precedence. "Freedom to make new projects
anytime" beats "must use
| GLEP for significant new feature."

The metastructure policy doesn't override anything it
doesn't
explicitly say it overrides...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-devgentoo.org mailing list