couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Do we release src/fauxton?
Date Wed, 07 Aug 2013 21:28:04 GMT
>From what I understand, Dirkjan will be on vacation for 10 days. Nobody
else has indicated that they intend to do the release. So perhaps that's
enough of a window?


On 7 August 2013 21:08, Russell Branca <chewbranca@apache.org> wrote:

> Yay! Sue just made a PR for the UI updates:
> https://github.com/apache/couchdb/pull/77
>
> Depending on the timeline of 1.4, I would not be opposed to shipping
> Fauxton in the release with the new UI, but we should get a solid week or
> two of people QA-ing it first.
>
>
> -Russell
>
>
> On Wed, Aug 7, 2013 at 8:51 PM, Dave Cottlehuber <dch@jsonified.com>
> wrote:
>
> > Weird googleness, this time with comments.
> >
> > On 7 August 2013 18:59, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
> > > 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.
> >
> > Nicely put.
> >
> > > 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.
> >
> > +1 optimise for sanity.
> >
> > >> 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.
> >
> > +0.8 -- this is the way I see it. Feel free to shoot me down but I am
> > not fussed if we have code that is not directly user-accessible that's
> > included in a release. Although we shouldn't make a habit of it.
> >
> > >> 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.
> >
> > Agree, however I think we crossed the fauxtonic rubicon a while back,
> > I'd rather not force a huge merge later on for the sake of git branch
> > purity. We have a merry circus of merges this year and one less branch
> > of this magnitude is a Good Thing.
> >
> > > 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.
> >
> > I'm ok with whatever the RM decides is appropriate. No point in
> > handing out a pointy hat if you can't wear it at maximal pointiness.
> > Ultimately we are in a messy situation and I'd go for whatever is Most
> > Relaxing, ie takes the least effort to sort out.
> >
> > Finally, it seems like 1.4 is a good line in the sand to draw about
> > sticking to a branch workflow. I'll bring myself up to date and then
> > try and write it all up this week.
> >
> > A+
> > Dave
> >
>



-- 
Noah Slater
https://twitter.com/nslater

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