Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6E2DD9528 for ; Thu, 15 Mar 2012 17:59:31 +0000 (UTC) Received: (qmail 90061 invoked by uid 500); 15 Mar 2012 17:59:30 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 89929 invoked by uid 500); 15 Mar 2012 17:59:30 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 89920 invoked by uid 99); 15 Mar 2012 17:59:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Mar 2012 17:59:30 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of robert.newson@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-iy0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Mar 2012 17:59:23 +0000 Received: by iage36 with SMTP id e36so5629524iag.11 for ; Thu, 15 Mar 2012 10:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :content-type; bh=az9ip9efl/doIQGgWb5dN2QNrHG65wUy0YNgtdMUKQk=; b=azXcM62u5VoA9AKFu7k5ARnmx/5xMl8M+61E4FWNtpFQCsDMcwROpLTkS3/8vSLGsd NEw4iNDKNK8C81EfwDH5qbI0T22fZClJ6jRQzSFNZMWq66P2upZu7KxUnUAVM4/axyM7 xXYPxYzgmGmyiGUrnthVtaz+ZHKqDB3byaDxZ0N5GTWRj8irmcymtVi6O7vL42SCsDSj /gcZwU3dHMKxZlA4wmzj+JoT9ulAKG2I7GEOpSeQf8KjlBqVSEqslP0KDIH/BRVhdGIe UjJ0z3JRcpGj+eMhm6+MImeXViFmGqasWC7BAuW7c9JGW8OboK9MlPLrVRjMVj5hgIDh wYQg== Received: by 10.50.76.130 with SMTP id k2mr10645350igw.22.1331834342207; Thu, 15 Mar 2012 10:59:02 -0700 (PDT) References: <0BB4F003-4C8B-441A-9CEF-08782AF170BB@dionne-associates.com> <-4709298919342606669@unknownmsgid> <4F60C606.5060409@83864.com> <302B50A4-B2EE-4B01-9EA7-CD46B187C356@dionne-associates.com> From: Robert Newson In-Reply-To: <302B50A4-B2EE-4B01-9EA7-CD46B187C356@dionne-associates.com> Mime-Version: 1.0 (1.0) Date: Thu, 15 Mar 2012 17:59:23 +0000 Message-ID: <-8091222010974240678@unknownmsgid> Subject: Re: 1.2.0 status update To: "dev@couchdb.apache.org" Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org I'd say 3 out of 4 is pretty darn good. Sent from my iPhone On 15 Mar 2012, at 17:28, Bob Dionne 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 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? ;) >