Re: mercurial new test packages
Hi Antoine,
> > * A build that does not non-determistically fail in its testsuite (and
> > thus FTBFS randomly.).
> >
> > * Reliably detecting regressions ("introduce new…").
> >
> > * A bit-for-bit reproducible build - eg. your "test packages
> > unreproducible" note in data/dla-needed.txt when we both agreed that
> > is not a goal of LTS updates.
> >
> > Can you please clarify exactly which are referring to in data/dla-
> > needed.txt?
>
> Sorry if I wasn't clear. By "unreproducible" I meant the first option
> above, that is the build fails non-deterministically.
Whilst your subsequent argument to use "reproducible" may have some
merit, you will notice that it caused more communication problems than
it solved. So, at least being (overly) specific may be preferable in
future.
> I am not sure I understand. Are you saying that btrfs makes it easier to
> introduce non-deterministic filesystem ordering?
(In my experience, yes. Roughly speaking, the ext family "tends" to
return the same ordering from readdir(3) whilst btrfs might restructure
stuff behind behind the scenes. Naturally, this is not at all
guaranteed, just an anecdote)
> @wireprotocommand('listkeys', 'namespace')
> def listkeys(repo, proto, namespace):
> d = repo.listkeys(encoding.tolocal(namespace)).items()
> return pushkeymod.encodekeys(d)
>
> And in my tests this is returns as a list of tuples,
> deterministically.
I'm skeptical, given that after a 30-second (!!) glance pushkey.py uses
a dict underneath. Only a recent Python 3.x defines insertion-order key
ordering and even that may not even be enough if, obviously, they are
inserted in a non-deterministic order.
> ie. just pipe the output through sort to get consistent results.
Yay!
FYI I really don't have any secret insight into mercurial, I just
"keep" being CC'd on this ;)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org / chris-lamb.co.uk
`-
Reply to: