This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: OSS-QM global patch repository


On Sat, Mar 10, 2007 at 03:22:22PM +0100, Enrico Weigelt wrote:
> I don't think they would get their problems out of sight. Instead
> they would all save much work and provide big help to the package
> developers. The problem is that fixes have to real fixes, not ugly
> hacks to get in. For example, always fixing the real sources, not
> playing around in autogenerated files (ie. ./configure). 

Yes, sure, we do it the same way. But once you have it in your patch
stack, the packet works. Everything else is extra effort, without
anybody really being interested in it.

> So, we're doing quite the same, we want quite the same, now let's
> get our repositories compatible. 
> 
> Mine has an quite simple structure: one directory per package

dito here (although we have a directory "generic" inside, which is
historic and could be removed some day).

> (names probably normalized -- see oss-qm wiki)

You cannot enforce naming policies; we use the normal packet name for
that, which is usually what you get if you extract a packet. 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

As I said before: I see no point in talking all similar projects out
there into using the same format. If you want to push something, make
yet another patch repository, plus automated scripts which make it easy
for the maintainers of the projects to automatically convert and push
their patches in.

Regarding the patch format, we have our own header ontop of it, to
specify things like the upstream status, source or the error etc. In the
future it will most probably be the canonical patch format used for
Linux.

T2 has an interesting packet description & patch format as well...

> there some patches.db file which lists patches per (normalized)
> release, and the patches are sitting within the src subdir. 

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.

> Of course, evryone may have it's own tree(s). But all trees have the
> same structure, we can operate with the same tools in them and these
> tools provide easy techniques for finding changes/updates, etc.

Seconded.

> And we also have tools that automatically notify the package 
> maintainers.

Forget it. Patch feeding is communication, and it needs _active_ work
with upstream. 

> > For example, somebody who rants libtool would probably be sub optimal =8-)
> 
> Heh, this clearly goes into my direction ;-o 

Dum titum ....

> Yeah, I'm not very diplomatic, but I've got my reasons against libtool
> - you probably know them.

We agree that libtool has problems. But it is the same with libtool as
with for example cmake: People come and want to do everything better
what has been done by skilled developers for years. They make something
new, and in the end it does the deficiencies 100% perfectly, but on the
way 50% of the old functionality is lost. Cmake for example still cannot
cross compile as far as I know, and it breaks the known-for-decades way
of building packets with ./configure && make && make install, together
with well established methods like --with-foobar=blub and --enable-baz.

So IMHO the only solution is: fix libtool.

> Grmpf, I'm talking about the organisation structure, management tools,
> etc, not the actual patches. My trainee can of course build some scripts
> for comparing trees, notifying about changes, cat'ing patches together ...

Yes, sure.

So for the moment I'd say that we are generally interested in such a
project, taken that it is structured in a way that we may discuss a
generic patch + documentation format and build automatisms to push
patches from the build systems into a QM project. Let's do some more
thinking about how to structure it correctly...

Rene, what is your oppinion? Would you also be interested? It might also
be a good idea to ask buildroot, open-embedded etc.

And, of course, it would have to happen under a neutral organisation. I
wouldn't also mind to let this thing be quality.pengutronix.de to get
the marketing effect ;) but if we want to be it a success, it must be
strictly vendor neutral. LTP could be a candidate, or the Linux
Foundation. Has anybody contacts?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]