On Mon, Oct 29, 2007 at 12:00:11PM -0500, Aaron Griffin wrote:
On 10/29/07, Jason Chu <jason@archlinux.org> wrote:
On Mon, Oct 29, 2007 at 10:38:52AM -0500, Aaron Griffin wrote:
On 10/29/07, Jason Chu <jason@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