Re: freeze exception: fossil 2010.08.05.100943-1

["Barak A. Pearlmutter" <barak@cs.nuim.ie>]

Okay, so be it.

But I'm going to go ahead and make the case for letting it in though
anyway.  Not just for fossil, but as a general comment which likely
will apply to other packages, and food for thought for the release
team.

I don't see any technical point to holding fossil back.  It is a leaf
package, so even if there is a bad bug allowing it in won't slow the
release.  The upstream author is the author of sqlite as well, which
is decidedly *not* a leaf package, and I can assure you that the level
of scrutiny you're describing was not done on the sqlite major release
that is about to transition into testing, and which was dput a couple
days ago.  As far as I can tell, the logic here is: if this had been
dput a few days ago it would be fine, but not now.  Why?  Because
that's our policy, no other reason.  It's your decision of course, but
I think a bit of softness in the process, call it a cooling to frozen
solid from the core on out, make a lot more sense.  This had been done
in releases past, and did not seem to cause any delay.

I could look in the fossil upstream tracker for some nasty bug fixed
in this release, and push it into the BTS with an appropriate tag.  Is
that really how we want to operate though?  Should I have dput a
non-working placeholder last week just in case?  This kind of thing is
not how I want to operate; I'm not into gaming the Debian release
process.  But one design goal for the release process itself should be
that it doesn't make people *want* to game it.

My hope is that you'll take these in the spirit intended: as thoughts
about how the release process and policy play out on the ground, and
this developer's thoughts on how they might be improved.

					Cheers,

					--Barak.

PS  To see what code was actually changed, with upstream VCS log
    entries, see
     http://fossil-scm.org/index.html/timeline?n=200&y=ci
    between [fb5f0c2580] and [d090292800], or to see changes on the
    debian branch as well, see
     http://cvs.bcl.hamilton.ie:8080/timeline?n=200&y=ci
    between [256386f581] and [12a83050a6].