Hi again
as written below I think it makes more sense for Project sunrise to redefine
it a bit. It seems to be clear that currently noone is happy with the
Sunrise Project.
There is one huge disadvantage for end users like me:
If we decide to use an overlay package (because "we" need / want the
functionality) we have to make sure from time to time that this one is up to
date.
BTW: This is not only time consuming but also inefficient.
Where is the difference to BMG? Two things:
a) Official development support (note: not an official overlay).
b) One overlay per development (team) project instead of an huge overlay
with maybe breaking stuff.
This is a different approach than the one of BMG:
"We want to provide unstable ebuilds, which have no chance to get into
portage."
How about this alternative:
Use sunrise (as stated earlier) as an "help me"-mailing list or whatever for
users who may want to become developers. Provide RSS feeds (as stated below
- a good idea I think) for end users.
How should it work (new dev view):
- A user want to add application (x) to portage. He creates a overlay and
uses bugzilla and so on.
- He is interested in adding his ebuild (or program (x)) permanently to
portage.
- This user requests help and support from the sunrise developers. The
guidelines say, that he should provide a RSS feed to inform users about new
versions of program (x) for Gentoo.
Why should he provide an overlay? Because it's easier for testing purposes
than downloading maybe a whole bunch of files from bugzilla.
How should it work (the sunrise project view):
- Sunrise works like an planet site. It scans the RSS feeds in specific
time intervals and add new entries to its own DB.
- Sunrise contains a DB for locations of overlays and contact details.
- Sunrise will provide functions for users to search on it (like
packages.gentoo.org) and to find information where the overlay is
located.
How should it work (sunrise dev view):
- The developer finds out that a new version of the ebuild exists. He
reviews the ebuild and gives feedback to the developer.
- He uses contact details that the "taker" used to register at sunrise.
How should it work (end users view):
- Load a RSS feed into your favorite RSS viewer and you're done. Of course
you still have to use layman or whatever to update the overlays manually. Is
there a way to integrate this functionality into emerge --sync?
Advantages:
- Easy to search and up to date DB for custom Gentoo overlays
- Helpful information and feedback from Gentoo developers.
- Learning by doing approach.
Disadvantages:
- Still different places all over the net for overlays.
- Possibility that two teams create ebuilds for the same program.
- Different development forms. Somehow there have to be a way that third
parties provide improved ebuilds.
- Maybe complicated rules: After x days inactivity, the project should be
given to new takers and so on.
What do you think?
Best regards
PS.: This is just an early idea. Maybe you will find some not logical points
here or things that already exist in the www ...
Edward Catmur writes:
On Fri, 2006-06-09 at 02:53 +0200, Stefan Schweizer wrote:
<SNIP>
Encouraged? If you leave it at that, people will forget, and things will
get out of sync. At the very least you should supply per-package rss
feeds and email subscriptions. Otherwise this will be a downgrade in
functionality from the current bugzilla system. (Which I think is
perfectly fine as it is.)
<SNIP>
--
gentoo-dev@gentoo.org mailing list
