couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: 1.2.0 status update
Date Thu, 15 Mar 2012 15:52:39 GMT

How long before we can land COUCHDB-1426?

On Thu, Mar 15, 2012 at 8:48 AM, Paul Davis <>wrote:
> Nope. Though that was a bit silly of us.


It was something of an experiment. And one that turned out quite well, I
think. I figured that if one person was enabled to drive each issue, and
had the say in what was done, etc, then we might see quicker progress on
them. There is a certain amount of pride that comes with having your name
attached to something, and being deputised to make something happen.

Out of four issues, we saw three of them get fixed very quickly. One of
them had looked almost insurmountable before this organisations. I
think Bob, Bob, and Jan, and everyone who helped then, did a fantastic job,
and I was proud to see the community come together in the way that it did.
We dropped the ball on COUCHDB-1426, but it's not a big deal. All I am
trying to do is be an annoying gadfly who won't shut up about it. And I
will continue to annoy and pester people until we can ship. Lighting fires
under people's arses. If that costs me some browny points in the process,
then so be it. We need to ship. We HAVE to ship.


Because we haven't made a major version release for almost a year. As a
project, we have slowed down a lot in recent years. Some of this is
completely fine. We're a database, after-all, and one that has a fetish for
correctness. But on the other hand, there have been a number of times where
tickets are debated back and forth in JIRA, loose steam, and then languish.
There is a fine line between being cautious, and allowing permission
culture to let tickets atrophy.

I think we all know the misfortunes that have befallen the project
recently. We've had Ubuntu dropping CouchDB, we've had Damien dropping
CouchDB, we've had Couchbase confusing our users, we've had Mikeal publicly
deriding us, and more recently we've had NPM's security boo boo cast a
spotlight on us. Most of these things are not our fault. (The only one I
think that says anything about the project is Mikeal's posts, which I have
taken to heart a little bit.) But regardless, from the outside perspective,
people have been looking in and asking themselves, is it all over for
CouchDB? This is, perhaps, the most important moment in CouchDB's history.
It's do or die, and getting 1.2.0 out is the first step on a long, and
hopefully enjoyable, path towards a better, stronger, project.

How long before we can land COUCHDB-1426? :)

I do understand your passion and I'm glad to have you as part of the
> community. My peevishness here is that we're being more reactive
> rather than proactive in our approach to addressing the issues at
> hand. For instance, what takes us so long to release? Mostly the fact
> that master/trunk/maintenance-branches are never in a consistent state
> ready for release.

Well, in this instance, I have been trying to release for two weeks, and
what is slowing me down is slow progress on release blockers. This is This
has nothing to do with branch maintenance. COUCHDB-1426 is slowing us down.

How long before we can land COUCHDB-1426? :P

But maybe you meant in general. As an ongoing thing. I do not agree that
our problems are entirely technical in nature. I like that you're
approaching it from a technical angle, and I actually agree with everything
you say from hereon in. But I am approaching from another angle myself.
Which is good, really. Because there are many things we could be doing to
fix the project.

So, after this release, there are three major community things that I want
to try out. I have been collecting my ideas on them, and the occasional bit
of private feedback for the best part of a month.

The first the concept of teams. A team is like a bigger, more formal
version of what we did for the 1.2.0 blockers. The teams I have thought of
so far are Community, JIRA, Wiki, Documentation, QA, Packaging, Core,
Mobile, Platform, and Release. The idea being that you don't have to be a
committer to be on a team. Anyone could be on the JIRA
Team, triaging tickets. You, Paul, would almost certainly be on the QA,
Packaging, Release, and Development teams. Each team would have a lead, and
the lead would be responsible for driving and communicating progress.

The second is the concept of a heartbeat. This would be a weekly and
monthly checklist of items, and activities, much like the release procedure
or the test procedure. Think of it like a set of cron jobs for the project.
The PMC would be responsible for carrying out these tasks. The main purpose
of the heartbeat will be to keep momentum, sort out any issues before they
stagnate, provide steerage, and collect feedback from all of the team
leads, and to communicate progress to the community and the board.

The third is a more well defined roadmap process. Now, more than ever,
CouchDB needs some product management. Which in my view, is about enabling
and documenting a unified vision of the product, being a user advocate, as
well as working with the release team to enable faster,
more iterative releases. Like a meta-release procedure. What do we want in
our next major revision? What should we leave out? When should we aim for?
What should we do about our maintenance versions. That sort of stuff.

These are the main ideas I have at the moment. I welcome the community's
feedback on them, though this thread, or this moment, is not the best time
for it. I only mention them now to illustrate that while you, Paul, might
be thinking about the engineering challenges in front of you, I am thinking
about the community challenges in front of us. And I think that's just

> If you really want to get super serious in showing
> the world the awesomeness then come join me in a stand for being a
> better software project (engineering wise. I personally think our
> community is best by lots).

I won't comment on all of your points, because I agree with them. I have
actually made a note to myself to revisit your email after the release, so
that we can start to talk about where these items fit in on the roadmap.
(See my above note about wanting an actual roadmap process.) Unfortunately,
a lot of the stuff I want to do only makes sense after the 1.2.0 release. I
want to focus all my energy on getting this shipped, and I want everyone
else to do the same. Once this is out of the door, I think there are a lot
of conversations that need to happen, and a lot of things that need to
change. But let's get this shipped. This is yet another reason why I feel a
fire under my arse, and why I am trying to light fires under other people's
arses. We have SO much to do, but we need to ship this puppy first.

How long before we can land COUCHDB-1426? :D

> 7. Fix our fucking website to not suck balls (yes, already in motion
> if we accept that a body in motion remains in motion until acted upon
> by an outside round house kick to the face).

I have something up my sleeve here, but I'm not prepared to act on it until
we ship 1.2.0. My intention is to roll out the new version of the site
along with the 1.2.0 release announcement. Yet another reason why I have
such a sense of urgency. You have no idea how freaking awesome our new site
looks. But I am waiting on 1.2.0 before I'm prepared to land it. (I am
purposefully not sharing it, because that will kill it, like it has killed
every other re-design attempt. I am being bold, and I will ask for
forgiveness if I've made a mistake. But trust me it is awesome, and if you
completely hate it, you can veto and roll it back afterwards.)

How long before we can land COUCHDB-1426? ^__^

But above all else, lets be true to us. This project has prided itself
> on correctness above all else since I've been involved.

Agreed. But let's light some fires up some people's arses. I want us all to
have the same sense of urgency.

> I can't resist the Zen of CouchDB:
> 1. Relax
> 2. Everyone is welcome
> 3. Your data is safe with us
> 4. Its simpler than you think
> 5. Fast is good
> 6. But safe and correct are best
> 7. Advanced uses should be supported
> 8. But not at the expense of core simplicity
> 9. Always respect existing standards
> 10. Unless those standards are absurd

I like this. I may put it on the wiki later.

> So in closing, I know your fever, but chill, Winston. They know its us.

I'll chill when 1.2.0 is shipped.

How long before we can land COUCHDB-1426? ;)

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