On 09/20/2011 09:18 PM, Jesse Keating wrote:
> On Sep 20, 2011, at 11:11 AM, Panu Matilainen wrote:
>>
>> My personal pet-peeve with the current branching policy is that
>> the mass-branching happens way way too early for packages where
>> there are no significant new development to be introduced in
>> rawhide during branched state. So for every single tiny fix that
>> needs to go in, it needs to be built into rawhide and also
>> branched. Minor annoyance maybe but annoying things tend to get
>> negletted - perhaps this is one of the reasons for rawhide lagging
>> behind branched.
>
> This isn't quite correct. If you haven't built anything explicitly
> for Rawhide since the branch point, the stable packages from the
> branched repo will be inherited into rawhide.
>
> You still should merge your changes from the branch up to master (for
> rawhide) but there is no reason to do a build. Let the build system
> inheritance take care of that.
>
> One change to make this better might be to move the inheritance point
> to updates-testing so that things built from the fresh branch are
> immediately inherited into rawhide.
Besides changing rawhide to inherit from Branched updates-testing, I
would also advocate for some additional process changes.
With the current no frozen rawhide process, I very much like how Bodhi
and the QA that gets introduced at the Alpha freeze has a nice calming
effect on the flow of new packages. People actually start testing things
before building for Branched.
What I don't like about the current no frozen rawhide process is that
Branched and rawhide start diverging way too early, when in reality
everybody just wants to keep the two branches in sync. Lets face it, we
just don't have the manpower to keep two separate development branches
around for such a long time.
I would also like to move everybody who has been on the rawhide branch
to Branched at Alpha time, in order to get the maximum amount of testing
for the new release.
My proposal:
1) Branch git at Beta Freeze
=========================
Move the git branching point later in time, perhaps a week before
the Beta freeze. This would eliminate needless maintainer overhead
where they, in most cases, have to keep both Branched and rawhide
git branches in sync.
I would, however, still put Bodhi and the all the other QA
processes in place during the Alpha - Beta time frame.
The way I envision this working is like this:
F17 Alpha Freeze
----------------
a) Up to F17 Alpha freeze, koji inheritance looks like this:
dist-rawhide (17)
└─f17
b) At F17 Alpha freeze, releng updates inheritance and locks
dist-rawhide, making dist-rawhide (18) essentially a copy of
f17-updates-testing:
dist-rawhide (18)
└─f17-updates-testing
└─f17-updates
└─f17
c) At F17 Alpha freeze, git isn't branched. Fedpkg will build to
f17-updates-candidate. No builds can go directly to
dist-rawhide, but they will get inherited to dist-rawhide
from f17-updates-testing.
d) At F17 Alpha freeze, Bodhi will be introduced to the newly
created f17-* tags. Since git isn't branched, the builds from
master branch go to f17-updates-candidate and will be inherited
to rawhide (18), once they make it to f17-updates-testing.
F17 Beta Freeze
---------------
a) git is branched.
b) rawhide is unlocked, but will continue inheriting from
f17-updates-testing.
c) fedpkg will build to dist-rawhide from git master branch, and
to f17-updates-testing from git f17 branch.
d) Bodhi remains in place on the f17-* tags, but since rawhide is
unlocked and git is branched, the two can now start diverging.
2) Keep rawhide users at Branched
==============================
In order to bring as many testers as possible to the new release,
modify fedora-release and fedora-release-rawhide packages at F17
Alpha Freeze, so that every rawhide user who updates during Alpha -
Beta time frame, will be moved to Branched repo.
--
Kalev
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
