| 1 |
On 23/03/06, Stuart Herbert <stuart.herbert@×××××.com> wrote: |
| 2 |
> > > The vision I have for overlays.g.o is one official home for all Gentoo |
| 3 |
> > > overlays run by projects and by individual Gentoo devs. I see the |
| 4 |
> > Also for Arch/Herd Testers? |
| 5 |
|
| 6 |
The discussion seems to have moved from the original "how can we |
| 7 |
become more open to enable our users to contribute?" to "how to |
| 8 |
provide testing overlays for existing gentoo devs". I think that the |
| 9 |
use of overlays is more a symptom of a problem with portage. Overlay |
| 10 |
problems: |
| 11 |
|
| 12 |
They remove ebuilds from the tree |
| 13 |
Users have to add yet another overlay / retrieve the ebuilds somehow |
| 14 |
Conflicts between overlays |
| 15 |
Increases time to moving packages into the tree |
| 16 |
Overlay becomes a developers "personal space" making it difficult to |
| 17 |
contribute if package is neglected (though that is also a problem |
| 18 |
now...) |
| 19 |
Lose repository metadata moving a package from overlay to tree |
| 20 |
Reduced responsibility for package QA (I expect "we don't care about |
| 21 |
overlays" to become a standard response on bugs.g.o) |
| 22 |
|
| 23 |
And what do we gain: |
| 24 |
|
| 25 |
Eases testing - can push in alpha quality ebuilds |
| 26 |
Developers feel safer because they can't break the tree |
| 27 |
|
| 28 |
Surely the solution is to provide that safety net within the tree? |
| 29 |
Rather than pushing changes into a live tree, push them into a testing |
| 30 |
tree, then after they pass repoman/QA checks, and a build check, apply |
| 31 |
the changes to the live tree, otherwise email a rejection. And allow |
| 32 |
developers to add their own testing ebuilds to the tree (for a start, |
| 33 |
they will be more widely tested). |
| 34 |
|
| 35 |
The current system of overlay usage is very annoying for users, |
| 36 |
particularly when bugs are hanging around with packages in the tree, |
| 37 |
and after filing bug reports the user is told that the bug is already |
| 38 |
fixed in the overlay. Or when new packages are added to overlays |
| 39 |
instead of the tree. How are users expected to find them? |
| 40 |
|
| 41 |
Another thing that needs fixing is the massive number of packages that |
| 42 |
aren't really maintained. Either the maintainer doesn't respond to |
| 43 |
bugs, or the package is maintained by a herd and so no one feels it's |
| 44 |
actually their responsibility to deal with the boring bugs, and when |
| 45 |
some developer outside of the herd comes across it, they feel like |
| 46 |
they can't fix the bug without stepping on someone's toes. What's |
| 47 |
worse is that in a lot of these cases there will be a user on bugs.g.o |
| 48 |
posting fixes and new ebuilds, and yet they never make it into the |
| 49 |
tree. |
| 50 |
|
| 51 |
A system where developer ebuilds are kept in the tree, and users have |
| 52 |
a way to automatically contribute ebuilds, either human reviewed, or |
| 53 |
in some reputation based system, would be very useful. Users also need |
| 54 |
feedback - how many times does a user submit an ebuild via bugzilla to |
| 55 |
be told that it doesn't meet QA standards? Why isn't there a system in |
| 56 |
place to run repoman/QA/build checks on user ebuilds/patches to make |
| 57 |
sure they are fixed *before* being submitted for inclusion into the |
| 58 |
tree? And if this could be linked to a bug reporting system where |
| 59 |
people report/fix individual ebuilds or packages, and I can just type |
| 60 |
'gbugs -l pkgname' and get a list of problems and fixes that other |
| 61 |
people have proposed, even better. |
| 62 |
|
| 63 |
I'm not sure whether the answer is more openness of the existing |
| 64 |
system, some custom submission flow system, or a distributed SCM, but |
| 65 |
I do think there's a lot that could be changed to make things better. |
| 66 |
|
| 67 |
-- |
| 68 |
gentoo-dev@g.o mailing list |
Archives