On Tue, 11.09.12 09:52, Kevin Fenzi (kevin(a)scrye.com) 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.
Lennart
--
Lennart Poettering - Red Hat, Inc.