On Thu, 2007-04-10 at 10:27 +0200, Stanislav Brabec wrote:
I think the right thing to do is to ask the autobuild team to reject submissions for anything that'll go into /work/SRC/all/GNOME unless it comes from GNOME:UNSTABLE or another repository in the build service.
Well, then we need a way, how people could do global changes in GNOME packages (e. g. BuildRequires after package rename / branch, new CFLAGS,...).
These are some of the issues: 1) If foo depends on bar which is renamed to (or branched to, replaced with, etc) baz, then foo will fail to build. Somebody will look at the logs or attempt a local build with osc, see what's changed in Factory or G:U, and fix the package. Same thing when the toolchain changes and gcc is stricter, or whatever. 1a) Autobuild has its own set of checks that it performs on built packages. These checks are stricter than the ones in the Build Service. Some people told me that the checks will someday be in the Build Service; others have told me that they won't. I'm of the opinion that they should be. Either way, until they are (which may be never) somebody who works for Novell will need to watch for packages that fail to build in Autobuild, fix each package so that it builds internally, do a getpac -d to figure out what he did, and apply the result of getpac -c to the package in the G:U. - Tasks that need to be done in the PDB: package renames, splits, etc. For now, somebody who works for Novell will need to do these, although I think a good case can be made for opening the PDB.
We might use technical solutions to solve this problem - e. g. making snapshot of Factory packages in a moment of starting separate development in G:U, but success ratio of an automatic spec and patch merging is not as good as one could expect (I guess ~70%).
I think any plan for this that requires any manual merges, other than merges within a single branch (in the terms of a proper version control system) or project, would be a real mistake.
Standard version control system does not work well for packages - spec files changes are concentrated in preamble and %prep and you get a lot of rejects there.
I don't follow. Fixing rejects and merging things by hand is a fact of life. It's like that now, and it would be like that with version control, although probably easier. Our Esteemed Competition uses revision control to manage their spec files and .deb equivalents [0]. One of our Esteemed Competitors even went so far as to write their own standalone revision control tool. It isn't tightly coupled with their infrastructure or workflows. They've done a pretty good job at it -- I'm a fan. I don't propose writing our own, of course. There's no need. But to say that revision control doesn't work well for packages? I don't buy it. (Needless to say, Federico's comments about the benefits of revision control are spot on.) [0] For example, see http://cvs.fedoraproject.org/viewcvs/devel/nautilus/ and https://code.launchpad.net/~ubuntu-desktop/nautilus/ubuntu. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org