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
