Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAPaJBx61wwDLv4Oe6ZspW9W+_fcDL3YTZhvfARcbdeEG=r8C+w@mail.gmail.com>
References: 
 <CAPaJBx47G5-chL44Fh_cvSFyPrw9aNsqmUrwLexrhsQHA3eKZw@mail.gmail.com>
	<CAKmKYaCRAXh__=njRKDQF+9oCjFF_gZ5TQucRAsaZ7xr6koY_w@mail.gmail.com>
	<CAPaJBx61wwDLv4Oe6ZspW9W+_fcDL3YTZhvfARcbdeEG=r8C+w@mail.gmail.com>
Date: Wed, 7 Aug 2013 19:54:35 +0100
Message-ID: 
 <CAFUSCh9kvho1msFszg6H1t4FOLdcUFVc27jgaUjBe=rEXh=Tfw@mail.gmail.com>
Subject: Re: Do we release src/fauxton?
From: Russell Branca <chewbranca@apache.org>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=089e0158ae3898275d04e36012fa

--089e0158ae3898275d04e36012fa
Content-Type: text/plain; charset=ISO-8859-1

We merged Fauxton into master for two reasons, 1) it was functionally
working and in a place where we've kept it in a working state, and 2) the
branches had diverged by 6 or 7 months and was becoming unwieldily.

The primary motivation for not including Fauxton in 1.4 is that we're only
a few weeks from having the new UI in place (see COUCHDB-1829 and Sue's
branch), and I think we should wait to ship until we've got everything in
place. It's not "unshippable", I just think we should get it right the
first time.


-Russell


On Wed, Aug 7, 2013 at 6:04 PM, Noah Slater <nslater@apache.org> wrote:

> As Jan points out. This is an odd situation to end up in. But we can still
> clean it up properly. :)
>
> Dirkjan, as the release manager for 1.4.0, you should consider yourself
> deputised to make the call on this. If you think that fauxton isn't
> shippable, then that is fine, but we should back it out of master, and
> recut the 1.4.x branch.
>
> On IRC you mentioned that removing it from the 1.4.x branch was a shortcut.
> I'm all for process shortcuts, but in this instance, it's not a shortcut.
> Because the actual problem turns out to be that our release manager thinks
> master contains unshippable code.
>
> Which is fine. Your call. :) But we need to clean this mess up properly.
> Which means moving it to a feature branch.
>
>
> On 7 August 2013 17:59, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
>
> > On Wed, Aug 7, 2013 at 6:44 PM, Noah Slater <nslater@apache.org> wrote:
> > > But this leaves us in a bit of a pickle, because the code is on master.
> > And
> > > part of our agreed-upon-but-not-documented Git workflow is that master
> is
> > > always shippable.
> > >
> > > Another part of our agreed-upon-but-not-documented Git workflow is that
> > > major and minor releases are cut from master, or a new release branch
> > that
> > > mirrors master.
> >
> > This is still weird for me, but it is what we agreed to.
> >
> > > Dirkjan has removed src/fauxton from the 1.4.x, which was recently cut
> > from
> > > master. But this, to me, is a problem. It breaks the Git workflow
> > agreement.
> > >
> > > Because now, we're implicitly saying that master is not shippable.
> > Because
> > > we had to cut from it, and then remove a thing that we didn't want to
> > ship.
> > >
> > > Dirkjan thinks this is unimportant. Because you could just remove
> > > src/fauxton from master, cut the 1.4.x branch, and then add it back a
> few
> > > seconds later and say "this is for 1.5.x". And the Git workflow
> agreement
> > > wouldn't be broken.
> >
> > Saying I think this is important is cutting it short a little. :) I do
> > see a difference between the process we want and the outcome we want.
> > If the process has gone off the path we wanted for some reason, I
> > don't agree we have to backtrace all the way to where we went wrong
> > and move forward again to do it right. Instead, I think we can take a
> > shortcut to make sure we get the outcome we want, and try to be better
> > about our processes going forward.
> >
> > > But I think he's wrong, because the agreement is that master is always
> > > shippable. So you couldn't just add fauxton back. Because we've just
> said
> > > fauxton is not shippable.
> > >
> > > So what I actually think Dirkjan is saying is that src/fauxon should be
> > on
> > > a feature branch, and not on master. And if that's the case, then fine,
> > but
> > > we need to actually do that. We shouldn't leave it on master, and just
> > > remove it by hand from any release branches we cut in the meantime.
> > That's
> > > sloppy, and it messes with the Git workflow promise we've agreed to but
> > not
> > > documented.
> > >
> > > So, I actually think there are two perspectives here:
> > >
> > > 1) Master is shippable. It doesn't matter that the fauxton code is on
> it,
> > > because it doesn't effect the user. (Garren has confirmed this for me.)
> > If
> > > this is your perspective, then we fix up the Makefile on master, cut
> > 1.4.x
> > > master again, and we ship with the fauxton code in the tarball.
> > >
> > > 2) Master is not shippable. The fauxton code should be removed, and
> only
> > > merged back in once we're happy with it being shipped. (Where being
> > shipped
> > > means being included in the tarball, even if it's not activated, or
> > visible
> > > for users.) In which case, remove it, put it back on a branch. Then cut
> > > 1.4.x master again, and we ship 1.4.0 without any of the fauxton code.
> > >
> > > I am happy with both options. I think I prefer (1), but if someone
> wants
> > to
> > > go to the effort of (2), then I am okay with that too.
> >
> > Okay, so I think shipping gobs of code that aren't wired up to
> > anything and have been expressly declared not ready for shipping is
> > wrong. We effectively put this whole directory of stuff in the tarball
> > that's known not to be functional or, in any case, good enough to
> > release as something that's accessible to users... that's pretty crazy
> > to me.
> >
> > So, I prefer (2). But, my point is that it should be fine to take a
> > really pretty small shortcut to get there from the current state of
> > we-did-something-wrong-a-few-weeks-ago.
> >
> > > What I'm not okay with, however, is breaking our
> > > agreed-upon-but-not-documented Git workflow that says that master is
> > always
> > > shippable, and that major and minor releases branches are cut from
> > master.
> > > (And yep, of course, we make changes to the release branches. But these
> > > should be very minimal, and/or backports.)
> >
> > I argue that the workflow was already broken before I did anything
> > today, because Fauxton wasn't shippable (in any meaningful sense, i.e.
> > other than including the code in the tarball). And so we need some
> > kind of process to clean that up.
> >
> > Cheers,
> >
> > Dirkjan
> >
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>

--089e0158ae3898275d04e36012fa--