Re: DTC 1.0.0 Release Coming?

[David Gibson <dwg@au1.ibm.com>]

On Mon, Aug 06, 2007 at 08:48:13AM -0500, Josh Boyer wrote:
> On Fri, 27 Jul 2007 11:33:31 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote:
> > > So, like, the other day David Gibson mumbled:
> > > 
> > > > > > Only thing I'm not really happy with in the current release is the
> > > > > > versioning stuff.  For starters, it always reports my builds as
> > > > > > -dirty, even when they're not.
> > > > > 
> > > > > I think it won't do that once there is a tag available.
> > > > 
> > > > Your 1.0.0-rc1 tag is there, still showing as dirty.
> 
> git vs quilt issue, as you have already discovered.  I've always seen
> that with kernel builds.

Yeah, ick.

> > > > > I would like to keep the current version mechanism as it
> > > > > is really quite similar to what is in the Kernel now.
> > > > 
> > > > First, I don't think it really is - except in superficial aspect of
> > > > how the version number is partitioned
> > > 
> > > I lifted the code from the Kernel's Makefile directly, and tweaked
> > > it slightly for lack of Kconfig aspects.
> > 
> > Ah, yes, ok, I see.  Frankly I really don't think a lot of that stuff
> > makes much sense outside the context of Kbuild.  The whole complex
> > filechk macro, for example - for which there's only one used parameter
> > in dtc's case.
> 
> Except didn't you say you were going to work with Stephen to get DTC
> into the kernel source itself?  Keeping things similar to Kbuild might
> help in that effort.

Actually, after discussions with Stephen and Paulus, we decided not to
take this route.  In any case having Kbuild like versioning wouldn't
actually help us any in integrating into a full Kbuild system.

> > > I don't want to tie the code and build mechanism to git too much.
> > > Specifically, we need to be able to support stand-alone tarball
> > > based builds.  For example, I've spoken to the Debian package
> > > maintainer on this issue, and he likes this approach as well as
> > > he says it will make packaging it much easier.
> > 
> > Have a look at the patch I posted.  I haven't sufficiently tested it
> > yet, but it should be able to generated version info for a tarball too
> > (provided the .git-manifest file is included, and I'm intending that
> > will be build by a make dist target).  It will give both the
> > git-derived based version, and a file content derived hash so we can
> > robustly tell different builds apart, all with less code than the
> > current system.
> 
> That may be.  But I don't see the current approach being too much of a
> problem either.  Especially given that it's already there and it
> works.  Oh, and you sent out your patch saying it wasn't ready for
> merge and with no sign off.  Small but important issues to fix I'd
> think.

Yeah, it lacks a make dist target, and needs a bit more work to
support that properly.  Never mind, I'll revisit this post the 1.0
release.

> This seems to be the last issue holding up a dtc 1.0 release.  Perhaps
> we could go with what exists and see if there really are problems.  It
> can always be fixed later.
> 
> josh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson