On 4/25/10 4:10 PM, Shai Erera wrote:
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.
Right.
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.
I still don't like "just seeing what happens". What we all agree should
be best for users as well as devs is not always going to be in alignment
with letting the chips fall where they may. I don't think seeing whether
committers just do something individually/naturally is a good test for
whether we have the right goals for the project.
Deciding if we should have the back compat police is not something we
would do by saying "Okay, no more back compat policy - lets just see if
devs do back compat on there own or not - if they do, we bring back back
compat". Natural inclinations and unofficial 'policy' are two very
different things - and I think both are important. Natural inclination
doesn't sound exactly like the right test for official/unofficial/loose
policies that are meant to guide natural inclinations. Despite Roberts
complaining, we don't have many, but we do have some - without our back
compat policy, upgrading code that extensively uses Lucene would have
been extremely difficult. When you are avoiding deprecation, and
deprecation releases and increasing the number and size of complicated
changes, you make upgrading more and more difficult. 2.9 to 3.0 was
already no cakewalk, but if you did it right, Lucene walks you right
through all the changes you need to grapple with, and points you along
the path. This will all essentially go away. The least we can do is
provide solid stable releases, and are informally dedicated to doing
such - by putting all dev that fits into stable.
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.
I'm totally against this whole "request" idea. Things that make sense to
go to stable should go to both. Things that make sense to go to unstable
should go there. Some people I think put dev annoyances over a good user
experience - personally I think their should be more of a balance.
What's easy for devs is not always easy for users - otherwise this would
have been a free for all from the beginning. We would have done away
with all of the 'burdens', 'annoyances', and 'tediousness'. And just
shoved them off to users that where trying to upgrade their code to use
the latest Lucene. The two need to be balanced.
As Mark indicated, the current back-compat policy was never voted on.
Instead it made sense and thus was applied. Maybe we're wrong :)?
No we where not wrong. That back compat policy has worked out for a long
time. Evolving policy is going to be natural as the situation changes.
That doesn't mean it should evolve to nothing or anything just because
its changing. And the current back compat policy was not officially
voted on (which only the PMC can do), but it was voted on with action
over time. Same as its been loosened over time.
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 …
But I don't agree that the path you want is the right path. So why be
"bold" about it?
What would be "confusing to the people"?
How is this the process we currently use? The current process is that
bugs that should be back ported are back ported. Sometimes their are
requests for further back ports, but the general policy is to back port
what makes sense, not what is requested. And that's been being done for
some time.
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
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
