couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: 1.2.0 status update
Date Thu, 15 Mar 2012 02:04:30 GMT
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 <paul.joseph.davis@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 <nslater@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 <wendallc@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<jhs@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
> >>>
> >>
> >>
>

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