[arch-dev-public] Killing CVS [was: Status Report 2007-10-15]

[Jason Chu]

On Mon, Oct 29, 2007 at 12:00:11PM -0500, Aaron Griffin wrote:
> On 10/29/07, Jason Chu <jason at archlinux.org> wrote:
> > On Mon, Oct 29, 2007 at 10:38:52AM -0500, Aaron Griffin wrote:
> > > On 10/29/07, Jason Chu <jason at archlinux.org> wrote:
> > > > And it helps to treat package repositories as branches... though... how do
> > > > you know what PKGBUILD to use for a repository other than core/extra?
> > > > There's a test_kernel24, test_kernel, and test_udev.  Each of them have
> > > > different versions of kernel24, kernel, and udev.
> > > >
> > > > In the svn suggestion, we're explicit about which version is in testing,
> > > > how would we figure it out in git?
> > >
> > > The intent is to actually have two different versions. If
> > > 'test_kernel' and 'test_udev' spawned off their own mini-repos, each
> > > would have a kernel24. They would need to be merged to the master
> > > branch later.
> > >
> > > When Dan and I talked about this, the whole purpose was experimental
> > > features and/or rebuilds. Here's a use-case:
> > >
> > > Paul makes his AUFS changes to the kernel on a test_aufs branch (which
> > > may include the aufs and aufs-utils packages too). This allows the
> > > normal kernel to continue on as planned. People test it, everyone
> > > likes it, changes get rebased a few times, and eventually merged to
> > > master.
> >
> > Ah, so this would get rid of the testing repo entirely.  Instead we'd have
> > "topic" package repos that would have specific changes contained within
> > them.  If that's the case, I like it.
> 
> In a way, yes. Depending on the nomenclature we use though, we could
> always have a branch called "testing" that makes the testing repo.
> 
> It's a harder sell, but the functionality is there. How we actually
> use it can be molded a little as we go.

Yeah, the big problem with this sort of system and having a testing
branch/repo with it is that we like to release individual packages from
testing instead of migrating the whole thing all at once.  Cherrypicking at
that point becomes quite tedious if possible at all.

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20071029/8377d42b/attachment.pgp>