couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Branca <chewbra...@apache.org>
Subject Re: Do we release src/fauxton?
Date Wed, 07 Aug 2013 20:08:51 GMT
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
>

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