#1 would be nice. I would discourage the cherry-pick-back-from-master model because it completely disregards git's history model and makes auditing changes nearly impossible because for N patches, the same change exists N times under different IDs. If we wanted that, we'd be back to subversion without mergeinfo.
#2 and #3 is possible now with our branching strategy. Is there some deficiency you notice with it? While we're a big project, I think we might be able to benefit from a review-then-commit process. It could allow us to review any patch to master, and if we determine it is relevant in historical branches, we commit it to the historical branch and then merge forward before publishing to our public history. On Tue, Oct 7, 2014 at 1:12 AM, Sean Busbey <bus...@cloudera.com> wrote: > What if we start with what we want and work from there, instead of starting > from our current model. > > I would really like: > > 1) A *single* place where new contributors can base patches > > 2) Stable planned release lines where a release manager can determine what > does or does not get included > > 3) a git history that makes it easy for me to tell what jiras impact a > given release tag > > One way to achieve these goals is to adopt a commit-to-master and > cherry-pick approach. > > * Master would be the default landing zone for new commits (unless they > only apply to an older branch). > * Master would have a version that represents unstable "future work" (so > right now presumably 3.0 if Christopher wants to start solidifying 2.0) > * We'd have a branch for each current dev branches > * When a fix applies to an older branch a committer (and usually not a > contributor) would cherry pick it from master > * When the release manager for a new version was ready to start stabilizing > things they'd make a new branch > * Said release manager would determine what feature changes in master get > pulled back to the new major release > > The big disadvantage with this approach is that in the event that there is > a bad commit `git bisect` will only find it on a single development branch. > On the plus side, the lack of merge commits means that it's easier to > revert. > > On Mon, Oct 6, 2014 at 10:41 PM, Christopher <ctubb...@apache.org> wrote: > > > True. Everything I'm thinking of would work with no master, but that > might > > be confusing, and might break some tooling without extra effort (which > > branch is default when cloning?). We also kind of assume that the master > > branch is forward-moving only, but other branches are disposable and can > be > > rebase'd, deleted, re-created, etc. > > > > Alternatively, if people understood that a "2.0" branch is a "future" > > branch when 1.7 (master) is the "current", that'd work, too... I just > worry > > that people will merge it poorly. > > > > I suppose the best option, then, is probably to keep the status quo, and > > use a branch name like "ACCUMULO-####" which represents the overall work > > for a particular future release plan, instead of a name which looks like > a > > maintenance branch. > > > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > On Mon, Oct 6, 2014 at 10:59 PM, William Slacum < > > wilhelm.von.cl...@accumulo.net> wrote: > > > > > It seems to me you can get everything you want by merely getting rid of > > > master or making master just be the 1.7 branch. I'm not really > concerned > > > about the name, because it's easy enough to figure out. Master > > duplicating > > > a tag doesn't really seem useful to me, save for "here's the highest > > > version we have released", which is of limited utility when a user can > > just > > > check the tags. I don't see the point in having master be something for > > the > > > sake of having master. > > > > > > > > > > > > On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <josh.el...@gmail.com> > wrote: > > > > > > > Christopher wrote: > > > > > > > >> What purpose does the master branch serve if it's just the same as > the > > > >>> last > > > >>> > major release tag? > > > >>> > > > > >>> > > > > >>> > > > >> I think Josh had some specific opinions on this, but the general > idea > > > from > > > >> what I understood was that master is supposed to be stable... > > > >> representative of the latest, most modern release, because it's > what a > > > new > > > >> contributor would expect to fork to create a patch. That's hard to > do > > if > > > >> the goalpost is moving a lot, and it makes feature merges more > > > >> complicated, > > > >> since contributors have to rebase or merge themselves in order to > > > create a > > > >> patch that merges cleanly. Having a stable master makes it very easy > > to > > > >> contribute to the most recent release. > > > >> > > > > > > > > No, I don't really care for a stable-only master (I think I diverge > > from > > > > the git-flow model in that regard). I like master to just be a > > > > "commits-go-here" area more than anything. > > > > > > > > > > > > > -- > Sean >
