You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <eh...@gmail.com> on 2006/07/09 21:37:56 UTC
Our (in)ability to do releases?
I'm not seeking to accuse anybody, but feel I should speak up about
the way I'm feeling.
Ever since 1.3, I feel like we're more and more unable to get releases
out the door (within a reasonable time after branching).
I haven't identified any reasons why this might be happening or even
what to do about them. That is the reason of this mail: do others feel
the same? Do you have ideas why it is happening? Do you have ideas how
to prevent it?
One possible reason is that we have too many changes per release: most
of which go largely untested as long as they're on trunk, getting
first exposure on a release branch. When many changes/new features are
exposed this way, stabilization takes a long time. This ofcourse isn't
in any way 'the truth'. I hope others have thought about it too.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 7/10/06, Daniel Berlin <db...@dberlin.org> wrote:
> Erik Huelsmann wrote:
> > I'm not seeking to accuse anybody, but feel I should speak up about
> > the way I'm feeling.
> >
> > Ever since 1.3, I feel like we're more and more unable to get releases
> > out the door (within a reasonable time after branching).
> >
> > I haven't identified any reasons why this might be happening or even
> > what to do about them. That is the reason of this mail: do others feel
> > the same? Do you have ideas why it is happening? Do you have ideas how
> > to prevent it?
>
> I believe it is simply a matter of our release manager not having time.
> Not that I blame him, it's just that we have no paid, full time release
> manager, so we get releases when he has time to make them.
>
> He hasn't had time lately due to other, higher priority (and rightly so)
> commitments.
>
> >
> > One possible reason is that we have too many changes per release: most
> > of which go largely untested as long as they're on trunk, getting
> > first exposure on a release branch. When many changes/new features are
> > exposed this way, stabilization takes a long time. This ofcourse isn't
> > in any way 'the truth'. I hope others have thought about it too.
>
> Sorry, I don't believe this at all. All the time we've spent has been
> waiting for RC's to be rolled and getting signatures, not waiting for
> features to be fixed.
Well, from 1.3, I remember the python bindings memory management
needing fixes after branching (and before RC1). This time, we have -
at least - the bdb 4.4 fixes we've been waiting for.
In my opinion neither was an *RC1* show stopper though, once the cause
was identified: we could have released with the first bdb 4.4 fix and
worked on the bdb-4.4-real-fix while collecting test results for RC1
IMO, since there was no dataloss, only segfaults (at program
shutdown!) which required bdb recovery, but that's built-in now...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Paul Burba <pa...@softlanding.com>.
Daniel Berlin <db...@dberlin.org> wrote on 07/10/2006 10:34:37 AM:
> Lieven Govaerts wrote:
> > 2. Making+publishing a release apparently is very a time-consuming
manual
> > process. Gathering the required signatures for the Windows .zip
> file proved to
> > be very difficult, probably because there aren't many full
> committers working
> > on Windows?
> >
> True.
A small bit of good news re Windows testing: I recently put together a
dedicated Windows test environment* for 1.4.0-rc1 and plan to perform
Windows testing going forward.
Paul B.
* [ fsfs | bdb ] x [ file | svn | http ] on Windows XP Pro Version 2002
SP2 x86 with MS Visual C++ 6.0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Daniel Berlin <db...@dberlin.org>.
Lieven Govaerts wrote:
> Quoting Daniel Berlin <db...@dberlin.org>:
>
>> I believe it is simply a matter of our release manager not having time.
>> Not that I blame him, it's just that we have no paid, full time release
>> manager, so we get releases when he has time to make them.
>>
>> He hasn't had time lately due to other, higher priority (and rightly so)
>> commitments.
>
> I have only been involved in subversion-dev starting from 1.4 so my view is a
> bit from the outside. As a result some of my observations/ideas may be plain
> wrong, feel free to point them out.
>
> To start with, I'm very excited about the prospect of upgrading our (at the
> office) Subversion to the 1.4 release. While there aren't many functional
> changes, lots and lots of issues have been fixed, many of them which we
> encounter daily.
>
> The 1.4 branch was created 2 months ago, no official RC has been released since.
> In fact, lots of new changes (bugfixes) have been merged to the 1.4.x branch
> later.
>
> The fact that our RM (who voluntarely spends some of his free time on this
> project) didn't have time to make the release is one thing, but it shows me
> other - more importants - facts:
>
> 1. We only have one RM, nobody seems to be able to replace him?
Actually, he replaced the last RM who up and disappeared for a while
(for personal reasons).
The process is documented.
What time is
> needed for someone to learn the skills of releasing svn? Is it fully documented?
AFAIK, It's just herding people and following the checklist we have.
So it is documented. It was documented when he started, but the
documentation wasn't as complete as it is now.
>
> 2. Making+publishing a release apparently is very a time-consuming manual
> process. Gathering the required signatures for the Windows .zip file proved to
> be very difficult, probably because there aren't many full committers working
> on Windows?
>
True.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 10 Jul 2006, Malcolm Rowe wrote:
> On Mon, Jul 10, 2006 at 12:35:04PM -0400, Garrett Rooney wrote:
> > On 7/10/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> > >But now that you mention it, we could have released -rc1 with the initial
> > >--bdb-txn-nosync bug present (i.e. before Garrett's pool-destruction fix
> > >in svnserve) and just noted the problem as a known bug for that release.
> >
> > That gets us back to the "it's not much of an RC if we know we aren't
> > going to release it" problem... Maybe we really need beta releases
> > for major version bumps or something like that.
> >
>
> Yeah. I was thinking that on the way home. I think we'd have avoided a
> lot of the recent stress of trying to release 1.4.0-rc1 if we'd already
> put out a 1.4.0-beta1 when we were ready (about 6 weeks ago).
Given the current process, betas would be useful to get some initial
feedback on whether we're in good enough shape for a release
candidate.
Re: Our (in)ability to do releases?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Jul 10, 2006 at 12:35:04PM -0400, Garrett Rooney wrote:
> On 7/10/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> >But now that you mention it, we could have released -rc1 with the initial
> >--bdb-txn-nosync bug present (i.e. before Garrett's pool-destruction fix
> >in svnserve) and just noted the problem as a known bug for that release.
>
> That gets us back to the "it's not much of an RC if we know we aren't
> going to release it" problem... Maybe we really need beta releases
> for major version bumps or something like that.
>
Yeah. I was thinking that on the way home. I think we'd have avoided a
lot of the recent stress of trying to release 1.4.0-rc1 if we'd already
put out a 1.4.0-beta1 when we were ready (about 6 weeks ago).
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/10/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> Just to clarify (because I don't think I was very clear above), the
> 'theoretical' part of the problem I was referring to was the BDB
> pool-destruction ordering bug that I don't pretend to understand,
> and that was recently fixed.
>
> But now that you mention it, we could have released -rc1 with the initial
> --bdb-txn-nosync bug present (i.e. before Garrett's pool-destruction fix
> in svnserve) and just noted the problem as a known bug for that release.
That gets us back to the "it's not much of an RC if we know we aren't
going to release it" problem... Maybe we really need beta releases
for major version bumps or something like that.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Jul 10, 2006 at 11:56:28AM -0400, C. Michael Pilato wrote:
> Malcolm Rowe wrote:
> > I also feel that we seem to be too hung up on creating a 'perfect'
> > release. For example, we've had enough signatures for 1.4.0-rc1 to
> > release for a while, but we held it up because of a theoretical problem
> > that only manifested itself with BDB-backed --bdb-txn-nosync repositories.
>
> Um. No. This was no theoretical problem. Tests were failing. Garrett and
> I both experienced the problem independently. We held up the 1.4.0-rc1
> release because we felt rc2 was gonna be out in a matter of days. In
> retrospect, that might not have been such a good plan. Maybe better to
> release rc1 with a warning message about known problems (I mean, I'm running
> rc1 on svn.collab.net right now with no issues, so presumably others could,
> too) and then continue as usual towards rc2.
>
Just to clarify (because I don't think I was very clear above), the
'theoretical' part of the problem I was referring to was the BDB
pool-destruction ordering bug that I don't pretend to understand,
and that was recently fixed.
But now that you mention it, we could have released -rc1 with the initial
--bdb-txn-nosync bug present (i.e. before Garrett's pool-destruction fix
in svnserve) and just noted the problem as a known bug for that release.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> 2. Our compatibility rules only allow desupport of feature based on the
> (I'll make up terms here) catastrophe model rather than the slow
> extinction model.
It may be worthwhile considering a "punctuated equilibrium" model
instead of either of the extremes you mention, as that might lower the
barrier for major releases to an acceptable level. A focused effort to
move forward at a brisker pace, followed by a quiet period of bugfixes
and more minor feature changes.
The goal should be to make sure that new features can be added in an
orderly fashion without necessarily being frozen out by backwards
compatibility worries. I'm thinking specifically of some of the
discussions about bumping the repository structure to support additional
indexes. As long as that is viewed a "2.0-only task" no development
will happen on trunk.
It's almost like the project has to fork itself into 1.x development
(backwards compatible) and 2.x development (forward compatible only).
If the new development was focused more on this new trunk, 2.x could
become a reality, rather than being a long-off hope. I don't know if
there is enough programming talent available to handle this. But I'd
like to see 2.x last half as long as 1.x did, with more focus on moving
forward than trying to shoehorn new capabilities into the existing
footprint.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2006-07-10 at 17:59 +0200, Erik Huelsmann wrote:
> Also, I said that we definitely should have released RC1 after the
> initial fix: it may not have been the perfect one, but it did work for
> that moment and the perfect fix could have been in RC2...
I'm seeing two issues raised by this thread:
1. We don't have beta tests for new-feature releases, only release
candidates. Something with a known release-blocking bug is not a
release candidate, so once we know about a release-blocking bug, we
can't get any tarball testing done until we fix it.
2. Our compatibility rules only allow desupport of feature based on the
(I'll make up terms here) catastrophe model rather than the slow
extinction model.
In the catastrophe model, we release an svn 2.x which is considered a
totally different product from svn 1.x. There's an upgrade path, but
there's no other requirement of compatibility. svn 1.x and 2.x can
perhaps be installed concurrently, just like svn 1.x and CVS can be
installed concurrently. This is what GNOME did between 1.x and 2.x.
In the slow extinction model, we declare a feature deprecated in release
1.x, and then remove it in release 1.(x+5) or something. Users are
expected to migrate away from desupported features over time. I think
this is more like how gcc works.
One of the drawbacks of the catastrophe model is that we are forced to
do a lot of work during a relatively short window. We say "okay, we
have enough things we want to do now that we're going to put out svn 2.x
in [six months, a year, whatever]" and in that window we have to code
*every* incompatible change we want to do in the next 5-10 years, since
we only want to pay the price of a major upgrade rarely. I think the
reason we've never seen a serious proposal towards 2.0 is that no one
believes we have the resources to pull off such a massive effort, or
wants to coordinate it if we do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Erik Huelsmann <eh...@gmail.com>.
> > I also feel that we seem to be too hung up on creating a 'perfect'
> > release. For example, we've had enough signatures for 1.4.0-rc1 to
> > release for a while, but we held it up because of a theoretical problem
> > that only manifested itself with BDB-backed --bdb-txn-nosync repositories.
>
> Um. No. This was no theoretical problem. Tests were failing. Garrett and
> I both experienced the problem independently. We held up the 1.4.0-rc1
> release because we felt rc2 was gonna be out in a matter of days. In
> retrospect, that might not have been such a good plan. Maybe better to
> release rc1 with a warning message about known problems (I mean, I'm running
> rc1 on svn.collab.net right now with no issues, so presumably others could,
> too) and then continue as usual towards rc2.
Right, but we use in our test suite an option which we explicitly
advise against for production environments.
Also, I said that we definitely should have released RC1 after the
initial fix: it may not have been the perfect one, but it did work for
that moment and the perfect fix could have been in RC2...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Malcolm Rowe wrote:
> On Mon, Jul 10, 2006 at 07:56:22AM -0700, Justin Erenkrantz wrote:
>
>>The release process should be invokable and be able to be "run" by any
>>full SVN committer and not have to wait for any other person (except
>>for the 3 +1s to make the release public). It's not fair to the rest
>>of us who want to see releases out the door and have the time to help
>>out. -- justin
>>
>
>
> +1.
>
> I also feel that we seem to be too hung up on creating a 'perfect'
> release. For example, we've had enough signatures for 1.4.0-rc1 to
> release for a while, but we held it up because of a theoretical problem
> that only manifested itself with BDB-backed --bdb-txn-nosync repositories.
Um. No. This was no theoretical problem. Tests were failing. Garrett and
I both experienced the problem independently. We held up the 1.4.0-rc1
release because we felt rc2 was gonna be out in a matter of days. In
retrospect, that might not have been such a good plan. Maybe better to
release rc1 with a warning message about known problems (I mean, I'm running
rc1 on svn.collab.net right now with no issues, so presumably others could,
too) and then continue as usual towards rc2.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Our (in)ability to do releases?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Jul 10, 2006 at 07:56:22AM -0700, Justin Erenkrantz wrote:
> The release process should be invokable and be able to be "run" by any
> full SVN committer and not have to wait for any other person (except
> for the 3 +1s to make the release public). It's not fair to the rest
> of us who want to see releases out the door and have the time to help
> out. -- justin
>
+1.
I also feel that we seem to be too hung up on creating a 'perfect'
release. For example, we've had enough signatures for 1.4.0-rc1 to
release for a while, but we held it up because of a theoretical problem
that only manifested itself with BDB-backed --bdb-txn-nosync repositories.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/10/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> If nobody objects, I'd be willing to start picking up some of the RM
> tasks myself, I just don't want to step on anyones toes here.
As before, I'd be willing to be an RM for a 1.4.x RC as well.
I will reiterate that I dislike the fact that we have a concept of a
dedicated RM for all releases. This is not a new argument from me and
is not intended in any way towards our current RM. For those new to
SVN, I've made this argument for many years now as we've changed the
RM title (at least) three times now...
I really feel strongly that having a dedicated RM tends to stall the
process whenever that volunteer inevitably gets bogged down by Real
Life(tm). Other people then get in the mindset of "I can't do a
release without that one RM being available." That's just bad. The
RM title should only be given when that person says, "I'm going to do
1.4.0-RC1" - that should not mean that they are going to be RM for
1.4.0-RC2 or so forth...
The release process should be invokable and be able to be "run" by any
full SVN committer and not have to wait for any other person (except
for the 3 +1s to make the release public). It's not fair to the rest
of us who want to see releases out the door and have the time to help
out. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/10/06, Lieven Govaerts <lg...@mobsol.be> wrote:
> 1. We only have one RM, nobody seems to be able to replace him? What time is
> needed for someone to learn the skills of releasing svn? Is it fully documented?
It is not that we don't have anyone who can replace him. We have
people who could do so, it's simply that most people don't feel
comfortable standing up and saying "hey, this is taking way longer
than it should, mind if I take over for you" because it implies that
the current RM isn't doing their job. Now we know that's not the case
at all, it's just a matter of volunteer work taking the back seat
compared to things that are more important, but it's still difficult
to make that leap to asking someone to step back from the job they've
volunteered for.
> 2. Making+publishing a release apparently is very a time-consuming manual
> process. Gathering the required signatures for the Windows .zip file proved to
> be very difficult, probably because there aren't many full committers working
> on Windows?
This is a problem, yes.
> 3. Nobody seems to be owning this release. I'd expect that someone would take
> the lead in having and closing the discussion on the bdb fixes, motivate people
> to write the changelog, enquiring the RM on the status of RC packages etc. I
> maybe mistaking, but I guess this is something that Karl or Ben have been doing
> for previous releases?
Normally the RM does that.
> It's the holiday season now, I think it's going to be difficult to release 1.4
> before the beginning of september; while this means people will have to wait
> two months longer, we have the opportunity to fix even more of the open issues.
I think August is a more reasonable timeline, personally.
If nobody objects, I'd be willing to start picking up some of the RM
tasks myself, I just don't want to step on anyones toes here.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Lieven Govaerts <lg...@mobsol.be>.
Quoting Daniel Berlin <db...@dberlin.org>:
> I believe it is simply a matter of our release manager not having time.
> Not that I blame him, it's just that we have no paid, full time release
> manager, so we get releases when he has time to make them.
>
> He hasn't had time lately due to other, higher priority (and rightly so)
> commitments.
I have only been involved in subversion-dev starting from 1.4 so my view is a
bit from the outside. As a result some of my observations/ideas may be plain
wrong, feel free to point them out.
To start with, I'm very excited about the prospect of upgrading our (at the
office) Subversion to the 1.4 release. While there aren't many functional
changes, lots and lots of issues have been fixed, many of them which we
encounter daily.
The 1.4 branch was created 2 months ago, no official RC has been released since.
In fact, lots of new changes (bugfixes) have been merged to the 1.4.x branch
later.
The fact that our RM (who voluntarely spends some of his free time on this
project) didn't have time to make the release is one thing, but it shows me
other - more importants - facts:
1. We only have one RM, nobody seems to be able to replace him? What time is
needed for someone to learn the skills of releasing svn? Is it fully documented?
2. Making+publishing a release apparently is very a time-consuming manual
process. Gathering the required signatures for the Windows .zip file proved to
be very difficult, probably because there aren't many full committers working
on Windows?
3. Nobody seems to be owning this release. I'd expect that someone would take
the lead in having and closing the discussion on the bdb fixes, motivate people
to write the changelog, enquiring the RM on the status of RC packages etc. I
maybe mistaking, but I guess this is something that Karl or Ben have been doing
for previous releases?
It's the holiday season now, I think it's going to be difficult to release 1.4
before the beginning of september; while this means people will have to wait
two months longer, we have the opportunity to fix even more of the open issues.
Lieven.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/10/06, Daniel Berlin <db...@dberlin.org> wrote:
> Not that i'm suggesting removing BDB right now, i'm just saying that
> *even if we wanted to*, we don't have a policy about how to do it, other
> than "we can't remove it until 2.0".
And there-in lies the policy - BDB can't be tossed until 2.0. What's
the problem here? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Daniel Berlin <db...@dberlin.org>.
Garrett Rooney wrote:
> On 7/9/06, Daniel Berlin <db...@dberlin.org> wrote:
>
>> Sorry, I don't believe this at all. All the time we've spent has been
>> waiting for RC's to be rolled and getting signatures, not waiting for
>> features to be fixed.
>
> Well, yes and no. We've certainly burned a lot of time on that, but
> we've also burned a lot of time waiting for BDB 4.4 fixes (and for
> someone not very familiar with that code (uhh, me) to get up to speed
> enough with it to finish those fixes off), something that IMO is
> likely to happen more and more as we go down the road of having
> multiple implementations of a given subsystem.
True.
However, this is also going to get worse because we have a policy of
backwards compat with things like the fs until the "mythical 2.0", which
nobody seems to have any concrete idea of (IE what it would take to make
something 2.0).
This means we can't deprecate things as they fall by the wayside, even
if we had a strategy of waiting until the release was no longer
officially supported to remove the feature.
Not that i'm suggesting removing BDB right now, i'm just saying that
*even if we wanted to*, we don't have a policy about how to do it, other
than "we can't remove it until 2.0".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/9/06, Daniel Berlin <db...@dberlin.org> wrote:
> Sorry, I don't believe this at all. All the time we've spent has been
> waiting for RC's to be rolled and getting signatures, not waiting for
> features to be fixed.
Well, yes and no. We've certainly burned a lot of time on that, but
we've also burned a lot of time waiting for BDB 4.4 fixes (and for
someone not very familiar with that code (uhh, me) to get up to speed
enough with it to finish those fixes off), something that IMO is
likely to happen more and more as we go down the road of having
multiple implementations of a given subsystem. If everyone (for some
values of "everyone") uses fsfs, it's harder to get people to work on
bdb, so problems there take longer to fix. I don't have a solution to
that problem, but I think it's a part of the issue. As someone else
pointed out in this thread, we had a similar set of issues with
1.3.x's python bindings changes, because we had limited numbers of
people who could address the bugs. When the bus factor is low, this
kind of problem happens. Historically svn has had a high bus factor
in most parts of the code, but unfortunately not in all of them...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Our (in)ability to do releases?
Posted by Daniel Berlin <db...@dberlin.org>.
Erik Huelsmann wrote:
> I'm not seeking to accuse anybody, but feel I should speak up about
> the way I'm feeling.
>
> Ever since 1.3, I feel like we're more and more unable to get releases
> out the door (within a reasonable time after branching).
>
> I haven't identified any reasons why this might be happening or even
> what to do about them. That is the reason of this mail: do others feel
> the same? Do you have ideas why it is happening? Do you have ideas how
> to prevent it?
I believe it is simply a matter of our release manager not having time.
Not that I blame him, it's just that we have no paid, full time release
manager, so we get releases when he has time to make them.
He hasn't had time lately due to other, higher priority (and rightly so)
commitments.
>
> One possible reason is that we have too many changes per release: most
> of which go largely untested as long as they're on trunk, getting
> first exposure on a release branch. When many changes/new features are
> exposed this way, stabilization takes a long time. This ofcourse isn't
> in any way 'the truth'. I hope others have thought about it too.
Sorry, I don't believe this at all. All the time we've spent has been
waiting for RC's to be rolled and getting signatures, not waiting for
features to be fixed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org