On Dec 8, 2007 10:25 AM, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> I've been making a lot of noise lately about releasing 1.4.6. The
> reason is that I feel that our users deserve the fixes we've made since
> 1.4.4, some of which are fixes for data corruption bugs. I know people
> are working on 1.5, but we have gone far too long without even a patch
> release of 1.4.x. (1.4.5 doesn't count, as it only had one security fix.)
>
> We need a system which gets bug-fixes into the hands of our users
> quicker. The idea is similar to attracting new committers: if we act
> reasonably quickly on patch submissions, we are likely to continue to
> see patches. If we release bug fixes quickly, we are likely to see more
> bug reports, which is a Good Thing.
>
> So the proposal[1] is this: patch releases every two months, regardless
> of the number of bugs fixed for the release. (If nothing in STATUS has
> been approved in the two month window, we'd just skip that release.)
> Having such a policy would take the guess work out of when to do a patch
> release, give people deadlines for reviews of STATUS, and get bug fixes
> into the hands of our users quickly.
>
> The only downsides I see to this proposal are associated with the
> overhead in creating a release. One is that the RM would have more
> work, and I'll volunteer to help share in that role if needed. The
> other is the increased testing and signing role of committers. I think
> both of these can be mitigated with more automation, and neither are
> serious impediments to time-based patch releases.
-0 (assuming that means I am against this but not enough to block it)
This is a solution in search of a problem. I have never, ever, heard
users complaining that we do not have enough a patch releases. Ever.
The only people that talk about this are committers, and perhaps a few
of the people that submit patches. None of those people probably even
use our official releases and they are certainly capable of applying
patches that they need.
We should create patch releases because of the nature of the fixes
that have been made since the last one. Producing these releases
creates a ton of work, not just for our committers (which is
considerable) but for all of the downstream maintainers. I personally
experience this as a maintainer for Subclipse and also for the
CollabNet Subversion packages. The last thing I want is a release
every two months. I could live with every four months, but am against
anything based on time and not content.
If we cannot drum up enough people to get a release out when it is
based on the content of the release, how do you expect to do it if it
is based on the calendar? Who is going to want to do all this work
when all that has been backported is some trivial fix that no one
really cares about?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 8 17:53:40 2007