Re: OSS-QM global patch repository

[Enrico Weigelt <weigelt at metux dot de>]

* Robert Schwebel <r.schwebel@pengutronix.de> wrote:

Hi,

> > That's why I want to bring things together. Virtually each distro
> > has it's own patches. Many, many sysops also do.
> 
> True, and that will probably stay that way, because folks get their
> problems out of sight.

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). 

> > What we need is an central point for all folks and some QM mechs. 
> 
> Good idea, but I doubt it will work.

I will work, if we simply do.

> > Most important policies (for us) would be:
> > 
> > * destdir installation (resspects either $DESTIR or $INSTALLDIR)
> > * alternate toolchain (respects $CC + friends properly)
> > * separate toolchains for host and target
> > * sysroot-capable
> > * deterministic build (no crazy guessing)
> 
> Important points, although I'm not sure what "normal distro" guys will
> think about the last one.

Well, "deterministic builds" is an point many distros and package
developers probably never ever heared about. Same with alternate
and separate toolchains or sysroot. ;-O

> > > IMHO the main question is: who will finance that effort. 
> > 
> > For my site: partially my customers, partially my own idealism :)
> 
> Well, to some extent it is the same here; we need a local patch
> mechanism in PTXdist to get our daily embedded projects done, but for
> the long term I would be more than happy to see the patch load go down
> instead of up.

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
(names probably normalized -- see oss-qm wiki), there some 
patches.db file which lists patches per (normalized) release, and 
the patches are sitting within the src subdir. Maybe there're
some other files laying around, which aren't really relevant.

    rsync://patches.metux.de/metux-patches/

<snip>

> In general: yes. But it's very important for us to have a well defined
> patch stack; I would not feed some community patch stack into our
> commercial projects, because it probably breaks things without us having
> influence on it. So if there will be some collaboration, it must be in a
> way that I can specify "this ptxdist patch qualifies for upstream" and
> make it magically appear in a central patch tree.

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.
And we also have tools that automatically notify the package 
maintainers.

> Nevertheless: Somebody has to care about communication with the 
> upstream projects. I've just cleaned up some of the dotgnu makefiles, 
> and it was something like 4 weeks of work just to do it and discuss 
> it with the upstream maintainers; it is a big piece of politics, 
> it is a lot of work and you probably also need somebody with good 
> community interaction. 

Well, this can be done by arbitary OSS-QM members, you don't have
to be an maintainer for that. Would be an good job for my trainee :)

> For example, somebody who rants libtool would probably be sub optimal =8-)

Heh, this clearly goes into my direction ;-o 
Yeah, I'm not very diplomatic, but I've got my reasons against 
libtool - you probably know them.

But you don't have to fear any libtool rants from my side anylonger.
I've completely dropped it. I've got unitoo ;-P

<snip>

> > An way out: create an generic repository, which works well for 
> > much, much more people than just our two parties. We first have 
> > to spend some time in an good organisation and workflow, then 
> > many things can be done by bots or futher aquired helpers. 
> > (from time to time I've got an trainee who could come in here)
> 
> It needs experienced people to do things right. You cannot do it in
> parallel to daytime work and you cannot let it do a trainee. At least I
> would not automatically let patches from such a stack flow into our
> professional trees...

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 ...


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

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