Re: couchdb stable
Hi Raphael,
On Tue, May 18, 2010 at 08:14:43AM +0200, Raphael Hertzog wrote:
> On Mon, 17 May 2010, Sam Bisbee wrote:
> > > 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).
>
> What is so difficult to understand that keeping the system of our stable
> users secure is not wasting time?
>
> If you make this remark, it's possibly because you don't believe that
> anyone is using the version in stable.
Yes, sorry, I thought I was clear in noting that I believe stable to be unused.
Again, I don't have numbers, but it's from my interactions, experiences, and
there being no chatter about 0.8.0.
While not related to the "waste of time" bit, I also commented that I don't
even know if it would be possible to back port the CVE changes across 2 years
of code changes. I know that the patch to 0.10.2 to fix the CVE issue was
small, but I haven't checked yet to see if that'll hold true all the way to
0.8.0. An exercise for tonight/tomorrow.
> In that case, maybe you (or the former maintainer) should not have let this
> version reach lenny and keep it in unstable only until the software was
> sufficiently usable and worth to be supported.
Well, 0.8.0-2 (in stable now) migrated to testing back in 2008-07-22, which at
the time was very current. But that's what I've been underlining in my e-mails:
stable is about two years old. That's also why I was so happy to help take over
the maintenance of CouchDB: a good job had been done, but it needed TLC.
Luckily we're just about out of the TLC woods.
> Note that you also have the possibility to provide a backport of a more
> recent version in backports.debian.org.
Sure, and users can peg versions on their systems like I do with my servers.
While I'm open to those solutions, I was investigating the possibility of
releasing other code to stable. Please note that this part of the thread all
started because I used the words "freshen up" where I was looking for
additional info as to the next steps after releasing 0.8.0-2+lenny1 to stable.
That spawned my "why don't we just release to stable once with a newer version,
thereby pushing both init and security fixes, as 0.8.0-2+lenny1 might not be
that useful?" point.
If we're not open to that kind of release management, then that's fine too (I'm
not looking to rewrite policy or start battles). I'm just exploring options to
get the users a better product.
> > > 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.
>
> It's not only a matter of affecting other packages, it's a matter of
> impacting users of couchdb!
Okay, to which I've said many times that I don't believe people are using
0.8.0. Again, while I don't have usage statistics or anything, I have what I've
seen, heard, and experienced. I could try reaching out to the community more
directly by polling various outlets (#couchdb, -users@, twitter, etc.) if
that'd be helpful.
> People running stable routinely upgrades packages non-interactively and don't
> expect to have anything to do to keep all their stuff working. Such a major
> upgrade is unlikely to keep their couchdb database and the code interacting
> with it working without any intervention.
I 100% agree with you on all of those points. However, I don't feel that they
apply to this situation very well with 0.8.0 being so out of date, no semblance
of a community around it that I have seen (documentation, discussion in
#couchdb or -users@, tickets in either bts or their JIRA, etc.), documented
security flaws (CVE applies), etc. Again, I'm not saying that we HAVE to
release >0.8.0 to stable, just that I'm interested in doing so and I believe it
would be of a greater benefit to our users than continuing to keep 0.8.0 in
stable.
Maybe one way to ease that transition is to show a prompt on upgrade that says,
"you know you're jumping versions, right?" with impacts and the ability to
cancel.
No data would be lost during an upgrade, as CouchDB partitions its data
directories based on version number. These are issues that our users have to
deal with whenever they upgrade anyways (some notes in #578868).
> > 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
>
> That's not okay. The promise we make when we release a stable version of
> any of our packages is not the same than any promise upstream can make.
Sorry, I'm confused as to the point you're making here. Could you please
rephrase?
> > 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?
>
> Why was it packaged in unstable and not in experimental at that time then?
> Or why was no RC bug opened to avoid it going into stable?
You're asking questions about things before my time. However, I think you might
be misunderstanding the point I was making there: it's not that 0.8.0 was out
of date back in 2008 (it was released by upstream then) and shouldn't have gone
to stable, but it is out of date now.
Cheers,
--
Sam Bisbee
Reply to: