Why are 4.8.80 packages already out in the wild?

[Friedrich W. H. Kossebau]

Am Montag, 4. Juni 2012, 18:01:29 schrieb Martin Gräßlin:
> On Monday 04 June 2012 15:18:11 Kevin Kofler wrote:
> > On Monday 04 June 2012, Sebastian Kügler wrote:
> > > That means that people report bugs against different incarnations of the
> > > same packages, which makes bugs hard to find -- it doesn't work as we
> > > can't verify the exact state of the code a bug is filed against.
> > 
> > That almost never makes a difference in practice, and when it does, the
> > developers are (or should be) aware of the respin and ask to make sure.
> > (If
> > the reporter is the packager, he/she'll definitely know whether the
> > package
> > already uses a respun tarball, if not, he/she can provide the exact
> > version
> > of the distro package and the distro packager can tell you what tarball
> > was
> > used. And in any case, we always issue a new build with the respun tarball
> > as soon as possible.)
> 
> I must admit that I find your answer strange. Given that the whole thread
> had been started by a developer because he sees a problem in exactly that
> thing, it's quite strange that I get told that there is no problem at all.
> 
> Please note that working as a developer is quite different to working as a
> distro packager. Yes your distro packages have very precise versions, yes
> our versions, too - once they are released. And that's the difference to
> the distro packages, before the release it is not known what the version
> is. (Btw. shipping patches upstream does not know about is as bad - even in
> development versions nobody should use).
> 
> Now what appears to be no problem is a problem. It is causing work for
> developers when the version information is wrong. It is causing work if we
> have to ask again for the version information. Furthermore it is not said
> that a developer knows about a respin tarball. Please note that unlike you,
> I as a developer have no access to the tarball before release and the
> developers don't get a mail in their inbox telling them that the tarball
> has been recreated. Developers have to actively monitor the release team
> mailinglist and I'm quite sure that not everybody is subsribed to this
> list.
> 
> The whole thing becomes even more complex if we consider the perfect case of
> bug triaging. How should a triager know that the developers fixed a bug
> which caused a respin of the package?
> 
> I hope you understand that what you describe as a non-issue, is issue enough
> that I started the thread. So yeah either I have no clue about what I do,
> or maybe, maybe it is an issue in fact.

For me the issue as you described it seems to be that it is not so easy to map 
the version of the binary/package back to the version of the sources, ideally 
even a git/svn commit id (and the ids of any patches downstream has applied).

This issue is even a bigger problem if your fellow developers compile your 
code from scratch and then file a bug by version "Compiled from sources". 
Should happen much more often, no? :)

Could this issue not be solved by somehow getting the real source code version 
id(s) into the binary/package info?

Cheers
Friedrich