On Fri, Nov 09, 2007 at 10:52:30AM +0100, Karel Zak wrote:
> > And sure it is not very convenient for developpers, because
> > developpers typically do not want to think about this stuff and would
> > be happy to have their IDE directly plugged into production or user
> > systems. But that's basic maintenance discipline that makes everyone
> > else's life easier.
>
> I think the best way (for Fedora project) is Tom Mraz's suggestion:
> use stupid central CVS as a storage for patch files and locally use
> scripts that convert these patches as code to/from real DVCS.
I've been doing something like that, but only for the packaging
(i.e. no exploded trees.) I have a local CVS->git conversion of the
Fedora CVS tree which I use for things like:
1. Being able to quickly see the history of a package and changes
between packaging in different versions of that package without
having to go through the CVS server (which is on another
continent than the one I am on -- I guess the latency from the US
is probably not too bad.)
2. Visualising branches with gitk, to make it easier to see where
F-7/F-8 branches have forked off from devel, etc.
3. Maintaining trivial patches for the ARM port such as the one in
BZ#245441 (when a new upstream release comes out, just run 'git
pull' and be done.)
4. Maintaining not-so-trivial patches, such as patches to make
packages build cross, or patches to make packages build with
uClibc instead of glibc.
There are a number of observations to be made about keeping local
changes to packages:
- For patches in category (3), you could argue that these should
just be merged upstream, and that would remove the need to make
maintainance of separate patches easier.
The truth is that they aren't always merged quickly, and giving
arch teams unrestricted CVS access only solves part of the problem
(e.g. what if you want to commit a patch that solves an issue but
you're not sure whether the maintainer will like it, but he
isn't responding -- you'll still have to maintain the patches
separately somehow for some time.)
- Also, the patches in category (4) are unlikely to be merged into
Fedora any time soon, and the "We can stick with CVS because we
don't have to make life easier for forks because those people
should just be working on upstream Fedora instead" argument doesn't
really apply, because we have enough local changes that you wouldn't
even _want_ to have in Fedora. ;-)
- Besides, the existence of OLPC-2 branches for various packages
suggests that we _do_ want to accommodate forks to a limited
extent.
Note that in a distributed VCS, the OLPC-2 specific stuff wouldn't
have to live on the main Fedora VCS server, and could very easily
live on a separate box. (Whether this is desirable for the OLPC-2
stuff or not is a separate issue, I'm just saying that it is easily
possible in a DVCS.) (And whether the result can still be called
Fedora or not is also a separate issue.)
- [ Also, putting our cross/uClibc patches in a VCS that understands
branches makes it easier for us to keep those sets of patches on
different branches, i.e. keep them separate, and only merge them
the moment you want to build a package. ]
If you have a need to maintain local changes to packages, IMHO
you're _much_ better off if you keep them in a VCS that is connected
to the upstream Fedora VCS in some sense.
I _could_ just have checked out Fedora CVS, committed that into my
own CVS tree, and started hacking on that, but then I would just be
making life a lot harder for myself, as that would make pulling in
new upstream changes hell, and would probably lead to a permanent
fork.
As an example, Fedora's rpm packaging looks somewhat like this in
gitweb:
http://git.wantstofly.org/?p=fedora/rpm.git;a=summary
The tags in the upper half correspond with tags in CVS. The heads
on the bottom correspond with each of the branches in CVS -- note
how that in the git conversion, different branches live in one
repository, and are merely different versions of the same thing,
instead of living in separate subdirectories in the same module.
To see the individual commits, click on 'shortlog' next to the
branch name (under 'heads'.)
In gitk, it ends up looking something like this:
http://www.wantstofly.org/~buytenh/fedora-git-rpm.png
Note that it is really easy to see:
- where F-7/F-8 forked off from devel
- whether there have been patches applied to F-7 or F-8 that
haven't been committed to devel yet or vice versa
- etc.
Two more examples (gcc and glibc) are here:
http://git.wantstofly.org/?p=fedora/gcc.git;a=summary
http://git.wantstofly.org/?p=fedora/glibc.git;a=summary
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
