Re: Proposed new release goal: Dependency/file list predictability
On Fri, Jun 22, 2007 at 09:23:16AM +0200, Lucas Nussbaum wrote:
> However, with this setup, you only check that building packages in
> non-clean environments doesn't significantly affect the package. It
> would be interesting to check as well if the resulting package matches
> what is in the archive, to some point.
I already do that, but mainly as an optimization at this point.
I do agree with your goal, though, but it's very hard to determine what's a
bug and what's not. "This package hasn't transitioned to newer libfoo yet"
is, IMO, not a bug in itself.
BTW, I've built everything in optional up to the letter c (plus all of
required, standard and important), and so far, 28 bugs have showed up. (Also,
44 FTBFS bugs have showed up, but I haven't filtered out those that FTBFS in
clean chroots yet, and I guess those would account for nearly all.)
Extrapolating from that, it would seem that slightly over 200 bugs of this
class exist in the archive. I only started the full build on hydra (thanks,
Joey) yesterday, so I assume I'll have a first approximation of the number of
bugs in a couple of days.
> - some files will differ, because of:
> + date/time information
> + newer compiler versions causing better optimization
> + ...
Yes, diffing binary files properly is very hard.
> So, I'd like to extend this release goal to something like "binary packages
> predictability (to some extend)". This would mostly result in a lot of binNMUs
> to update the binary packages to the current state of unstable, so in most
> cases, it shouldn't put a lot of load on maintainers.
> The number of issues is unknown ; it depends on how close we want packages
> to match.
>
> Do you think it's a good idea?
I'm unsure. I do like the idea, but I'm concerned it would be difficult to
determine what's an acceptable difference and what is not.
> Steinar, do you want to merge your release goal with that one, or do you prefer
> me to file a seperate release goal? The main reason why I think they should be
> merged is that the way to detect issues is similar.
I'd prefer to have it as a separate release goal, or at least a different
usertag (which is really all that matters; release goals are not binary
achieved/not achieved anyway).
/* Steinar */
--
Homepage: http://www.sesse.net/
Reply to: