public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Aron Griffis <agriffis@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: Ryan Phillips <rphillips@gentoo.org>, stuart.herbert@gmail.com
Subject: Re: [gentoo-dev] overlay support current proposal?
Date: Sat, 25 Mar 2006 18:00:49 -0500	[thread overview]
Message-ID: <20060325230048.GA2691@olive.flatmonk> (raw)
In-Reply-To: <20060325064751.GA8104@trolocsis.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 4275 bytes --]

Ryan Phillips wrote:  [Sat Mar 25 2006, 01:47:51AM EST]
> It sounds to me like the overlays would benefit of using git/cogito.
> The Linux Kernel uses this DVCS to full affect. Pulling changes from
> other repositories, and even receiving email patches pushed from
> people not having their own official repository (or repository http
> or ssh accessible).  Any git checkout is a branch, so its easy to
> stay up to date with the mainline tree and still work on personal
> branches.

Most of the other DVCSs are easier to use than git, and just as
powerful or more.  IMHO git is used for Linux mostly because Linus
wrote it, rather than it being the best tool for the job.

I think any of mercurial, darcs or bazaar-ng is a better choice than
git.  Regarding cogito, I haven't looked at it in a while, but the
last time I did, it was underpowered and buggy.  AFAIK none of the
kernel developers use it, 'cause it doesn't hold up under serious use.

> We need to pick one VCS and only one.  Having multiple systems
> requires users to install multiple applications and learn each one.
> Not all of them are easy to pick up.  Plus, it would be nice to be
> able to merge from the overlays to the Portage trunk.

This would be pretty neat eventually, to switch portage itself over to
a DVCS so that all the overlays would simply be branches that could be
merged, etc.  At this point it would be biting off more than we can
chew, though...  Perhaps using various DVCS solutions for the overlays
might actually be a good testing ground for determining the successor
to cvs for the actual portage tree.

At any rate, I don't think it's necessary to limit ourselves to one.
You're right, developers will have to install multiple applications
and learn each one for the overlays they work on.  Probably it won't
be that many, though (overlays or applications) and r/o users will
likely just get an rsync'd copy instead of using the DVCS to access
the overlay (at least that's how I imagine it working...)

> I think git/cogito might be the solution.  It works for a highly
> distributed kernel development, which would be similar to the way
> the overlays would work.  Gentoo User A would checkout the kde
> overlay, make some changes, cg-commit them to their own overlay, and
> submit the patches upstream via an email requesting a pull, or
> emailing them patches directly with a git-mkmail command.

*shrug*  All possible with the other DVCSs, generally easier to use,
and harder to screw up your repo.

> An alternative to git would be using subversion.  
> 
> *** The main portage tree should be switched away from CVS. ***
> There are much better alternatives (svn or git) to use.

Have you followed the threads in the past regarding using other
version control systems for portage?  Some devs have done benchmarks
and found that there are blocking issues with subversion, particularly
because of its repo-wide revisions that prevent multiple commits from
happening simultaneously.

> CVS is our bottleneck when it comes to development and our users
> too.  What I see is that the overlays are trying to create branches,
> when they should not need to.  Making a PHP or Gnome v2000 overlay
> is ridiculous, since a branch is almost free using subversion.
> There are more advantages, like making sure the rest of the tree
> doesn't break, and when the branch is stable for package.mask or
> arch masking then merge the branch to trunk.  The main tree could
> live within subversion (or whatever VCS we choose) as a branch.  It
> would be easy to keep the branch up to date with trunk, and then
> merge the changes to the live branch.  Major changes to the tree
> need to be done in a branch where it should be done.
> 
> Overlays should be used only for small additions/changes/or tests.
> It feels like the overlays are already trying to create branches,
> when in fact, they would not have to if the main tree was _not_ in
> CVS.

I agree this sounds really nice and makes a lot of sense.  I think
that the overlay project is a step toward this, though, not a step
away.  The time isn't yet ripe for switching the portage tree to
different VCS.

> Comments?

I guess you asked... :-)

Aron

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

  parent reply	other threads:[~2006-03-25 23:03 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-24 19:35 [gentoo-dev] overlay support current proposal? Grant Goodyear
2006-03-24 19:54 ` Aron Griffis
2006-03-24 20:06 ` Daniel Ostrow
2006-03-24 20:13   ` Daniel Ostrow
2006-03-24 20:44   ` Stuart Herbert
2006-03-25  0:34     ` Alec Warner
2006-03-25  2:31     ` Diego 'Flameeyes' Pettenò
2006-03-25 11:41       ` Duncan Coutts
2006-03-25 11:49         ` Diego 'Flameeyes' Pettenò
2006-03-25 15:08           ` Carsten Lohrke
2006-03-25 18:50             ` Diego 'Flameeyes' Pettenò
2006-03-25 20:36               ` Carsten Lohrke
2006-03-25 22:17                 ` Stephen P. Becker
2006-03-25 11:42       ` Kevin F. Quinn (Gentoo)
2006-03-25 11:46         ` Duncan Coutts
2006-03-25 12:32           ` Kevin F. Quinn (Gentoo)
2006-03-25 12:37             ` Duncan Coutts
2006-03-25 13:28               ` Kevin F. Quinn (Gentoo)
2006-03-25 11:47         ` Diego 'Flameeyes' Pettenò
2006-03-25  6:47     ` Ryan Phillips
2006-03-25 11:55       ` [gentoo-dev] " Duncan
2006-03-25 23:00       ` Aron Griffis [this message]
2006-03-25 23:12         ` [gentoo-dev] " Aron Griffis
2006-03-25 23:20           ` Fernando J. Pereda
2006-03-25 23:18         ` Fernando J. Pereda
2006-03-26  0:57           ` Aron Griffis
2006-03-26  9:54             ` Fernando J. Pereda
2006-03-26 20:28             ` Greg KH
2006-03-27  5:43         ` Ryan Phillips
2006-03-27  8:29           ` Paul de Vrieze
2006-03-27 20:58             ` Dan Armak
2006-03-28  9:25               ` Paul de Vrieze
2006-03-27  8:51           ` Chris Bainbridge
2006-03-27 14:15             ` Chris Gianelloni
2006-03-26  1:30       ` Duncan Coutts
2006-03-26  4:39         ` Luca Barbato
2006-03-26  9:57           ` Fernando J. Pereda
2006-03-28 16:29             ` Patrick McLean
2006-03-30 12:40               ` Stuart Herbert
2006-03-30 18:54                 ` Aron Griffis
2006-03-31  8:16                   ` Stuart Herbert
2006-03-31  8:24                     ` Fernando J. Pereda
2006-03-31 11:36                       ` Duncan Coutts
2006-03-30 14:08               ` Nguyễn Thái Ngọc Duy
2006-03-25 10:16     ` Luca Barbato
2006-03-25 23:04       ` Aron Griffis
2006-03-25 23:32         ` Luca Barbato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060325230048.GA2691@olive.flatmonk \
    --to=agriffis@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=rphillips@gentoo.org \
    --cc=stuart.herbert@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox