Re: couchdb stable
On Mon, May 17, 2010 at 09:26:32PM +0100, Adam D. Barratt wrote:
> On Sun, 2010-05-16 at 16:28 -0400, Sam Bisbee wrote:
> > On Sat, May 15, 2010 at 05:21:49PM +0100, Adam D. Barratt wrote:
> > > On Fri, 2010-05-14 at 17:47 -0400, Sam Bisbee wrote:
> [...]
> > > > Here's the revision with the 0.8.0-2+lenny1 back port:
> > > > http://svn.debian.org/viewsvn/pkg-erlang?view=rev&revision=1231
> [...]
> > > The new awk dependency should not be included, however. There are two
> > > reasons - firstly, awk is pseudo-essential, as base-files pre-depends on
> > > it; secondly, and were the first reason not applicable, adding a
> > > dependency on awk to a stable update purely for "| awk '{print $2}'"
> > > would be inappropriate ("cut" from coreutils would suffice, for
> > > example).
> >
> > Risking circular logic/discussion...
> >
> > - If mawk is pseudo-essential, then should we even really need to outline it
> > as a dependency? My gut says "yes" because of the pseudo part.
>
> base-files is Essential, and its pre-dependency on awk is not going to
> change in stable. You can assume that awk is in all but name Essential
> in stable, so the dependency should be removed.
>
> (For completeness, the pre-dependency is partly to ensure that the awk
> virtual package is Essential without enforcing the use of a particular
> implementation)
Gotcha, I'll remove it from both 0.8.0-2+lenny1 and our next release(s), and
test tonight. Will this make 0.8.0-2+lenny1 sufficiently clean for release to
stable?
> > > > I would like to get this done soon so that we can release 0.11.0-1 to stable,
> > > > as it contains a security fix for CVE-2010-00009, and stable needs to be
> > > > freshened up badly.
> > >
> > > stable doesn't get "freshened up" in terms of new upstream releases
> > > (with a couple of notable exceptions which prove the rule).
> >
> > Sorry, I didn't mean to suggest that we release directly to stable again - it
> > was more a commentary on how old 0.8.0 is (2 years?), and therefore stable is
> > missing a lot of stability and security fixes, without considering
> > functionality.
>
> If there are stability or security fixes that apply to the version in
> stable then backporting those that are "important enough" to stable is
> worth investigating. Functionality updates are unlikely to be
> appropriate for a stable update.
>
> > > A fix for CVE-2010-0009 in stable may well be appropriate,
So, it sounds like the CVE fix would qualify for this, but I have no idea how
the code is going to back port across 2 years of changes. And, like I said, I'm
not sure I see the point; I don't mind doing the work, but I do mind wasting
time (more below).
> [...]
> > > but updating
> > > to 0.11.0-1 is not. After ignoring changes to autotools / libtool and
> > > updates to the presumably-bundled Javascript libraries, the diffstat
> > > between the two versions is
> > >
> > > 307 files changed, 40896 insertions(+), 8269 deletions(-)
> >
> > I just did a few quick diffs (also ignoring dependencies' diffs)...
> >
> > diffstat between branches/0.8.0-2+lenny1 and tags/0.9.0-1
> > 41 files changed, 405 insertions(+), 311 deletions(-)
> [...]
> > Or should we skip releasing 0.8.0-2+lenny1 to stable and go straight to 0.10.2,
> > negating the need for multiple releases, getting everything we want out there
> > (init and CVE fixes), and making some users happy?
>
> Unfortunately, it's not just a case of the size of the diff. One of the
> reasons we generally don't include new upstream releases in stable is
> that they often introduce functionality changes which may have unforseen
> effects, particularly when paired with other software in stable.
Well, it doesn't appear that we'll impact any other packages as nothing depends
on us in lenny.
To be fair though, python-couchdb does suggest CouchDB and its version in
stable does not support CouchDB >=0.9.0 (python-couchdb 0.4 introduced
compatibility with 0.8.0, 0.6 with 0.9.x., and 0.6.1 with 0.10.x) - based on
https://code.google.com/p/couchdb-python/source/browse/ChangeLog.txt as I have
no experience with python, let alone python-couchdb. python-couchdb has 0.6-1
in testing.
So, I don't see us "messing around" with anyone else's work. We could always
offer an opportunity for other maintainers to raise concern over package
interactions? I don't know what's commonly done in this case.
> In this case, upstream helpfully provide a list of changes between
> versions which are backwardly incompatible. The existence of those
> changes would likely be enough to rule out introducing a new version in
> to stable - in the specific instance of the move from 0.8.x to 0.9.x,
> those changes include a modification of the database file format, which
> requires user intervention to upgrade and is not a suitable change for a
> stable update.
There's a ticket about the database migration between versions: #578868. I'm
thinking about some clean ways of doing it automatically, taking upgrade time
and system resources into consideration (based on database size, whether
compaction was run prior, etc.). We'll see what shakes out, but I'll probably
introduce a notice during upgrade to bridge the gap.
As for the other breaking changes, my initial reaction is that it's okay. It's
not even that <0.11.0 flew the beta flag or that CouchDB as a whole is under
one-dot-oh, but folks shouldn't be surprised that they need to check the
changelog of their dependencies when their version numbers change - a warning
can be added during upgrade if needed, though that could result in a damaged
image a la, "Oh no, this software is unstable!" I feel like users who upgrade
dependencies without considering how they've changed and how those changes
impact their environment/application deserve what's coming to them. Especially
when we don't have non-programmer packages depending on us - my expectations
would be different if I were supporting users who aren't technically able.
I'm not asking for constant pushes to stable or anything, but I'm considering
stability, security fixes, and the usefulness of stable - if people don't use
stable because of "no" features and it not being, well, stable, then why do we
have it? And I say that with no numbers, just impressions from talking to the
community, my experiences, and there being little-to-no documentation available
for 0.8.0 (or support/documentation requests for that matter).
Cheers,
--
Sam Bisbee
Reply to: