Mailinglist Archive: opensuse-gnome (216 mails)

< Previous Next >
Re: [opensuse-gnome] GNOME:STABLE and GNOME:UNSTABLE
  • From: Michael Wolf <maw@xxxxxxxxxx>
  • Date: Thu, 04 Oct 2007 14:05:17 -0500
  • Message-id: <1191524717.21889.34.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-gnome+help@xxxxxxxxxxxx

< Previous Next >