couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Dionne <dio...@dionne-associates.com>
Subject Re: 1.2.0 status update
Date Thu, 15 Mar 2012 22:49:53 GMT
I'll be more than happy to, after the 1.2 release is out, as Dave mentioned we should all table
it for now. Remind me then -- Bob


On Mar 15, 2012, at 2:28 PM, Noah Slater wrote:

> Bob,
> 
> Can you explain your remarks?
> 
> Thanks,
> 
> 
> On 15 Mar 2012, at 17:28, Bob Dionne <dionne@dionne-associates.com> wrote:
> 
>> Noah,
>> 
>> Sorry, but I disagree. I don't think your experiment worked well at all and I think
the approach you are taking is going to alienate people.
>> 
>> Best regards,
>> 
>> Bob
>> 
>> On Mar 15, 2012, at 11:52 AM, Noah Slater wrote:
>> 
>>> Paul,
>>> 
>>> How long before we can land COUCHDB-1426?
>>> 
>>> On Thu, Mar 15, 2012 at 8:48 AM, Paul Davis <paul.joseph.davis@gmail.com>wrote:
>>>> 
>>>> Nope. Though that was a bit silly of us.
>>> 
>>> 
>>> Why?
>>> 
>>> 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.
>>> 
>>> Why?
>>> 
>>> 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
>>> smashing.
>>> 
>>> 
>>>> 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? ;)
>> 


Mime
View raw message