| 1 |
Stuart Herbert <stuart.herbert@×××××.com> said: |
| 2 |
> Thanks for the summary. I think that's a fair assessment of where we are at. |
| 3 |
> |
| 4 |
> The offered software will be trac, svn, and moinmoin. I'm going to |
| 5 |
> look at darcs, and with the help of the haskell team and infra |
| 6 |
> determine if we can support it or not. No-one has expressed a |
| 7 |
> preference for a different distributed VCS instead of darcs. |
| 8 |
> |
| 9 |
> Just one more thing ... |
| 10 |
|
| 11 |
It sounds to me like the overlays would benefit of using git/cogito. |
| 12 |
The Linux Kernel uses this DVCS to full affect. Pulling changes from |
| 13 |
other repositories, and even receiving email patches pushed from |
| 14 |
people not having their own official repository (or repository http or |
| 15 |
ssh accessible). Any git checkout is a branch, so its easy to stay up |
| 16 |
to date with the mainline tree and still work on personal branches. |
| 17 |
|
| 18 |
We need to pick one VCS and only one. Having multiple systems |
| 19 |
requires users to install multiple applications and learn each one. |
| 20 |
Not all of them are easy to pick up. Plus, it would be nice to be |
| 21 |
able to merge from the overlays to the Portage trunk. |
| 22 |
|
| 23 |
I think git/cogito might be the solution. It works for a highly |
| 24 |
distributed kernel development, which would be similar to the way the |
| 25 |
overlays would work. Gentoo User A would checkout the kde overlay, |
| 26 |
make some changes, cg-commit them to their own overlay, and submit the |
| 27 |
patches upstream via an email requesting a pull, or emailing them |
| 28 |
patches directly with a git-mkmail command. |
| 29 |
|
| 30 |
An alternative to git would be using subversion. |
| 31 |
|
| 32 |
*** The main portage tree should be switched away from CVS. *** |
| 33 |
There are much better alternatives (svn or git) to use. |
| 34 |
|
| 35 |
CVS is our bottleneck when it comes to development and our users too. |
| 36 |
What I see is that the overlays are trying to create branches, when |
| 37 |
they should not need to. Making a PHP or Gnome v2000 overlay is |
| 38 |
ridiculous, since a branch is almost free using subversion. There are |
| 39 |
more advantages, like making sure the rest of the tree doesn't break, |
| 40 |
and when the branch is stable for package.mask or arch masking then |
| 41 |
merge the branch to trunk. The main tree could live within subversion |
| 42 |
(or whatever VCS we choose) as a branch. It would be easy to keep the |
| 43 |
branch up to date with trunk, and then merge the changes to the live |
| 44 |
branch. Major changes to the tree need to be done in a branch where |
| 45 |
it should be done. |
| 46 |
|
| 47 |
Overlays should be used only for small additions/changes/or tests. It |
| 48 |
feels like the overlays are already trying to create branches, when in |
| 49 |
fact, they would not have to if the main tree was _not_ in CVS. |
| 50 |
|
| 51 |
There are advantages to subversion and advantages to git. I propose |
| 52 |
picking one (I vote for subversion) to use for the overlays. I also |
| 53 |
believe that CVS is now hindering us from reaching our goals as a |
| 54 |
project. |
| 55 |
|
| 56 |
Comments? |
| 57 |
|
| 58 |
-Ryan |
Archives