Mark Phippard wrote:
> 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.
Thanks for bringing this to the list Hyrum.
Given Mark's concerns I think we need to separate the reason for this
proposal from the actual proposal. Mine was a bit different than yours
actually.
I'm going to follow a 'things to keep', 'things to improve' ->
'proposal' approach.
From the current situation, things I'd like to keep:
- For the important issues, we're doing a good job fixing them. Often it
happens that a user reports an issue and it's fixed the same day.
- Our means to delivery fixes to the user is with maintenance releases
combining multiple fixes.
- Advanced users and package maintainers can take patches from our
maintenance branch, apply them individually and basically make their own
maintenance releases.
- The majority of our user base is not capable of doing that, and just
uses our official blessed releases.
Things I'd like to see improved:
- I'd like to see us deliver releases with less issues. This is IMO the
main thing to work on, ideally we'd never have to fix issues at all.
- We often get reports on users for issues that have already been
solved, either on trunk or on a maintenance release, but not yet released.
- I often find myself explaining 'my' users that a certain issue they're
encountering will be solved in version x.y.z so they have to wait a bit.
- Since we do not plan maintenance releases, nor our users nor the
package maintainers can prepare for such releases.
- While we do a good job fixing issues, most of our users have to wait
for weeks or months before they are actually seeing those fixes.
From our 1.4.6 list of changes, I'll use an extreme example to show what
I mean: r27256 is about using fsfs's directory cache for mutable nodes
leading to possible corruption of an fsfs store. The original issue was
fixed October 17th, backported a few weeks ago and now waiting to be
released in the hands of our users, so that's about two months. And then
we still have downstream maintainers and svn admins that need their time.
In an *ideal* world it would have been fixed 10-17, released 10-17 and
installed on all Subversion repo's worldwide 10-17.
We do not live in an ideal world (un)fortunately, but I think we should
strive to reduce the barriers & constraints that are between us and such
a world instead of going the other way around.
So, instead of doing less but bigger (maintenance) releases I propose to
do more and smaller (maintenance) releases.
Why?
- Primarily, because our users will find issues fixed earlier, which
will lead to less issue reports and happier users.
- Also, the impact of a release will be smaller, easier to review and
test for us committers, for the package maintainers and for admins.
There are however some constraints and valid concerns, some of which
Mark has already pointed out:
- we need to find a release manager with plenty of time to build the
source release package, update documentation etc.
- we need 6 committers to stop developing features for half a day to
build the src package, run 2x4 tests and sign.
- package maintainers need to review and test the packages, maybe change
their scripts and release the packaged binaries.
- svn admins need to plan and take the time to upgrade a production
server installation.
- svn admins (on Windows at least) need to repackage the client and
deploy it to all the user pc's.
Basically, what I'm saying in the above 40 lines is: in order to provide
more value to our users and ourselves, we should do more releases at a
lower cost, instead of less releases at the current high cost.
So, how can we remove or at least reduce the above constraints?
Here are some proposals, feel free to shoot, refine or add suggestions:
1. Plan releases:
- we make a script that sends an email with the current status of the
maintenance branch to dev@s.t.o every week or two weeks. Based on the
content of that mail, committers can discuss the need for a new
maintenance release. I know people already send such mails to the list
regularly already, but:
- we committers can decide anything we want, but we need a release
manager that says: "I'll make a release on Friday next week based on the
current content of the branch. If you want something added, make sure
you vote for and merge it before that time". This doesn't have to be
fixed every two months, but we evaluate the available fixes regularly
and a date gets set. Since most of us our volunteers, we'll need more
people able to make releases.
- criteria to make a release or not probably should be (in order of
importance): the impact of the issues fixed, the number of fixes, time
since last release should not be too small (say less than a month).
2. Reduce the release cost:
Building:
- is the whole release building process automated and documented? If I
remember correctly David Anderson already did a good job here, just
wondering if we can / need to do more?
- what about making a virtual machine image with all the tools and
scripts installed that can automatically build, test and sign a source
release package?
Testing:
- can we make the 3 buildslaves build, test and sign release packages?
That's already 50% of the needed votes ánd we don't waste time
re-releasing and re-testing a package if things went wrong. What about
having 6 buildslaves?
Packages/svn applications:
- what can we do to make the work of the packagers easier? If packaging
and distributing subversion is so difficult that Mark proposes that we
only do maintenance releases every 4 months then we have a serious problem.
However, since we typically have windows binaries in the week after
release I assume Mark is pointing to Subclipse releases, not CN's releases.
- how can we help to make the effort of releasing applications using
Subversion (like Subclipse) smaller? Is it subversion that's the issue
here? Or is it waiting for the svnkit release? Updating the distribution
site?
3. Installing releases:
- as a subversion admin I'll say: the lower the risk, the easier it is
for me to take the decision to install it. Which means, give me one big
release and I'll take me time, give me two smaller and I'll upgrade
directly (on acceptance env. first obviously) if any of the issues are
impacting my users.
- we are already doing a good job reviewing fixes, writing release
notes, keeping api changes out of maintenance releases etc.
- is there something we can automate? is our documentation on how to
upgrade a production svn server sufficient?
- for rolling out client packages on Windows we should switch to .msi
packages instead of .exe's. Well, the 'we' here is those people
volunteering to build and test the installer based on djh's binaries,
ie. Troy and me.
4. Other?
Hm, this mail has gotten a bit longer than expected, but I think this
topic is important enough to spend some time thinking and discussing
about. Most of what I'm proposing is applicable to our feature releases
too in fact. Oh, if that wasn't clear already, if people agree this is
the approach to follow I'm willing to spend time on the above proposals.
Lieven
>> > 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 9 11:16:22 2007