OSS-QM global patch repository

Robert Schwebel r.schwebel@pengutronix.de
Wed Mar 14 12:04:00 GMT 2007


On Mon, Mar 12, 2007 at 03:44:09PM +0100, Enrico Weigelt wrote:
> > But once you have it in your patch stack, the packet works.
> > Everything else is extra effort, without anybody really being
> > interested in it.
> 
> In short terms: yes.
> 
> In long terms, maybe not (hope so ;o): often we have to fix every new
> release, if our patches don't go into upstream. That suxx and eats up
> resources. 

It eats up _your_ ressources, but customers tend to forget a packet once
it works for them.

> The big trick is to find an optimum between investing not more than
> necessary, but enough for cooperating with those projects being worth
> to. I already had to learn the lessons, that some projects simply
> aren't intrested in my works, ie. mplayer or gtk, so I simply don't
> care about them at all.

I suppose you did it wrong then.

> > There are activities on the way to restructure our packets to 
> > have something like
> > 
> > memedit-1.2.3/
> > memedit-1.2.3/patches/
> > memedit-1.2.3/patches/memedit-1.2.3-fix-something.diff
> > memedit-1.2.3/memedit.make
> > memedit-1.2.3/memedit.in
> 
> What do your *.make and *.in files do ?
> For configuring / building the package ?

Yep. .make files contain the building rules, .in files are Kconfig files
for PTXdist's 'make menuconfig' system.

> > In the future it will most probably be the canonical patch format 
> > used for Linux.
> 
> How does this look like ? 

See Documentation/SubmittingPatches in your favourite Linux kernel.

> > The community tool for getting patches in order is quilt; so we use
> > quilt like series files in our patch repositories. It also makes
> > patch development easy: just link the patch dir into a breaking
> > project and use quilt to maintain the patch.
> 
> hmm, I didn't have the time to read the docs yet. 

Maybe a reason why people don't care about your patches. Because _you_
don't have time to read docs, you expect _me_ to tell you how it works?
Strange attitude.

> Perhaps you could give quick examples. At the end I need exactly one
> patch per release, which has some normalized location. (my buildsystem
> does not care about patches, it just applies one single patch)

foobar-1.2.3/patches
foobar-1.2.3/patches/series
foobar-1.2.3/patches/blub.diff
foobar-1.2.3/patches/gargelpu.diff

cat foobar-1.2.3/patches/series
gargelpu.diff
blub.diff

Change into foobar-1.2.3 and run 'quilt push -a' to apply all patches,
in the order specified in series. I leave the exercise of finding out
how quilt is used while working on a packet to you.

> Well, at least the initial mail, opening bug, etc can be done
> automatically. I've written a small tool, which can be used to open
> bugs (currently on bugzilla, but other issuetrackers can be added
> easily) via commandline.

Then I'm not wondering why your patches are dropped.

> Well, for my unitool (and it's libtool-alike-frontend), it works quite
> good for me - at least much better than libtool. Thanks to the frontend
> (an some minor patch in autoconf, which just puts a call to lt-unitool 
> into libtool.sh), it works as an drop-in-replacement.

What do you mean - patch in autoconf. I have > 400 packages, built by
their respective maintainers. Do they all have to be repackaged?

> So what do you think about my new patch dir structure (I recently
> posted) combined with your headers ? 

Could you put a prototype somewhere, for review?

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9


--
For unsubscribe information see http://sourceware.org/lists.html#faq



More information about the crossgcc mailing list