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: 
 <CAKmKYaCRAXh__=njRKDQF+9oCjFF_gZ5TQucRAsaZ7xr6koY_w@mail.gmail.com>
References: 
 <CAPaJBx47G5-chL44Fh_cvSFyPrw9aNsqmUrwLexrhsQHA3eKZw@mail.gmail.com>
	<CAKmKYaCRAXh__=njRKDQF+9oCjFF_gZ5TQucRAsaZ7xr6koY_w@mail.gmail.com>
Date: Wed, 7 Aug 2013 18:04:07 +0100
Message-ID: 
 <CAPaJBx61wwDLv4Oe6ZspW9W+_fcDL3YTZhvfARcbdeEG=r8C+w@mail.gmail.com>
Subject: Re: Do we release src/fauxton?
From: Noah Slater <nslater@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=089e0102dee89268f404e35e87f6

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

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

--089e0102dee89268f404e35e87f6--