DTC 1.0.0 Release Coming?

[Josh Boyer]

On Fri, 27 Jul 2007 11:33:31 +1000
David Gibson <david at 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.

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

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

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