| 1 |
On Thu, 2006-03-23 at 18:55 +0000, Chris Bainbridge wrote: |
| 2 |
> On 23/03/06, Chris Gianelloni <wolf31o2@g.o> wrote: |
| 3 |
> > On Thu, 2006-03-23 at 16:40 +0000, Chris Bainbridge wrote: |
| 4 |
> > > If the software a user wants is in an overlay, then the user will be |
| 5 |
> > > forced to install the overlay. |
| 6 |
> > |
| 7 |
> > It shouldn't be in the overlay, is I think the point many are trying to |
| 8 |
> > make. If the software is good enough for any of our users, it should be |
| 9 |
> > good enough for the tree. |
| 10 |
> |
| 11 |
> I agree. I would ask, what are the advantages of overlays that |
| 12 |
> developers find so compelling that they use them rather than the |
| 13 |
> portage tree? Would it not be a better idea to find a way to bring |
| 14 |
> those advantages to the tree, rather the proliferation of overlays we |
| 15 |
> are seeing? |
| 16 |
|
| 17 |
The advantages we see are: |
| 18 |
|
| 19 |
We use it as a staging area for our herd's ebuilds. We can start with an |
| 20 |
untested ebuild and between several team members and outside testers we |
| 21 |
can iteratively test and refine the ebuild. This relies on a low latency |
| 22 |
between committing changes and other devs and outside testers receiving |
| 23 |
those changes. We have a lag of several seconds rather than 30 minutes |
| 24 |
for the anoncvs. It means we get much higher QA before ebuilds actually |
| 25 |
end up in portage because by the time they get there they have been |
| 26 |
reviewed and tested by other team members and outside helpers (often |
| 27 |
including testing on several arches). |
| 28 |
|
| 29 |
If we did this in the cvs tree we'd need to keep the packages masked all |
| 30 |
the time we were improving them (overhead). We'd need changelog entries |
| 31 |
for every change (overhead). We wouldn't be able to share the |
| 32 |
development and testing with our outside helpers (due to anoncvs lag). |
| 33 |
And of course we wouldn't be able to grant out outside helpers write |
| 34 |
access. |
| 35 |
|
| 36 |
So the lower latency helps to run an AT-style system and the write |
| 37 |
access allows for a safe intermediate stage in the recruitment process |
| 38 |
between AT and dev status. |
| 39 |
|
| 40 |
-- |
| 41 |
Duncan Coutts : Gentoo Developer (Haskell herd team lead) |
| 42 |
email : dcoutts at gentoo dot org |
| 43 |
|
| 44 |
-- |
| 45 |
gentoo-dev@g.o mailing list |
Archives