couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [DISCUSS] Goals for 2013
Date Thu, 07 Mar 2013 15:54:28 GMT
Agreed. Thanks for the honest feedback. Massively appreciated.

I have been very frustrated with the 1.3.0 release. It was, and still is,
supposed to be the first of our regular releases. Unfortunately, the
release was mired with a raft of CVEs that came first, and then some thorny
blockers. Not making excuses. I felt the pain of this as much as anybody
here who cares about making this work.

I've spent the last few weeks putting work in, and actually coming up with
an entirely new release procedure (which I will be announcing in tandem
with the release, in a day or two) that should address these problems. Most
significantly, I am moving the test suite to the voting stage, which will
allow me to cut and call votes very quickly.

So, from my perspective, we are just about to emerge from release hell, and
I have my eye firmly on the next three quarters. As I mention in my
original email, basically, most of this hinges on activity. And activity
hinges on releases, as you say. But I've already put a lot of thought into
that, and I wanted to invite the community to start thinking about the
other things we can start to address. I think these things are important

Here's an example, look at the burn-down chart for tickets:


How do we solve it? Sure, release will stimulate activity. But again, this
is a known quantity. And I hope. Oh God, I hope. That we're going to nail
that one. So I am left asking, from my POV, what else?

Well, the stuff I put in my email, I guess. I have a big backlog of project
management stuff to get through. Things I want to bring to the list. Things
that should hopefully get easier as activity picks up.

Perhaps some of these are things you might be interested in? One of the
things we really really desperately need is someone to organise and run a
JIRA triage team. The goal being, I think, to just keep an eye on JIRA,
field incoming tickets, close them out where appropriate, or categorise and
assign them otherwise.

We also need a docs team. And a marketing team. And a PM team. These teams
might just be one person to begin with. But I think we need someone to step
up to the plate and say "I will look after this."

There are lots of ways to contribute that don't involve Erlang. I don't
know Erlang. :)

Again, I think some metrics would be a good idea. For example, if we say,
okay, well, we want to double our committership by Q4. That invites a
conversation. How do we do that?

These are important questions to be asking!

On 7 March 2013 11:04, Dirkjan Ochtman <> wrote:

> (warning, grumpy rant forthcoming...)
> On Wed, Mar 6, 2013 at 7:14 PM, Noah Slater <> wrote:
> > Thoughts?
> It seems to me that a lot of this hinges on releases. Releases
> generate publicity and therefore developer interest, thus developer
> engagement. Releases make sure that work developers do gets into
> user's hands soon.
> CouchDB, and I am sorry to have been banging this drum for a few years
> now, is the worst open source project at doing releases I know.
> Here's a quote from this list, from February 13:
> > I plan to cut a release candidate from the 1.3.x branch this weekend.
> And another, from Nov 13:
> > when we set out to ship 1.3.0, we thought the cors and docs
> > branches were just around the corner. That was a couple of
> > weeks ago. We are just starting with this, but the whole
> > idea of time-based releases is that we do not wait for
> > feature branches to be ready.
> >
> > I’d like to propose that we ignore everything we’ve said
> > before and do the following:
> >
> >  - ship 1.3.0 as reflected in the 1.3.x branch now.
> Here's another, from October 23:
> > It's been a while since we released and I want to change this now. I
> > propose making a 1.3.x branch from today's master
> > (66529378dd06342929e04772370f3509cbe786a5) and building 1.3.0 there.
> Another, from June 16:
> > 1. We'd like to proposed formal time-based releases
> Et cetera. As an example, the EventSource bits, which are actually
> something which would be very useful for us at work, were committed to
> the tree on May 16. They are yet to be released.
> I feel a bit hypocritical for saying all this, since I don't
> contribute much to core CouchDB (although I did do a bunch of the doc
> conversion, try to be helpful around the edges and maintain
> couchdb-python). The reason for this is mostly that I thoroughly
> dislike Erlang as a language, and have no intention of learning it
> just to help out with CouchDB. I did some Futon work back in the day,
> but had lots of trouble getting it committed since no one's really
> owned Futon for a while (and right now, it looks like other people
> have that bit covered, though they're using a modern but also quite
> complex development stack that will make it unlikely for a lowly
> back-end web developer dude like me to be able to contribute much).
> So, IMNSH and annoyingly harsh O, stop talking so much about how to
> energize the project, and Just. Ship. It. Every month, preferably. Fix
> the test suite and whatever else makes it so damn hard to release.
> Insert story here about that dude who realized people were trying to
> fix the wrong problem [1].
> End of rant, cheers,
> Dirkjan
> [1]


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message