3:02 a.m.
Le Ven 9 novembre 2007 00:25, Karel Zak a écrit :
* __unfortunately__, we don't maintain source code in our VCS!
It's not unfortunate at all, the stuff in our VCS has not the same
target as the stuff in upstream VCS and there needs to be a big red
line between them.
Releases happen upstream. Development happens upstream. Fedora rpm
patches are an overlay of upstream work, need to be as limited and
static as possible. Anything else is fork-receipe and short path to
maintenance hell.
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.
--
Nicolas Mailhot
3:52 a.m.
New subject: When will be CVS replaced by modern version control system?
On Fri, Nov 09, 2007 at 10:02:04AM +0100, Nicolas Mailhot wrote:
Le Ven 9 novembre 2007 00:25, Karel Zak a écrit :
> * __unfortunately__, we don't maintain source code in our VCS!
It's not unfortunate at all, the stuff in our VCS has not the same
target as the stuff in upstream VCS and there needs to be a big red
line between them.
You can set the big red line in modern content trackers -- tags,
branches and rebase are your friends. This is not problem.
Releases happen upstream. Development happens upstream. Fedora rpm
patches are an overlay of upstream work, need to be as limited and
static as possible. Anything else is fork-receipe and short path to
maintenance hell.
We still maintain non-trivial number of non-upstream patches.
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.
Karel
--
Karel Zak <kzak(a)redhat.com>
5:22 a.m.
New subject: When will be CVS replaced by modern version control system?
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
11:20 a.m.
New subject: When will be CVS replaced by modern version control system?
On 11/09/07 06:22, Lennert Buytenhek wrote:
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.)
I think we (as OLPC) could really benefit from a truly
distributed development infrastructure.
The CVS to git migration is only part of the problem. We'd need
a local Koji installation that could "inherit" braches from
koji.fedoraproject.org. And maybe also local installations of
pkgdb and Bohdi...
It would be really cool if the whole toolset for a full
"distro assembly line" was easy enough to setup locally.
For my daily development, I often felt the need for a personal
fork of OLPC-2 where I can experiment with my custom packages.
An example of a project that required it was upgrading to
Xorg 1.4, which involves a dozen of updated packages and
some config updates.
We already have a modified version of pilgrim, plus some
build machinery that generates hourly builds from several
streams:
http://xs-dev.laptop.org/~cscott/olpc/streams/
We're currently limited to dropping customized binary RPMs
in a directory. What's missing is the same level of support
in the preceding stages of the build system.
My impression is that setting up a local koji server on
workstation machines is way too complicated. What an
individual developer would need is the same ability to
build packates, but without the added complexity xmlrpc,
multiuser, clustering and web interface.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
11:45 a.m.
New subject: When will be CVS replaced by modern version control system?
On Mon, 19 Nov 2007 12:20:34 -0500
Bernardo Innocenti <bernie(a)codewiz.org> wrote:
We already have a modified version of pilgrim, plus some
build machinery that generates hourly builds from several
streams:
http://xs-dev.laptop.org/~cscott/olpc/streams/
We're currently limited to dropping customized binary RPMs
in a directory. What's missing is the same level of support
in the preceding stages of the build system.
My impression is that setting up a local koji server on
workstation machines is way too complicated. What an
individual developer would need is the same ability to
build packates, but without the added complexity xmlrpc,
multiuser, clustering and web interface.
Could this not be accomplished with my koper idea?
http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
--
Jesse Keating
Fedora -- All my bits are free, are yours?
11:12 p.m.
New subject: When will be CVS replaced by modern version control system?
Jesse Keating wrote:
On Mon, 19 Nov 2007 12:20:34 -0500
Bernardo Innocenti <bernie(a)codewiz.org> wrote:
> My impression is that setting up a local koji server on
> workstation machines is way too complicated. What an
> individual developer would need is the same ability to
> build packates, but without the added complexity xmlrpc,
> multiuser, clustering and web interface.
Could this not be accomplished with my koper idea?
http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
Indeed, I like it very much! It's maybe not as versatile
as what I had in mind, but it has a higher features/complexity
ratio. Is anyone working on implementing it?
To make this development model feasable, I think we should also
speedup uploading srpms to koji, which is needed for scratch
builds. Uploading the kernel srpm takes around 20-30 minutes.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
6:57 a.m.
New subject: When will be CVS replaced by modern version control system?
On Tue, 20 Nov 2007 00:12:29 -0500
Bernardo Innocenti <bernie(a)codewiz.org> wrote:
Indeed, I like it very much! It's maybe not as versatile
as what I had in mind, but it has a higher features/complexity
ratio. Is anyone working on implementing it?
Not actively. It's something I'd like to see done, but I haven't the
time immediately to work on it. I have to get the signing server done
first :/
To make this development model feasable, I think we should also
speedup uploading srpms to koji, which is needed for scratch
builds. Uploading the kernel srpm takes around 20-30 minutes.
That's unfortunately a function of bandwidth. However we could at some
point have a shell server near the buildsystem that could be used to
generate the kernel src.rpm and upload it over local bandwidth.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
8:05 a.m.
New subject: When will be CVS replaced by modern version control system?
On Fri, 2007-11-09 at 10:52 +0100, Karel Zak wrote:
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.
FWIW, I think that seeing some people work on some various
implementations of this could be a really useful way forward on the
whole SCM discussion. It gives us a good way to test out new workflows
and see how they really _do_ work without forcing everyone to change at
once. And then when we get to something markedly better, we can revisit
the idea of changing out the canonical method.
Jeremy
6024
days inactive
6035
days old
7 comments
6 participants
participants (6)
-
Bernie Innocenti -
Jeremy Katz -
Jesse Keating -
Karel Zak -
Lennert Buytenhek -
Nicolas Mailhot