On Fri, May 29, 2009 at 03:12:08PM +0200, Erik van Pienbroek wrote:
Hi all,
As F-11 is approaching we're getting to deal with multiple branches
(F-10, F-11 and devel). I've noticed that several packages have
different versions across branches. For most packages this isn't a
problem, but for some core-packages this causes issues.
One of such packages is mingw32-filesystem. This package contains
several RPM macros which are used to build packages. I've noticed that
some fixes have been backported from the F-11 to the F-10 branch while
others haven't. This can cause confusion among packagers as they have to
keep track of the changes in each individual branch to get the
'BuildRequires: mingw32-filesystem > XX' right.
A solution to this situation would be to keep the mingw32-filesystem
package in sync on all branches, but I think it's best if we create a
more general 'Package update policy' so that it's clear for all
packagers what package versions can be expected among the different
branches.
For this policy I'm thinking about dividing all the mingw32 packages in
separate groups:
1. Core packages with no native version in Fedora
2. Packages with a native version in Fedora
3. Packages with no native version in Fedora
Packages belonging to the first group are:
- mingw32-filesystem
- mingw32-runtime
- mingw32-w32api
What I would like to propose is:
- Packages in group 1 are always in sync among the different branches
(there may be a small delay to test changes, but eventually the
changes should to applied to all branches)
The problem with changing this, is that if you then need to rebuild
another library package, there's a non-trivial chance you've broken
the RPM rebuild-from-source with the rebase changes. There have been
packages broken by updates to runtime & w32apis in the past, so I
think these should all be bug-fix only.
- Packages in group 2 are always in sync with the native version
of each branch
Agree. These packages should always be version + patch identical
to the native version,.
- The update policy of packages in group 3 is fully up to the
maintainer
IMHO, stable trees should never receive version rebases, particularly
important if other packages depend on them, so again bug fix only.
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|