Lieven Govaerts wrote:
> 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.
So, I'm willing to back away from the idea of hard-and-fast deadlines
for patch releases, but I do think we've got to do a better job at
getting releases out quicker. Lieven's proposal for a policy with an RM
who will say "hmm, it's been a couple of months and 10 new fixes have
gone through STATUS. Let's release next Friday" appeals to me. My
Subversion-related time has been somewhat bursty as of late, but I think
that I could fill such a role if needed.
I also would like to reiterate that automation would be key to this
process. Testing and signing releases wouldn't take half a day if the
entire process were scripted well enough. We've come a long way in that
regard, but we can still do better.
I've never maintained a downstream package, so I may also be a little
bit naive in this regard. Is there a significant amount of pressure
from users of downstream packages to have the latest and greatest right
away? Do the users monitor svn-announce@s.t.o and clamor for the next
release of Subclipse or TSVN? I guess I just don't understand why
downstream package managers feel they need to do a release just because
we do.
-Hyrum
Received on Mon Dec 10 22:33:27 2007