1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Hey chaps,

How are we doing on:

* Bob Dionne will driving COUCHDB-1424
* Benoît Chesneau will be driving COUCHDB-1426
* Robert Newson will be driving the performance work

The R15B patch has been committed already.

Thanks!

N

Re: 1.2.0 status update

[Jan Lehnardt <ja...@apache.org>]

Thanks for the summary Dave, this is helpful to keep everyone 
in the loop :)


On Mar 14, 2012, at 00:20 , Dave Cottlehuber wrote:

> Brief update from today.
> 
> etag_views issue emerged, Jan and Filipe sorted that out already & its
> been committed.
> Sorry; I was aware of it but didn't raise it as I wasn't sure it was
> actually a couch issue.
> 
> Following that I got all etaps and futon tests passing on FF Aurora 12, running
> Couch on Mac Lion and Linux Mint Debian Edition. If somebody can
> confirm for ubuntu that
> would be a help - any other OS reqd?
> 
> I slowly worked my up past gpg signing in the release procedure (all
> good) but died at
> the md5 stage due to md5sum not being installed. I can see why some of
> this takes a while.
> 
> I am not clear whether the PMC have made a call on including
> COUCHDB-1426 or not;

> but either way we need to ensure we have:
> - out of the box builds on most sensible platform default configurations
> - a clear statement on how to build against a compatible SpiderMonkey
> when the above doesn't apply.
> 
> From what Benoît says, the current approach doesn't handle the latter,
> so I think we need to complete
> the patch.
> 
> What's the plan to move forwards here? We are damn close but a half
> finished solution for 1426 will
> simply mean another round. This needs more collaboration so that we
> are not working async on this.
> 
> Can we organise enough people tomorrow evening (Euro time / daytime US
> time) to nail this specific issue?
> Or you can sort it while I sleep ;-)

The PMC hasn't decided on this in particular, but we (dev@) agreed last week that
1426 is a nice to have for 1.2.0 but not a blocker and that we should fix it
asap, but if we can't make it for 1.2.0, we should include the fix in a 1.2.1
shortly after and document the situation for 1.2.0.

I welcome any efforts to tag team the issue, but we shouldn't hold 1.2.0
for this. :)

Cheers
Jan
-- 



> 


> 
> A+
> Dave
> 
> 
> On 9 March 2012 21:30, Noah Slater <ns...@tumbolia.org> wrote:
>> Cool. Please circle back here and let me know when I am good to call 1.2.0.
>> 
>> We're waiting on you Paul. No pressure. ;)
>> 
>> (Seriously, thanks!)
>> 
>> On Fri, Mar 9, 2012 at 8:24 PM, Paul Davis <pa...@gmail.com>wrote:
>> 
>>> Will review this as soon as I catch up on what happened on the
>>> internet whilst I was sleeping.
>>> 
>>> On Fri, Mar 9, 2012 at 8:53 AM, Benoit Chesneau <bc...@gmail.com>
>>> wrote:
>>>> On Fri, Mar 9, 2012 at 4:05 AM, Noah Slater <ns...@tumbolia.org>
>>> wrote:
>>>>> Woot, thanks.
>>>>> 
>>>>> How's your stuff going, Benoît?
>>>> 
>>>> 
>>>> Sorry have been distracted by some due work yesterday. I updated the
>>>> ticket with a new version of the patch.
>>>> 
>>>> Hopefully we aren't so far. I tested it in different scenarios and it
>>>> worked. If anyone can review it that would help.
>>>> 
>>>> - benoît
>>> 

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Just to clarify, Benoît only agreed to drive it. Driving might've been
landing it, or it might've been organising other people to land it. I
appreciate the work that both Benoît and Paul have put in. Obviously, they
both "bothered" to help out here. But anyone else could've chipped in at
any point. It's a shame that didn't happen, but it's not the end of the
world. I think it's safe to assume, from the lack of people rushing to get
this fixed during the last two weeks, that it can wait until 1.2.1.

Unless it get's fixed tonight while I sleep... ;)

On Wed, Mar 14, 2012 at 1:56 AM, Randall Leeds <ra...@gmail.com>wrote:

> On Tue, Mar 13, 2012 at 18:27, Noah Slater <ns...@tumbolia.org> wrote:
>
> > Thanks Dave.
> >
> > On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber <da...@muse.net.nz>
> > wrote:
> > >
> > > What's the plan to move forwards here? We are damn close but a half
> > > finished solution for 1426 will
> > > simply mean another round. This needs more collaboration so that we
> > > are not working async on this.
> > >
> >
> > I don't think we are damn close.
> >
> > We've seen hardly any progress with this issue during the week and a half
> > since Benoît took ownership of it. That tells me that it can't be very
> > important, and so I will attempt another vote tomorrow, with or without
> it.
> >
>
> To be fair, I saw a couple iterations from Paul and some work from Benoit
> and I know Benoit has been at PyCon and busy with python things.
> But I agree, I don't see it as a blocker.
>

Re: 1.2.0 status update

[Randall Leeds <ra...@gmail.com>]

On Tue, Mar 13, 2012 at 18:27, Noah Slater <ns...@tumbolia.org> wrote:

> Thanks Dave.
>
> On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber <da...@muse.net.nz>
> wrote:
> >
> > What's the plan to move forwards here? We are damn close but a half
> > finished solution for 1426 will
> > simply mean another round. This needs more collaboration so that we
> > are not working async on this.
> >
>
> I don't think we are damn close.
>
> We've seen hardly any progress with this issue during the week and a half
> since Benoît took ownership of it. That tells me that it can't be very
> important, and so I will attempt another vote tomorrow, with or without it.
>

To be fair, I saw a couple iterations from Paul and some work from Benoit
and I know Benoit has been at PyCon and busy with python things.
But I agree, I don't see it as a blocker.

Re: 1.2.0 status update

[Jason Smith <jh...@iriscouch.com>]

On Wed, Mar 14, 2012 at 4:04 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Mar 13, 2012 at 7:47 PM, Jason Smith <jh...@iriscouch.com> wrote:
>> IMHO:
>>
>> It affects advanced users, with multiple JS builds installed. It is
>> not a 1.2.0 blocker. It's not relevant to this discussion.
>
> It is. If you reread the ticket it appears that the problem is more
> important than expected and I hesitated a lot to let it as blocker
> like it was initially. Since the release have been postponed, we aslo
> have the perfect opportunity to really fix that issue.

Hi, Benoit. You make a strong point.

I noticed your March 02 update to issue 1426. I interpreted that to
mean that 1.2.0 can ship without the bugfix.

I **thought** 1.1.1 also shipped with this bug, in which case it seems
not so severe. (If I am wrong, then I stand corrected.)

-- 
Iris Couch

Re: 1.2.0 status update

[Benoit Chesneau <bc...@gmail.com>]

On Thu, Mar 15, 2012 at 6:33 PM, Benoit Chesneau <bc...@gmail.com> wrote:

> Some bugs especially though based on multiple configurations not on
s/though/those

Re: 1.2.0 status update

[Jan Lehnardt <ja...@apache.org>]

On Mar 15, 2012, at 21:10 , Dave Cottlehuber wrote:

> On 15 March 2012 20:22, Noah Slater <ns...@tumbolia.org> wrote:
>> Again, anyone wanna help out here?
>> 
>> Most of us only have on specific environment we can test on, but the more
>> the merrier I expect.
>> 
>> Benoît, could you throw a list of checkpoints for people to run through and
>> report back with?
> 
> [snip] we're onto it.
> 
> Folks - let's park the non-1.2.0 non-tech discussion for after the
> eagle has landed?
> 
> Nobody on this list is lacking in Couch commitment, and a number of people
> have done an impressive job of juggling other things to help this get
> across the line.
> 
> I'd rather have a couple of uncomfortable nights tag-teaming on this
> and get it sorted -
> we are close!!

Word!

Thanks everybody for pitching in :)

Cheers
Jan
-- 

Re: 1.2.0 status update

[Dave Cottlehuber <da...@muse.net.nz>]

On 15 March 2012 20:22, Noah Slater <ns...@tumbolia.org> wrote:
> Again, anyone wanna help out here?
>
> Most of us only have on specific environment we can test on, but the more
> the merrier I expect.
>
> Benoît, could you throw a list of checkpoints for people to run through and
> report back with?

[snip] we're onto it.

Folks - let's park the non-1.2.0 non-tech discussion for after the
eagle has landed?

Nobody on this list is lacking in Couch commitment, and a number of people
have done an impressive job of juggling other things to help this get
across the line.

I'd rather have a couple of uncomfortable nights tag-teaming on this
and get it sorted -
we are close!!

A+
Dave

Re: 1.2.0 status update

[Benoit Chesneau <bc...@gmail.com>]

On Thu, Mar 15, 2012 at 8:22 PM, Noah Slater <ns...@tumbolia.org> wrote:
> On Thu, Mar 15, 2012 at 6:33 PM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>> On Thu, Mar 15, 2012 at 3:52 PM, Noah Slater <ns...@tumbolia.org> wrote:
>>
>> > How long before we can land COUCHDB-1426? ;)
>>
>> Depends how much feedback and tests are given on that. Want to help?
>>
>
> I time for CouchDB is saturated, but I can help you test for sure.
>
> Is there anyone on this list that can spare a few cycles to help Benoît
> test?
>
> Benoît, how would you us to test?
>
> Is there a list of stuff you'd like people to try?
>
>
>> Keeping pressure like this start to annoy me.
>>
>
> Understood, and I am sorry that you feel annoyed.

Thanks.
>
> I know some people work well under pressure, and some people do not. If my
> last email did not adequately express why I want to apply pressure, no
> follow up will. But this is not how I expect us to operate under normal
> circumstances, so there is no need to worry. But these are not normal
> circumstances.
>
> As Jan keeps saying to me, we need some good news.
>

I completely share the need to have  some good news but in my opinion
it shouldn't take the lead over the release quality. I can understand
we are under pressure (though not so much these days since people are
starting to understand what make couchdb a good fit for them) and
that's why I think we should take the time to make the installation
working for the users and packages maintainer.  Which is a good way,
by the way, to tell to anyone that they don't need anymore a binary
from a third party to enjoy the CouchDB experience.


>
>> Some bugs especially though based on multiple configurations not on
>> the dev control could take time to resolve. And I completely share
>> paul's opinion on that. We should take time when it's about to keep
>> CouchDB robust and stable.
>>
>
> Agreed.
>
> (Though I will note that core stability, and configure time stability are
> two different beasts.)
>
>
>> Anyway was off during last 16h due to flights and saw that @davisp
>> posted a new version that should fix latest issues. Time to test.
>>
>
> Again, anyone wanna help out here?
>
> Most of us only have on specific environment we can test on, but the more
> the merrier I expect.
>
> Benoît, could you throw a list of checkpoints for people to run through and
> report back with?

The best way to test right now is cloning the COUCHDB-1426 branch and
do the follwing tests :

- with spidermonkey installed by your system packaging tool
- with spidermonkey installed in a custom path using --with-js-lib &
--with-js-include
- mixing both, havin a spidermonkey installed globally on the system
and try to use one installed in custom path.

I hope I'm clear, if you have any question bug me on irc or  better by mail.

- benoit

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

On Thu, Mar 15, 2012 at 6:33 PM, Benoit Chesneau <bc...@gmail.com>wrote:

> On Thu, Mar 15, 2012 at 3:52 PM, Noah Slater <ns...@tumbolia.org> wrote:
>
> > How long before we can land COUCHDB-1426? ;)
>
> Depends how much feedback and tests are given on that. Want to help?
>

I time for CouchDB is saturated, but I can help you test for sure.

Is there anyone on this list that can spare a few cycles to help Benoît
test?

Benoît, how would you us to test?

Is there a list of stuff you'd like people to try?


> Keeping pressure like this start to annoy me.
>

Understood, and I am sorry that you feel annoyed.

I know some people work well under pressure, and some people do not. If my
last email did not adequately express why I want to apply pressure, no
follow up will. But this is not how I expect us to operate under normal
circumstances, so there is no need to worry. But these are not normal
circumstances.

As Jan keeps saying to me, we need some good news.


> Some bugs especially though based on multiple configurations not on
> the dev control could take time to resolve. And I completely share
> paul's opinion on that. We should take time when it's about to keep
> CouchDB robust and stable.
>

Agreed.

(Though I will note that core stability, and configure time stability are
two different beasts.)


> Anyway was off during last 16h due to flights and saw that @davisp
> posted a new version that should fix latest issues. Time to test.
>

Again, anyone wanna help out here?

Most of us only have on specific environment we can test on, but the more
the merrier I expect.

Benoît, could you throw a list of checkpoints for people to run through and
report back with?

Re: 1.2.0 status update

[Benoit Chesneau <bc...@gmail.com>]

On Thu, Mar 15, 2012 at 3:52 PM, Noah Slater <ns...@tumbolia.org> wrote:

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

Depends how much feedback and tests are given on that. Want to help?
Keeping pressure like this start to annoy me.

Some bugs especially though based on multiple configurations not on
the dev control could take time to resolve. And I completely share
paul's opinion on that. We should take time when it's about to keep
CouchDB robust and stable.

Anyway was off during last 16h due to flights and saw that @davisp
posted a new version that should fix latest issues. Time to test.
Hopefully we will all remember that day like the day where finally
most of the people could install couchdb without requiring external
layers.

- benoît

Re: 1.2.0 status update

[Bob Dionne <di...@dionne-associates.com>]

I should add, best of luck with the new web site  -- Bob

On Mar 15, 2012, at 1:28 PM, 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 <pa...@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? ;)
> 

Re: 1.2.0 status update

[Bob Dionne <di...@dionne-associates.com>]

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 <di...@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 <pa...@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? ;)
>> 

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Bob,

Can you explain your remarks?

Thanks,


On 15 Mar 2012, at 17:28, Bob Dionne <di...@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 <pa...@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? ;)
> 

Re: 1.2.0 status update

[Robert Newson <ro...@gmail.com>]

I'd say 3 out of 4 is pretty darn good.

Sent from my iPhone

On 15 Mar 2012, at 17:28, Bob Dionne <di...@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 <pa...@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? ;)
>

Re: 1.2.0 status update

[Bob Dionne <di...@dionne-associates.com>]

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 <pa...@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? ;)

Re: 1.2.0 status update

[Jan Lehnardt <ja...@apache.org>]

<3 Noah.


On Mar 15, 2012, at 16:52 , Noah Slater wrote:

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

Re: 1.2.0 status update

[Jan Lehnardt <ja...@apache.org>]

On Mar 19, 2012, at 15:00 , Bob Dionne wrote:

> This is great, when we can expect the next build? I'd like to set aside some time to test it -- Bob

We never have and never will be making any commitments as to when a certain…ah, no :)

Noah mentioned to me he might get to it tonight his time, but I'll leave it to him to comment.

Cheers
Jan
--



> 
> On Mar 19, 2012, at 5:34 AM, Jan Lehnardt wrote:
> 
>> tl;dr: 1.2.0 is finally ready to roll.
>> 
>> 
>> Just to close this loop:
>> 
>> COUCHDB-1426 is closed and committed.
>> 
>> Shortly after, COUCHDB-1445 got reported and solved (woop).
>> 
>> Thanks everybody for pushing hard on these last few steps!
>> 
>> Cheers
>> Jan
>> -- 
>> 
>> 
>> 
>> On Mar 16, 2012, at 05:31 , Randall Leeds wrote:
>> 
>>> On Mar 15, 2012 8:30 PM, "Jason Smith" <jh...@iriscouch.com> wrote:
>>>> 
>>>> On Thu, Mar 15, 2012 at 10:59 PM, Robert Newson <ro...@gmail.com>
>>> wrote:
>>>>> Noah = awesome. Kicking arse and takin' names.
>>>> 
>>>> Completely agree.
>>>> 
>>>> Also, your first sentence is a valid Erlang statement. If that's not
>>>> evidence that God is on our side, I don't know what is.
>>>> 
>>>> --
>>>> Iris Couch
>>> 
>>> I just LOL'd. I'm parsing out. I'll be in a standards meeting in eight
>>> hours, but should be available, with reasonable latency, to test 1426
>>> throughout.
>> 
> 

Re: 1.2.0 status update

[Bob Dionne <di...@dionne-associates.com>]

This is great, when we can expect the next build? I'd like to set aside some time to test it -- Bob

On Mar 19, 2012, at 5:34 AM, Jan Lehnardt wrote:

> tl;dr: 1.2.0 is finally ready to roll.
> 
> 
> Just to close this loop:
> 
> COUCHDB-1426 is closed and committed.
> 
> Shortly after, COUCHDB-1445 got reported and solved (woop).
> 
> Thanks everybody for pushing hard on these last few steps!
> 
> Cheers
> Jan
> -- 
> 
> 
> 
> On Mar 16, 2012, at 05:31 , Randall Leeds wrote:
> 
>> On Mar 15, 2012 8:30 PM, "Jason Smith" <jh...@iriscouch.com> wrote:
>>> 
>>> On Thu, Mar 15, 2012 at 10:59 PM, Robert Newson <ro...@gmail.com>
>> wrote:
>>>> Noah = awesome. Kicking arse and takin' names.
>>> 
>>> Completely agree.
>>> 
>>> Also, your first sentence is a valid Erlang statement. If that's not
>>> evidence that God is on our side, I don't know what is.
>>> 
>>> --
>>> Iris Couch
>> 
>> I just LOL'd. I'm parsing out. I'll be in a standards meeting in eight
>> hours, but should be available, with reasonable latency, to test 1426
>> throughout.
> 

Re: 1.2.0 status update

[Jan Lehnardt <ja...@apache.org>]

tl;dr: 1.2.0 is finally ready to roll.


Just to close this loop:

COUCHDB-1426 is closed and committed.

Shortly after, COUCHDB-1445 got reported and solved (woop).

Thanks everybody for pushing hard on these last few steps!

Cheers
Jan
-- 



On Mar 16, 2012, at 05:31 , Randall Leeds wrote:

> On Mar 15, 2012 8:30 PM, "Jason Smith" <jh...@iriscouch.com> wrote:
>> 
>> On Thu, Mar 15, 2012 at 10:59 PM, Robert Newson <ro...@gmail.com>
> wrote:
>>> Noah = awesome. Kicking arse and takin' names.
>> 
>> Completely agree.
>> 
>> Also, your first sentence is a valid Erlang statement. If that's not
>> evidence that God is on our side, I don't know what is.
>> 
>> --
>> Iris Couch
> 
> I just LOL'd. I'm parsing out. I'll be in a standards meeting in eight
> hours, but should be available, with reasonable latency, to test 1426
> throughout.

Re: 1.2.0 status update

[Randall Leeds <ra...@gmail.com>]

On Mar 15, 2012 8:30 PM, "Jason Smith" <jh...@iriscouch.com> wrote:
>
> On Thu, Mar 15, 2012 at 10:59 PM, Robert Newson <ro...@gmail.com>
wrote:
> > Noah = awesome. Kicking arse and takin' names.
>
> Completely agree.
>
> Also, your first sentence is a valid Erlang statement. If that's not
> evidence that God is on our side, I don't know what is.
>
> --
> Iris Couch

I just LOL'd. I'm parsing out. I'll be in a standards meeting in eight
hours, but should be available, with reasonable latency, to test 1426
throughout.

Re: 1.2.0 status update

[Jason Smith <jh...@iriscouch.com>]

On Thu, Mar 15, 2012 at 10:59 PM, Robert Newson <ro...@gmail.com> wrote:
> Noah = awesome. Kicking arse and takin' names.

Completely agree.

Also, your first sentence is a valid Erlang statement. If that's not
evidence that God is on our side, I don't know what is.

-- 
Iris Couch

Re: 1.2.0 status update

[Robert Newson <ro...@gmail.com>]

Noah = awesome. Kicking arse and takin' names.

Sent from my iPhone

On 15 Mar 2012, at 15:53, Noah Slater <ns...@tumbolia.org> wrote:

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

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Paul,

How long before we can land COUCHDB-1426?

On Thu, Mar 15, 2012 at 8:48 AM, Paul Davis <pa...@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? ;)

Re: 1.2.0 status update

[Paul Davis <pa...@gmail.com>]

On Wed, Mar 14, 2012 at 10:03 PM, Noah Slater <ns...@tumbolia.org> wrote:
> On Thu, Mar 15, 2012 at 2:43 AM, Paul Davis <pa...@gmail.com>wrote:
>
>> > Can't you feel the heat too?
>>
>> Nope. Is there a deadline I'm not aware of?
>>
>
> Evidently so.
>
> Were you aware that the Friday just gone was a deadline?

Nope. Though that was a bit silly of us.

>
> But you're missing my point. The deadline (that we agreed on via lazy
> consensus on the mailing list) was a symptom of the fire. The fire is not
> the cause. The cause is all of misfortune the project has had recently. The
> need to show the world that we are still alive and kicking, before it is
> too late. The need to demonstrate that we're an active project that doesn't
> get bogged down through process, and people disagreeing with each other. Do
> not under-estimate the impact of Mikeal's posts on the community at large.
> While I understand, and appreciate, the debates that have gone in to fixing
> the 1.2.0 issues, I feel like we could've moved faster as a team, and
> worked with more co-ordination. The outward possible perception is
> particularly unfortunate, given the context.
>
> So yes. I feel a fire. That fire is my passion for CouchDB. And I know that
> now more than ever, we, as a community need to pitch in together, pull our
> finger out, ship a great product, and start making the sort of inroads that
> will take us to the next level. It's tough, and there's a lot of
> ingrained behavioural stuff, and attitude stuff, that needs massaging. But
> I am happy that you seem to understand where my motivation is coming from,
> and are willing to overlook some rather hasty (frustrated) emails.

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. 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).

This starts with simple things:

1. Tests that fail randomly are disabled until they don't.
2. Tests that run in the browser should be deleted because browsers
are confounding and confounding is the enemy and this should be
obvious to anyone everywhere and I've been saying this for years.
3. Documentation should be top notch and as such is a first class
citizen which means all commits that change bevhaviour must have a
corresponding update to documentation.
4. Make a commitment to having a clean internal code base that we can
change quickly under pressure.
5. Update our JIRA SOPs so that shit that needs fixed is obvious and
shit that can be improved is not mistaken for shit that must be fixed.
6. More tests. Patches that show bugs should be accepted without fixes
and become blockers until fixed.
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).
8. Other shit that we don't do.

But above all else, lets be true to us. This project has prided itself
on correctness above all else since I've been involved. Many times
we've resisted the attempt to change that priority because someone
said something or some other project had better "benchmarks". I agree
that we should focus on improving our outward appearance, but I also
think we should never ever lose sight of that core principle, "Your
data is safe with us." So, with all due respect to the Zen of Python,
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

Or something.

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

http://www.youtube.com/watch?v=idO3VjT8sjk
http://www.youtube.com/watch?v=P7kme3GC9Gs

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

On Thu, Mar 15, 2012 at 2:43 AM, Paul Davis <pa...@gmail.com>wrote:

> > Can't you feel the heat too?
>
> Nope. Is there a deadline I'm not aware of?
>

Evidently so.

Were you aware that the Friday just gone was a deadline?

But you're missing my point. The deadline (that we agreed on via lazy
consensus on the mailing list) was a symptom of the fire. The fire is not
the cause. The cause is all of misfortune the project has had recently. The
need to show the world that we are still alive and kicking, before it is
too late. The need to demonstrate that we're an active project that doesn't
get bogged down through process, and people disagreeing with each other. Do
not under-estimate the impact of Mikeal's posts on the community at large.
While I understand, and appreciate, the debates that have gone in to fixing
the 1.2.0 issues, I feel like we could've moved faster as a team, and
worked with more co-ordination. The outward possible perception is
particularly unfortunate, given the context.

So yes. I feel a fire. That fire is my passion for CouchDB. And I know that
now more than ever, we, as a community need to pitch in together, pull our
finger out, ship a great product, and start making the sort of inroads that
will take us to the next level. It's tough, and there's a lot of
ingrained behavioural stuff, and attitude stuff, that needs massaging. But
I am happy that you seem to understand where my motivation is coming from,
and are willing to overlook some rather hasty (frustrated) emails.

Re: 1.2.0 status update

[Paul Davis <pa...@gmail.com>]

> Can't you feel the heat too?

Nope. Is there a deadline I'm not aware of?

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

I didn't ask for a promise, I asked for an expectation. I want to release.
I have been asked to delay the release. I think it is only fair to ask for
an your expectation about the length of that delay. I don't care that this
is an open source project, and that we all contribute our time for free,
and because we feel passionately about the project. That is no excuse to
expect any less from people. ETAs on release-critical blockers seem like a
perfectly reasonable request, within that context.

I am insistent because I there is a fire under my arse. Getting 1.2.0 out
as soon as possible, and with as few problems as possible, is
a critical first step towards our recovery from recent events. Can't you
feel the heat too?

On Thu, Mar 15, 2012 at 1:51 AM, Paul Davis <pa...@gmail.com>wrote:

> I'm not now nor will I ever promise when a patch is going to land.
> It'll land when its ready. Once again I enjoy your enthusiasm but I'm
> a bit confused by your insistence. We're working on it. I'm even
> fairly sure I fixed Wendall and Dave's issue tonight. Randall had a
> report on a build failure though.
>
> If other people are interested, they can try the current iteration of
> the patch by cloning the COUCHDB-1426 branch from the ASF git repo and
> building locally and reporting results on the JIRA issue. I'm pretty
> sure Randall's issue was on Linux with SpiderMonkey 1.8.5 if anyone
> has that configuration handy. And if they can get it to fail it would
> be super dandy to ping me with a login to a machine that repro's.
> (I'll even screen share whilst debugging in case people want to
> watch).
>
> On Wed, Mar 14, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org>
> wrote:
> > We've waited just shy of two weeks now. How long before a fix lands? If
> > you're proposing that we delay the release again, I need to know by how
> > much you plan to delay the release. Looking at Paul and Benoît here.
> >
> > On Wed, Mar 14, 2012 at 4:23 PM, Wendall Cada <we...@83864.com>
> wrote:
> >
> >> +1 On what Benoit says.
> >>
> >> I'll be using the current iteration of this patch to update the couchdb
> >> rpm spec I've been working on. Additionally, I've opened a dialog with
> the
> >> Redhat package maintainer about the possibility of maintaining or
> >> contributing to this package for RHEL/Centos and Fedora. This can be an
> >> issue for any distribution package maintainer.
> >>
> >> Wendall
> >>
> >>
> >> On 03/13/2012 09:04 PM, Benoit Chesneau wrote:
> >>
> >>> On Tue, Mar 13, 2012 at 7:47 PM, Jason Smith<jh...@iriscouch.com>
>  wrote:
> >>>
> >>>> IMHO:
> >>>>
> >>>> It affects advanced users, with multiple JS builds installed. It is
> >>>> not a 1.2.0 blocker. It's not relevant to this discussion.
> >>>>
> >>> It is. If you reread the ticket it appears that the problem is more
> >>> important than expected and I hesitated a lot to let it as blocker
> >>> like it was initially. Since the release have been postponed, we aslo
> >>> have the perfect opportunity to really fix that issue.
> >>>
> >>> Lot of our users are complaining to have some problem installing
> >>> couchdb on their machine. This isn't new. This isn't solved.
> >>>
> >>> While the lazy solution was to direct them to couchbase stuff, or
> >>> these days to build_couchdb or rcouch, I would really prefer we fix
> >>> this *important* issue and let people choose if they prefer to install
> >>> via a vendor or the official *distribution*. Last iteration of the
> >>> patch fix most of the cases I guess. We can choose like said above to
> >>> use this version and fix latest issues in next minor release or trying
> >>> to solve that last one.  At this point, after different iterations,
> >>> feedback is appreciated and that is the main reason why updates of the
> >>> tickets are sent to the ml.
> >>>
> >>>
> >>> - benoit
> >>>
> >>
> >>
>

Re: 1.2.0 status update

[Paul Davis <pa...@gmail.com>]

I'm not now nor will I ever promise when a patch is going to land.
It'll land when its ready. Once again I enjoy your enthusiasm but I'm
a bit confused by your insistence. We're working on it. I'm even
fairly sure I fixed Wendall and Dave's issue tonight. Randall had a
report on a build failure though.

If other people are interested, they can try the current iteration of
the patch by cloning the COUCHDB-1426 branch from the ASF git repo and
building locally and reporting results on the JIRA issue. I'm pretty
sure Randall's issue was on Linux with SpiderMonkey 1.8.5 if anyone
has that configuration handy. And if they can get it to fail it would
be super dandy to ping me with a login to a machine that repro's.
(I'll even screen share whilst debugging in case people want to
watch).

On Wed, Mar 14, 2012 at 12:23 PM, Noah Slater <ns...@tumbolia.org> wrote:
> We've waited just shy of two weeks now. How long before a fix lands? If
> you're proposing that we delay the release again, I need to know by how
> much you plan to delay the release. Looking at Paul and Benoît here.
>
> On Wed, Mar 14, 2012 at 4:23 PM, Wendall Cada <we...@83864.com> wrote:
>
>> +1 On what Benoit says.
>>
>> I'll be using the current iteration of this patch to update the couchdb
>> rpm spec I've been working on. Additionally, I've opened a dialog with the
>> Redhat package maintainer about the possibility of maintaining or
>> contributing to this package for RHEL/Centos and Fedora. This can be an
>> issue for any distribution package maintainer.
>>
>> Wendall
>>
>>
>> On 03/13/2012 09:04 PM, Benoit Chesneau wrote:
>>
>>> On Tue, Mar 13, 2012 at 7:47 PM, Jason Smith<jh...@iriscouch.com>  wrote:
>>>
>>>> IMHO:
>>>>
>>>> It affects advanced users, with multiple JS builds installed. It is
>>>> not a 1.2.0 blocker. It's not relevant to this discussion.
>>>>
>>> It is. If you reread the ticket it appears that the problem is more
>>> important than expected and I hesitated a lot to let it as blocker
>>> like it was initially. Since the release have been postponed, we aslo
>>> have the perfect opportunity to really fix that issue.
>>>
>>> Lot of our users are complaining to have some problem installing
>>> couchdb on their machine. This isn't new. This isn't solved.
>>>
>>> While the lazy solution was to direct them to couchbase stuff, or
>>> these days to build_couchdb or rcouch, I would really prefer we fix
>>> this *important* issue and let people choose if they prefer to install
>>> via a vendor or the official *distribution*. Last iteration of the
>>> patch fix most of the cases I guess. We can choose like said above to
>>> use this version and fix latest issues in next minor release or trying
>>> to solve that last one.  At this point, after different iterations,
>>> feedback is appreciated and that is the main reason why updates of the
>>> tickets are sent to the ml.
>>>
>>>
>>> - benoit
>>>
>>
>>

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

We've waited just shy of two weeks now. How long before a fix lands? If
you're proposing that we delay the release again, I need to know by how
much you plan to delay the release. Looking at Paul and Benoît here.

On Wed, Mar 14, 2012 at 4:23 PM, Wendall Cada <we...@83864.com> wrote:

> +1 On what Benoit says.
>
> I'll be using the current iteration of this patch to update the couchdb
> rpm spec I've been working on. Additionally, I've opened a dialog with the
> Redhat package maintainer about the possibility of maintaining or
> contributing to this package for RHEL/Centos and Fedora. This can be an
> issue for any distribution package maintainer.
>
> Wendall
>
>
> On 03/13/2012 09:04 PM, Benoit Chesneau wrote:
>
>> On Tue, Mar 13, 2012 at 7:47 PM, Jason Smith<jh...@iriscouch.com>  wrote:
>>
>>> IMHO:
>>>
>>> It affects advanced users, with multiple JS builds installed. It is
>>> not a 1.2.0 blocker. It's not relevant to this discussion.
>>>
>> It is. If you reread the ticket it appears that the problem is more
>> important than expected and I hesitated a lot to let it as blocker
>> like it was initially. Since the release have been postponed, we aslo
>> have the perfect opportunity to really fix that issue.
>>
>> Lot of our users are complaining to have some problem installing
>> couchdb on their machine. This isn't new. This isn't solved.
>>
>> While the lazy solution was to direct them to couchbase stuff, or
>> these days to build_couchdb or rcouch, I would really prefer we fix
>> this *important* issue and let people choose if they prefer to install
>> via a vendor or the official *distribution*. Last iteration of the
>> patch fix most of the cases I guess. We can choose like said above to
>> use this version and fix latest issues in next minor release or trying
>> to solve that last one.  At this point, after different iterations,
>> feedback is appreciated and that is the main reason why updates of the
>> tickets are sent to the ml.
>>
>>
>> - benoit
>>
>
>

Re: 1.2.0 status update

[Wendall Cada <we...@83864.com>]

+1 On what Benoit says.

I'll be using the current iteration of this patch to update the couchdb 
rpm spec I've been working on. Additionally, I've opened a dialog with 
the Redhat package maintainer about the possibility of maintaining or 
contributing to this package for RHEL/Centos and Fedora. This can be an 
issue for any distribution package maintainer.

Wendall

On 03/13/2012 09:04 PM, Benoit Chesneau wrote:
> On Tue, Mar 13, 2012 at 7:47 PM, Jason Smith<jh...@iriscouch.com>  wrote:
>> IMHO:
>>
>> It affects advanced users, with multiple JS builds installed. It is
>> not a 1.2.0 blocker. It's not relevant to this discussion.
> It is. If you reread the ticket it appears that the problem is more
> important than expected and I hesitated a lot to let it as blocker
> like it was initially. Since the release have been postponed, we aslo
> have the perfect opportunity to really fix that issue.
>
> Lot of our users are complaining to have some problem installing
> couchdb on their machine. This isn't new. This isn't solved.
>
> While the lazy solution was to direct them to couchbase stuff, or
> these days to build_couchdb or rcouch, I would really prefer we fix
> this *important* issue and let people choose if they prefer to install
> via a vendor or the official *distribution*. Last iteration of the
> patch fix most of the cases I guess. We can choose like said above to
> use this version and fix latest issues in next minor release or trying
> to solve that last one.  At this point, after different iterations,
> feedback is appreciated and that is the main reason why updates of the
> tickets are sent to the ml.
>
>
> - benoit

Re: 1.2.0 status update

[Benoit Chesneau <bc...@gmail.com>]

On Tue, Mar 13, 2012 at 7:47 PM, Jason Smith <jh...@iriscouch.com> wrote:
> IMHO:
>
> It affects advanced users, with multiple JS builds installed. It is
> not a 1.2.0 blocker. It's not relevant to this discussion.

It is. If you reread the ticket it appears that the problem is more
important than expected and I hesitated a lot to let it as blocker
like it was initially. Since the release have been postponed, we aslo
have the perfect opportunity to really fix that issue.

Lot of our users are complaining to have some problem installing
couchdb on their machine. This isn't new. This isn't solved.

While the lazy solution was to direct them to couchbase stuff, or
these days to build_couchdb or rcouch, I would really prefer we fix
this *important* issue and let people choose if they prefer to install
via a vendor or the official *distribution*. Last iteration of the
patch fix most of the cases I guess. We can choose like said above to
use this version and fix latest issues in next minor release or trying
to solve that last one.  At this point, after different iterations,
feedback is appreciated and that is the main reason why updates of the
tickets are sent to the ml.


- benoit

Re: 1.2.0 status update

[Jason Smith <jh...@iriscouch.com>]

IMHO:

It affects advanced users, with multiple JS builds installed. It is
not a 1.2.0 blocker. It's not relevant to this discussion.

In the meantime, I have been prepping all the Linux VMs I can find to
test for the next 1.2.0 vote.

On Wed, Mar 14, 2012 at 8:59 AM, Paul Davis <pa...@gmail.com> wrote:
> On Tue, Mar 13, 2012 at 8:27 PM, Noah Slater <ns...@tumbolia.org> wrote:
>> Thanks Dave.
>>
>> On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber <da...@muse.net.nz> wrote:
>>>
>>> What's the plan to move forwards here? We are damn close but a half
>>> finished solution for 1426 will
>>> simply mean another round. This needs more collaboration so that we
>>> are not working async on this.
>>>
>>
>> I don't think we are damn close.
>>
>> We've seen hardly any progress with this issue during the week and a half
>> since Benoît took ownership of it. That tells me that it can't be very
>> important, and so I will attempt another vote tomorrow, with or without it.
>>
>> If someone, anyone, wants to land a fix for it between now and then, be my
>> guest. But I will not hold the release up any longer for an issue that
>> nobody can be bothered to fix.
>>
>> (Not to discredit the work already put in to it. I really appreciate that.
>> Seriously, I do. But it's obviously not important enough to block the
>> release any longer, or it would've been fixed already. Actions speak louder
>> than words.)
>
> While I appreciate your enthusiasm, you appear to have not been
> following the issue very closely. There have been two versions of
> Benoit's initial work in the last week with multiple test reports [1].
> The current issue is that Dave has a machine that has a broken
> configuration. We need to figure out if we want to dig deeper into
> that or just assume that it's a broken configuration and thus outside
> our control. Once we have a decision there we can either commit
> Benoit's latest patch or fix it up to hack around that last edge case.
>
>
> [1] https://issues.apache.org/jira/browse/COUCHDB-1426



-- 
Iris Couch

Re: 1.2.0 status update

[Paul Davis <pa...@gmail.com>]

On Tue, Mar 13, 2012 at 8:27 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Thanks Dave.
>
> On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber <da...@muse.net.nz> wrote:
>>
>> What's the plan to move forwards here? We are damn close but a half
>> finished solution for 1426 will
>> simply mean another round. This needs more collaboration so that we
>> are not working async on this.
>>
>
> I don't think we are damn close.
>
> We've seen hardly any progress with this issue during the week and a half
> since Benoît took ownership of it. That tells me that it can't be very
> important, and so I will attempt another vote tomorrow, with or without it.
>
> If someone, anyone, wants to land a fix for it between now and then, be my
> guest. But I will not hold the release up any longer for an issue that
> nobody can be bothered to fix.
>
> (Not to discredit the work already put in to it. I really appreciate that.
> Seriously, I do. But it's obviously not important enough to block the
> release any longer, or it would've been fixed already. Actions speak louder
> than words.)

While I appreciate your enthusiasm, you appear to have not been
following the issue very closely. There have been two versions of
Benoit's initial work in the last week with multiple test reports [1].
The current issue is that Dave has a machine that has a broken
configuration. We need to figure out if we want to dig deeper into
that or just assume that it's a broken configuration and thus outside
our control. Once we have a decision there we can either commit
Benoit's latest patch or fix it up to hack around that last edge case.


[1] https://issues.apache.org/jira/browse/COUCHDB-1426

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Thanks Dave.

On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber <da...@muse.net.nz> wrote:
>
> What's the plan to move forwards here? We are damn close but a half
> finished solution for 1426 will
> simply mean another round. This needs more collaboration so that we
> are not working async on this.
>

I don't think we are damn close.

We've seen hardly any progress with this issue during the week and a half
since Benoît took ownership of it. That tells me that it can't be very
important, and so I will attempt another vote tomorrow, with or without it.

If someone, anyone, wants to land a fix for it between now and then, be my
guest. But I will not hold the release up any longer for an issue that
nobody can be bothered to fix.

(Not to discredit the work already put in to it. I really appreciate that.
Seriously, I do. But it's obviously not important enough to block the
release any longer, or it would've been fixed already. Actions speak louder
than words.)

Re: 1.2.0 status update

[Dave Cottlehuber <da...@muse.net.nz>]

Brief update from today.

etag_views issue emerged, Jan and Filipe sorted that out already & its
been committed.
Sorry; I was aware of it but didn't raise it as I wasn't sure it was
actually a couch issue.

Following that I got all etaps and futon tests passing on FF Aurora 12, running
Couch on Mac Lion and Linux Mint Debian Edition. If somebody can
confirm for ubuntu that
would be a help - any other OS reqd?

I slowly worked my up past gpg signing in the release procedure (all
good) but died at
the md5 stage due to md5sum not being installed. I can see why some of
this takes a while.

I am not clear whether the PMC have made a call on including
COUCHDB-1426 or not;
but either way we need to ensure we have:
- out of the box builds on most sensible platform default configurations
- a clear statement on how to build against a compatible SpiderMonkey
when the above doesn't apply.

>From what Benoît says, the current approach doesn't handle the latter,
so I think we need to complete
the patch.

What's the plan to move forwards here? We are damn close but a half
finished solution for 1426 will
simply mean another round. This needs more collaboration so that we
are not working async on this.

Can we organise enough people tomorrow evening (Euro time / daytime US
time) to nail this specific issue?
Or you can sort it while I sleep ;-)

A+
Dave


On 9 March 2012 21:30, Noah Slater <ns...@tumbolia.org> wrote:
> Cool. Please circle back here and let me know when I am good to call 1.2.0.
>
> We're waiting on you Paul. No pressure. ;)
>
> (Seriously, thanks!)
>
> On Fri, Mar 9, 2012 at 8:24 PM, Paul Davis <pa...@gmail.com>wrote:
>
>> Will review this as soon as I catch up on what happened on the
>> internet whilst I was sleeping.
>>
>> On Fri, Mar 9, 2012 at 8:53 AM, Benoit Chesneau <bc...@gmail.com>
>> wrote:
>> > On Fri, Mar 9, 2012 at 4:05 AM, Noah Slater <ns...@tumbolia.org>
>> wrote:
>> >> Woot, thanks.
>> >>
>> >> How's your stuff going, Benoît?
>> >
>> >
>> > Sorry have been distracted by some due work yesterday. I updated the
>> > ticket with a new version of the patch.
>> >
>> > Hopefully we aren't so far. I tested it in different scenarios and it
>> > worked. If anyone can review it that would help.
>> >
>> > - benoît
>>

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Cool. Please circle back here and let me know when I am good to call 1.2.0.

We're waiting on you Paul. No pressure. ;)

(Seriously, thanks!)

On Fri, Mar 9, 2012 at 8:24 PM, Paul Davis <pa...@gmail.com>wrote:

> Will review this as soon as I catch up on what happened on the
> internet whilst I was sleeping.
>
> On Fri, Mar 9, 2012 at 8:53 AM, Benoit Chesneau <bc...@gmail.com>
> wrote:
> > On Fri, Mar 9, 2012 at 4:05 AM, Noah Slater <ns...@tumbolia.org>
> wrote:
> >> Woot, thanks.
> >>
> >> How's your stuff going, Benoît?
> >
> >
> > Sorry have been distracted by some due work yesterday. I updated the
> > ticket with a new version of the patch.
> >
> > Hopefully we aren't so far. I tested it in different scenarios and it
> > worked. If anyone can review it that would help.
> >
> > - benoît
>

Re: 1.2.0 status update

[Paul Davis <pa...@gmail.com>]

Will review this as soon as I catch up on what happened on the
internet whilst I was sleeping.

On Fri, Mar 9, 2012 at 8:53 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Fri, Mar 9, 2012 at 4:05 AM, Noah Slater <ns...@tumbolia.org> wrote:
>> Woot, thanks.
>>
>> How's your stuff going, Benoît?
>
>
> Sorry have been distracted by some due work yesterday. I updated the
> ticket with a new version of the patch.
>
> Hopefully we aren't so far. I tested it in different scenarios and it
> worked. If anyone can review it that would help.
>
> - benoît

Re: 1.2.0 status update

[Benoit Chesneau <bc...@gmail.com>]

On Fri, Mar 9, 2012 at 4:05 AM, Noah Slater <ns...@tumbolia.org> wrote:
> Woot, thanks.
>
> How's your stuff going, Benoît?


Sorry have been distracted by some due work yesterday. I updated the
ticket with a new version of the patch.

Hopefully we aren't so far. I tested it in different scenarios and it
worked. If anyone can review it that would help.

- benoît

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Woot, thanks.

How's your stuff going, Benoît?


On 8 Mar 2012, at 21:18, Bob Dionne <di...@dionne-associates.com> wrote:

> checked in the sleep workaround that Jan confirms now works on the MINI with Filipes fix.
>
> On Mar 8, 2012, at 8:54 AM, Noah Slater wrote:
>
>> Thanks Bob. Do you think we'll have a fix by the weekend?
>>
>> On Thu, Mar 8, 2012 at 11:10 AM, Bob Dionne <di...@dionne-associates.com>wrote:
>>
>>> Still no root cause for 1424. We established that a small 100ms sleep
>>> solves the hanging problem on the MBA. One etap, 220-compaction-daemon..
>>> seemed to continue to cause a hang on the MINI, but that looks to be an
>>> interaction with the newest performance patch and that's been fixed. Jan
>>> will confirm on the MINI. Details are in JIRA
>>>
>>> My suspicion is that R15B is bringing out issues with how we shutdown
>>> things in couchdb, the hangs seem to always occur at the end of a given
>>> test, which explains why allowing etap:end_test() to wait a bit appears to
>>> clear it up completely.
>>>
>>> On Mar 8, 2012, at 5:55 AM, Noah Slater wrote:
>>>
>>>> Wow, cool. Thanks Bob, Filipe, and everyone who tested! :D
>>>>
>>>> Remaining issues:
>>>>
>>>> * Bob Dionne will driving COUCHDB-1424
>>>> * Benoît Chesneau will be driving COUCHDB-1426
>>>>
>>>> Guys?
>>>>
>>>> On Thu, Mar 8, 2012 at 10:19 AM, Robert Newson <rn...@apache.org>
>>> wrote:
>>>>
>>>>> Filipe's patch restores (and then exceeds) performance from before the
>>>>> regression, the explanation is lucid, and no contradictory results
>>>>> have been observed since, so I think that issue is closed now.
>>>>>
>>>>> B.
>>>>>
>>>>> On 8 March 2012 01:08, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>> Hey guys,
>>>>>>
>>>>>> What's the status of these items?
>>>>>>
>>>>>> On Sun, Mar 4, 2012 at 1:29 AM, Noah Slater <ns...@tumbolia.org>
>>>>> wrote:
>>>>>>
>>>>>>> Hey chaps,
>>>>>>>
>>>>>>> How are we doing on:
>>>>>>>
>>>>>>> * Bob Dionne will driving COUCHDB-1424
>>>>>>> * Benoît Chesneau will be driving COUCHDB-1426
>>>>>>> * Robert Newson will be driving the performance work
>>>>>>>
>>>>>>> The R15B patch has been committed already.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> N
>>>>>>>
>>>>>
>>>
>>>
>

Re: 1.2.0 status update

[Bob Dionne <di...@dionne-associates.com>]

checked in the sleep workaround that Jan confirms now works on the MINI with Filipes fix. 

On Mar 8, 2012, at 8:54 AM, Noah Slater wrote:

> Thanks Bob. Do you think we'll have a fix by the weekend?
> 
> On Thu, Mar 8, 2012 at 11:10 AM, Bob Dionne <di...@dionne-associates.com>wrote:
> 
>> Still no root cause for 1424. We established that a small 100ms sleep
>> solves the hanging problem on the MBA. One etap, 220-compaction-daemon..
>> seemed to continue to cause a hang on the MINI, but that looks to be an
>> interaction with the newest performance patch and that's been fixed. Jan
>> will confirm on the MINI. Details are in JIRA
>> 
>> My suspicion is that R15B is bringing out issues with how we shutdown
>> things in couchdb, the hangs seem to always occur at the end of a given
>> test, which explains why allowing etap:end_test() to wait a bit appears to
>> clear it up completely.
>> 
>> On Mar 8, 2012, at 5:55 AM, Noah Slater wrote:
>> 
>>> Wow, cool. Thanks Bob, Filipe, and everyone who tested! :D
>>> 
>>> Remaining issues:
>>> 
>>> * Bob Dionne will driving COUCHDB-1424
>>> * Benoît Chesneau will be driving COUCHDB-1426
>>> 
>>> Guys?
>>> 
>>> On Thu, Mar 8, 2012 at 10:19 AM, Robert Newson <rn...@apache.org>
>> wrote:
>>> 
>>>> Filipe's patch restores (and then exceeds) performance from before the
>>>> regression, the explanation is lucid, and no contradictory results
>>>> have been observed since, so I think that issue is closed now.
>>>> 
>>>> B.
>>>> 
>>>> On 8 March 2012 01:08, Noah Slater <ns...@tumbolia.org> wrote:
>>>>> Hey guys,
>>>>> 
>>>>> What's the status of these items?
>>>>> 
>>>>> On Sun, Mar 4, 2012 at 1:29 AM, Noah Slater <ns...@tumbolia.org>
>>>> wrote:
>>>>> 
>>>>>> Hey chaps,
>>>>>> 
>>>>>> How are we doing on:
>>>>>> 
>>>>>> * Bob Dionne will driving COUCHDB-1424
>>>>>> * Benoît Chesneau will be driving COUCHDB-1426
>>>>>> * Robert Newson will be driving the performance work
>>>>>> 
>>>>>> The R15B patch has been committed already.
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> N
>>>>>> 
>>>> 
>> 
>> 

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Thanks Bob. Do you think we'll have a fix by the weekend?

On Thu, Mar 8, 2012 at 11:10 AM, Bob Dionne <di...@dionne-associates.com>wrote:

> Still no root cause for 1424. We established that a small 100ms sleep
> solves the hanging problem on the MBA. One etap, 220-compaction-daemon..
>  seemed to continue to cause a hang on the MINI, but that looks to be an
> interaction with the newest performance patch and that's been fixed. Jan
> will confirm on the MINI. Details are in JIRA
>
> My suspicion is that R15B is bringing out issues with how we shutdown
> things in couchdb, the hangs seem to always occur at the end of a given
> test, which explains why allowing etap:end_test() to wait a bit appears to
> clear it up completely.
>
> On Mar 8, 2012, at 5:55 AM, Noah Slater wrote:
>
> > Wow, cool. Thanks Bob, Filipe, and everyone who tested! :D
> >
> > Remaining issues:
> >
> > * Bob Dionne will driving COUCHDB-1424
> > * Benoît Chesneau will be driving COUCHDB-1426
> >
> > Guys?
> >
> > On Thu, Mar 8, 2012 at 10:19 AM, Robert Newson <rn...@apache.org>
> wrote:
> >
> >> Filipe's patch restores (and then exceeds) performance from before the
> >> regression, the explanation is lucid, and no contradictory results
> >> have been observed since, so I think that issue is closed now.
> >>
> >> B.
> >>
> >> On 8 March 2012 01:08, Noah Slater <ns...@tumbolia.org> wrote:
> >>> Hey guys,
> >>>
> >>> What's the status of these items?
> >>>
> >>> On Sun, Mar 4, 2012 at 1:29 AM, Noah Slater <ns...@tumbolia.org>
> >> wrote:
> >>>
> >>>> Hey chaps,
> >>>>
> >>>> How are we doing on:
> >>>>
> >>>> * Bob Dionne will driving COUCHDB-1424
> >>>> * Benoît Chesneau will be driving COUCHDB-1426
> >>>> * Robert Newson will be driving the performance work
> >>>>
> >>>> The R15B patch has been committed already.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> N
> >>>>
> >>
>
>

Re: 1.2.0 status update

[Bob Dionne <di...@dionne-associates.com>]

Still no root cause for 1424. We established that a small 100ms sleep solves the hanging problem on the MBA. One etap, 220-compaction-daemon..  seemed to continue to cause a hang on the MINI, but that looks to be an interaction with the newest performance patch and that's been fixed. Jan will confirm on the MINI. Details are in JIRA

My suspicion is that R15B is bringing out issues with how we shutdown things in couchdb, the hangs seem to always occur at the end of a given test, which explains why allowing etap:end_test() to wait a bit appears to clear it up completely.

On Mar 8, 2012, at 5:55 AM, Noah Slater wrote:

> Wow, cool. Thanks Bob, Filipe, and everyone who tested! :D
> 
> Remaining issues:
> 
> * Bob Dionne will driving COUCHDB-1424
> * Benoît Chesneau will be driving COUCHDB-1426
> 
> Guys?
> 
> On Thu, Mar 8, 2012 at 10:19 AM, Robert Newson <rn...@apache.org> wrote:
> 
>> Filipe's patch restores (and then exceeds) performance from before the
>> regression, the explanation is lucid, and no contradictory results
>> have been observed since, so I think that issue is closed now.
>> 
>> B.
>> 
>> On 8 March 2012 01:08, Noah Slater <ns...@tumbolia.org> wrote:
>>> Hey guys,
>>> 
>>> What's the status of these items?
>>> 
>>> On Sun, Mar 4, 2012 at 1:29 AM, Noah Slater <ns...@tumbolia.org>
>> wrote:
>>> 
>>>> Hey chaps,
>>>> 
>>>> How are we doing on:
>>>> 
>>>> * Bob Dionne will driving COUCHDB-1424
>>>> * Benoît Chesneau will be driving COUCHDB-1426
>>>> * Robert Newson will be driving the performance work
>>>> 
>>>> The R15B patch has been committed already.
>>>> 
>>>> Thanks!
>>>> 
>>>> N
>>>> 
>> 

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Thanks Benoît. Please let me know if you want a patch review.

On Thu, Mar 8, 2012 at 11:23 AM, Benoit Chesneau <bc...@gmail.com>wrote:

> On Thu, Mar 8, 2012 at 2:55 AM, Noah Slater <ns...@tumbolia.org> wrote:
>
> > * Benoît Chesneau will be driving COUCHDB-1426
>
> I have a patch coming today or tomorrow depends on the TZ you live.
> Hopefully we can close it this week-end.
>
> - benoît
>

Re: 1.2.0 status update

[Benoit Chesneau <bc...@gmail.com>]

On Thu, Mar 8, 2012 at 2:55 AM, Noah Slater <ns...@tumbolia.org> wrote:

> * Benoît Chesneau will be driving COUCHDB-1426

I have a patch coming today or tomorrow depends on the TZ you live.
Hopefully we can close it this week-end.

- benoît

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Wow, cool. Thanks Bob, Filipe, and everyone who tested! :D

Remaining issues:

* Bob Dionne will driving COUCHDB-1424
* Benoît Chesneau will be driving COUCHDB-1426

Guys?

On Thu, Mar 8, 2012 at 10:19 AM, Robert Newson <rn...@apache.org> wrote:

> Filipe's patch restores (and then exceeds) performance from before the
> regression, the explanation is lucid, and no contradictory results
> have been observed since, so I think that issue is closed now.
>
> B.
>
> On 8 March 2012 01:08, Noah Slater <ns...@tumbolia.org> wrote:
> > Hey guys,
> >
> > What's the status of these items?
> >
> > On Sun, Mar 4, 2012 at 1:29 AM, Noah Slater <ns...@tumbolia.org>
> wrote:
> >
> >> Hey chaps,
> >>
> >> How are we doing on:
> >>
> >> * Bob Dionne will driving COUCHDB-1424
> >> * Benoît Chesneau will be driving COUCHDB-1426
> >> * Robert Newson will be driving the performance work
> >>
> >> The R15B patch has been committed already.
> >>
> >> Thanks!
> >>
> >> N
> >>
>

Re: 1.2.0 status update

[Robert Newson <rn...@apache.org>]

Filipe's patch restores (and then exceeds) performance from before the
regression, the explanation is lucid, and no contradictory results
have been observed since, so I think that issue is closed now.

B.

On 8 March 2012 01:08, Noah Slater <ns...@tumbolia.org> wrote:
> Hey guys,
>
> What's the status of these items?
>
> On Sun, Mar 4, 2012 at 1:29 AM, Noah Slater <ns...@tumbolia.org> wrote:
>
>> Hey chaps,
>>
>> How are we doing on:
>>
>> * Bob Dionne will driving COUCHDB-1424
>> * Benoît Chesneau will be driving COUCHDB-1426
>> * Robert Newson will be driving the performance work
>>
>> The R15B patch has been committed already.
>>
>> Thanks!
>>
>> N
>>

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Hey guys,

What's the status of these items?

On Sun, Mar 4, 2012 at 1:29 AM, Noah Slater <ns...@tumbolia.org> wrote:

> Hey chaps,
>
> How are we doing on:
>
> * Bob Dionne will driving COUCHDB-1424
> * Benoît Chesneau will be driving COUCHDB-1426
> * Robert Newson will be driving the performance work
>
> The R15B patch has been committed already.
>
> Thanks!
>
> N
>

Re: 1.2.0 status update

[Noah Slater <ns...@tumbolia.org>]

Thanks Bob. I was unable to replicate this in the first instance! :)

On Sun, Mar 4, 2012 at 12:05 PM, Bob Dionne <di...@dionne-associates.com>wrote:

> Noah,
>
> I reported my findings on 1424 in the jira ticket. It looks like a simple
> sleep in etap:end_tests() fixes it. I'm waiting for others to confirm that,
> perhaps you can also try it on your setup.
>
> Cheers,
>
> Bob
> On Mar 3, 2012, at 8:29 PM, Noah Slater wrote:
>
> > Hey chaps,
> >
> > How are we doing on:
> >
> > * Bob Dionne will driving COUCHDB-1424
> > * Benoît Chesneau will be driving COUCHDB-1426
> > * Robert Newson will be driving the performance work
> >
> > The R15B patch has been committed already.
> >
> > Thanks!
> >
> > N
>
>

Re: 1.2.0 status update

[Bob Dionne <di...@dionne-associates.com>]

Noah,

I reported my findings on 1424 in the jira ticket. It looks like a simple sleep in etap:end_tests() fixes it. I'm waiting for others to confirm that, perhaps you can also try it on your setup.

Cheers,

Bob
On Mar 3, 2012, at 8:29 PM, Noah Slater wrote:

> Hey chaps,
> 
> How are we doing on:
> 
> * Bob Dionne will driving COUCHDB-1424
> * Benoît Chesneau will be driving COUCHDB-1426
> * Robert Newson will be driving the performance work
> 
> The R15B patch has been committed already.
> 
> Thanks!
> 
> N