Paul, How long before we can land COUCHDB-1426?
On Thu, Mar 15, 2012 at 8:48 AM, Paul Davis <paul.joseph.da...@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? ;)
