I hate straddling the middle ground, because it seems so wishy-washy,
but I think Greg Stein's got a point, just not as strong a point as he
would have it.
We don't need to completely shut down all non-0.35 commits on trunk.
But we do need to get somewhat stricter than we have been.
Can we agree that until we branch, it's fine to commit riskless things
like error message fixes, comment fixes, and null checks (where the
thing *definitely* shouldn't be null)... but that larger changes such
as the recent wc access baton thing, or Tobias's SSL auth work, should
only be done if they bring a large benefit, and even then need three
+1's from full committers to go in?
Like Greg, I'm not complaining about a specific commit, just trying to
foster a general attitude. We should be treating the trunk carefully
at this point, even though we're not officially branched, because
after all anything that goes into trunk now is going to be in the
1.0-stabilization branch. I don't think Tobias's commit should be
reverted, and obviously Julian was acting in good faith. Just from
this point on, let's please be more conservative.
We definitely need to lose the attitude of "Gotta cram this new UI
into the trunk before the 1.0 branch, so it's Right for 1.0." There
will still have to be UI improvements after 1.0 no matter what, we
need to accept that.
So that's where I sit, somewhere between Greg and Greg :-).
Regarding Mike Pilato's proposed fix for issue #1093: that would be a
prime candidate for the three +1's. Suggest that we use the issue
tracker for recording votes (and if a proposed patch doesn't have an
issue, then it needs to get one).
-Karl
Greg Stein <gstein@lyra.org> writes:
> Part of the problem here is that it is *very* hard to say "don't commit".
> That implies a certain amount of "I have more say in the project, and I
> can tell you what to do." Even supposing that that right is conferred on
> the "core team" (as you put it) by the community, I would posit that they
> would be quite uncomfortable exercising that right.
>
> Instead, I believe it is more about individual developers making the
> decision themselves. Over the past few years, and I believe moving
> forward, this has worked very well. We all share a very strong notion of
> what 1.0 is all about, and have been able to focus on that goal. ("make
> SVN's feature set on par with CVS, and grab low hanging fruit to make it
> better") I think there are very different ideas on how to approach the
> end game, though. We know that 1.0 is "almost there" but don't quite agree
> on how to get that last 1% :-)
>
> I intended no slight towards you or Julian. I'm concerned about the
> pattern rather than the specifics.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 16:44:02 2003