On Tue, Sep 11, 2012 at 6:18 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Tue, 11.09.12 09:52, Kevin Fenzi (kevin@xxxxxxxxx) wrote: > >> > > This would give packagers much more flexibility about branching and >> > > would also simplify our model as the master branch would just go >> > > away... One branch less that can be confused is a win for >> > > everybody. >> > >> > I don't see a problem with that, but then I'm just the monkey :) >> >> So, the biggest problem is that in the past, FESCo has said that >> rawhide should never "go back" in versions. If we change the >> inheritance to pull from say f18-updates-testing, it means if an update >> was pulled it also would 'disappear' from rawhide the next day. >> >> If I was wanting a f19 branch for my big library build and I needed to >> build a new systemd version, could I branch it? or that would only be >> up to you? (ie, would it be any package maintainer, or just people with >> acls to the package). > > Everybody with commit access to he package should be able to create a > branch of it I guess. > >> How do we tell pkgdb that there is a new branch? Currently it's done >> at mass branch time, but in this model there would have to be some way >> for maintainer/brancher to tell it. > > Well, maybe the "mass branch time" should continue to exist, but instead > of actually doing any mass branching it would just be the point in time > where pkgdb learns that a new branch might now exist in the package > repos even though many packages won't have it any time soon. Wouldn't it already help if the build system would just refuse to build newer versions in branches than which are in rawhide at that moment? Kay -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
