>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 <chewbra...@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 <d...@jsonified.com> > wrote: > > > Weird googleness, this time with comments. > > > > On 7 August 2013 18:59, Dirkjan Ochtman <dirk...@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
