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 Wed, Mar 14, 2007 at 12:33:57PM +0100, Enrico Weigelt wrote:
> > I suppose you did it wrong then.
> 
> Subjective. 

Well, upstream had the same oppinion, so there are at least two subjects
in this universe who think you did it wrong :)

> Ah. At my site, those things are done in Briegel's (my buildsystem)
> port config, which is out of OSS-QM's scope. IMHO, it's important to
> keep things separated.

Build systems have their own reasons to structure things. That's why I
said create a "push buildsystem-patches into your project" path.

> > See Documentation/SubmittingPatches in your favourite Linux kernel.
> 
> hmm, looks quite nice, but since our patchfiles are not mails, we 
> should slightly differ, ie. Submitted-By" is IMHO better than "From".
> I also suggest writing all comments in the header form.

It's all about standards. Our patch files _are_ mails, if you 'quilt
mail' a complete series to upstream. And you can talk about names, but
the document is mandatory for 10k of Linux developers, so you'll
probably have a hard life to argument against it.

> > 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
> 
> The dir structure doesn't seem to be normalized.

I don't know what you mean with "normalized" and I don't want to, but it
is the way patches are handled in one of the biggest OSS communities out
there. If foobar-1.2.3 extracts into foobar-1.2.3, it is so and not
different.

> > cat foobar-1.2.3/patches/series
> > gargelpu.diff
> > blub.diff
> 
> Okay, quite equivanet to my patch list format (but 'm leaving off ".diff").

You can tell it whatever you like, as long as the entry in series is
consistent to the patch name.

> > > 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?
> 
> Autoconf has to be re-run, so all it's autogenerated stuff will be
> regenerated.

Which is a showstopper. Users are never intended to have the autotools
available, and nobody will repackage > 400 packets because of your idea.

> > > 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?
> 
> * CVSROOT=:pserver:anonymous@patch.metux.de:/home/cvs/repositories/oss-qm
> * cvspass=anonymous
> * module=oss-qm-patches

Revision control system is a good idea, but could you please use svn
instead of CVS? We don't want to go back to the mesozoikum :-)

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]