On 9/12/2013 12:57 PM, Robert Muir wrote: >> I superficially agree that trunk is a better place to do larger and >> potentially less stable changes, but I think the problem is that it seems >> that trunk is too far away from the stable branch and it just seems more >> productive to "iterate" on both in parallel rather than do a lot of >> iterating on trunk and then have to recreate a long iteration sequence on >> the stable branch. The faster code gets into the stable branch, the faster >> and more thoroughly people will test it out. >> > > This is what i cant stand: its not the purpose of a stable branch.
I'm fairly new to the behind-the-scenes work, so I don't have a lot of experience yet. I've put on my peril-sensitive sunglasses for the flames headed my way. (: Here's my two (American) cents: I can say from my short time as a committer that things change pretty fast. I've seen conflicts arise in my patches after only a day or two. Usually it isn't mass code reformatting, either. I accept that this is a reality, so if I can't complete my work quickly and get it committed, I know that I might need to start over. If a change bakes in trunk for any real time before it gets applied to the stable branch, there's a very good chance that there will be manual conflict resolution when trying to merge it. That problem is much worse if there are several trunk commits to merge instead of one. I'm probably not alone in thinking that if I've got to deal with dozens of manual conflict fixes on stable every time I merge a change that isn't trivial, there will be much frustration. For changes that hit a lot of code (whether they are huge paradigm shifts or not), a completely separate branch is best, so that when it finishes baking, it can be applied to trunk and stable at the same time. Everyone does their best to not break the stable branch, but expecting it to be releasable at any moment without at least a few days for stabilization (before the final vote) is rather unrealistic. I've broken it myself with changes that seemed completely innocent at the time. As long as nobody has declared an imminent release, IMHO iterating on a big change to fix problems is usually better than baking the change in trunk and perhaps making a mistake while merging the trunk commits and fixing conflicts. The manual conflict resolution problem is inevitable as trunk and stable diverge from each other, even for single-commit merges with no baking time. IMHO when that becomes commonplace, it's a good indicator that it's time to wrap things up, branch the next major version, and start working on the -ALPHA release. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
