| 1 |
On Wed, 2006-03-22 at 09:03 -0800, Donnie Berkholz wrote: |
| 2 |
> Stuart Herbert wrote: |
| 3 |
> > I've been very happy with using svn+trac overlays to bridge this gap. |
| 4 |
> > They provide a sandbox for contributions to be shared and evaluated. |
| 5 |
> > They provide a place where I've been able to give commit access to |
| 6 |
> > non-devs, so that they can learn the ropes w/out threatening the |
| 7 |
> > Portage tree proper. They provide a place where people who just want |
| 8 |
> > to write docs for a single package can contribute. |
| 9 |
> > |
| 10 |
> > Overlays create a sense of participation that's lacking with Bugzilla |
| 11 |
> > patch submissions. Backed up with regular communication (I recommend |
| 12 |
> > not recruiting anyone who won't spend time in the IRC channels, but |
| 13 |
> > that's a personal preference), they help us get things done quicker. |
| 14 |
> > |
| 15 |
> > The downside with overlays at the moment is that they're scattered |
| 16 |
> > around the net, and if you don't know where to look they can be very |
| 17 |
> > hard to find. I've been talking with infra about providing |
| 18 |
> > overlays.g.o as a central hosting service for herd and individual |
| 19 |
> > developer overlays. Infra have been very supportive of the idea. I |
| 20 |
> > just need to free up some time to get the service launched. |
| 21 |
> |
| 22 |
> This definitely sounds like a fun idea. It would be even cooler if we |
| 23 |
> were using a distributed SCM on both ends that allowed for easy merging. |
| 24 |
|
| 25 |
We do this within the Haskell herd and with a small handful of outside |
| 26 |
contributers. We use darcs for our distributed SCM which makes the |
| 27 |
merging trivial. |
| 28 |
|
| 29 |
If works like so: |
| 30 |
We keep our testing ebuilds in a shared overlay managed with darcs. |
| 31 |
The Haskell herd members have write access. Trusted external |
| 32 |
contributers have write access to the overlay too (mostly people who are |
| 33 |
in the middle of the recruitment process). The existing devs are of |
| 34 |
course responsible for actually committing anything to portage cvs. |
| 35 |
Other contributers have read only access but they can "darcs send" us |
| 36 |
patches. These do not automatically get applied (as with our trusted |
| 37 |
contributers) but get emailed to us and any Haskell herd dev can review |
| 38 |
and apply patches sent in this manner quite easily. |
| 39 |
|
| 40 |
We have found that this system works rather well. It allows our testers |
| 41 |
and helpers to participate in writing ebuilds which has made the |
| 42 |
recruitment process smoother. It provides an intermediate phase in the |
| 43 |
recruitment process where they can participate in the herd's work |
| 44 |
without any danger of messing up portage cvs. Bugzilla is ok for |
| 45 |
submitting whole new ebuilds but it's got far too large an overhead for |
| 46 |
one line patches. Using darcs gives us a very low overhead. |
| 47 |
|
| 48 |
We also use the shared overlay as a testing zone for our herd's ebuilds. |
| 49 |
Our modus-operandi is to commit changes in ebuilds to the overlay, get |
| 50 |
peer review from other herd members and then commit to portage when we |
| 51 |
are satisfied. Of course this also makes it easy for our testers to keep |
| 52 |
up with the latest versions of ebuilds. With the combination of darcs |
| 53 |
and irc, we can get very quick turnaround on our testers finding bugs to |
| 54 |
fixing them and getting those changes back to our testers. |
| 55 |
|
| 56 |
-- |
| 57 |
Duncan Coutts : Gentoo Developer (Haskell herd team lead) |
| 58 |
email : dcoutts at gentoo dot org |
| 59 |
|
| 60 |
-- |
| 61 |
gentoo-dev@g.o mailing list |
Archives