I think that we agree in principal about the policy change. We seem to disagree only on where should the default dev should be: trunk or branch.
So why not put it up to the test? Let's declare that all dev happens on trunk. If few features are backported - then it means (probably) that there is not much interest in backporting. If many features are backported, it means not only people want to backport, but also committers are willing to help do that. Feels to me like a win-win situation for both arguments. So instead of being strict right from the start, we try to be more agile and responsive. We don't unnecessarily burden the committers with the tedious job of merging svn every time, but instead verify first that what we think is requested by the people, actually is requested. As Mark indicated, the current back-compat policy was never voted on. Instead it made sense and thus was applied. Maybe we're wrong :)? Let's be bold, do some change and then reflect back on it and decide if it was smart or not. It's not like the process is irreversible - on the contrary, what I'm suggesting is essentially what's done today (svn-wise) and thus can easily be changed in the future. While if we start w/ Mike's proposal, changing it would be more confusing to the people, and will probably also generate such a huge thread … Shai On Sunday, April 25, 2010, Mark Miller <markrmil...@gmail.com> wrote: > On 4/25/10 1:43 PM, Michael McCandless wrote: > > > Changes that go into stable need to be merged to unstable, maybe > periodically sweeped or maybe merged up by the original committer or > likely some combination (like flex). > > (And, yes we'll still use other branches for big new features that are > in active development). > > Mike > > > > I'm still +1 on all the proposals you have made. And still -1 to most of the > attempted tweaks on them that have been proposed :) > > -- > - Mark > > http://www.lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
