Home
The Toolkit for Online Communities
16673 Community Members, 0 members online, 2513 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Release plans for 5.1 (feature freeze 22 Feb!) : One Message

Forum OpenACS Development: Re: Release plans for 5.1 (feature freeze 22 Feb!)

Collapse
Posted by Lars Pind on
What's the goal?

To me, the goal is to get as many hands as possible to help fix bugs, so we can get the release out quickly and merge the branch back.

Branching early seems to detract from that goal in that it encourages people to continue working on new features, when they should be helping testing and bug fixing the release, so we can move on.

Branches are also painful, because bugs are going to be discovered, researched, and fixed twice, meaning wasted effort.

Ideally, I'd have all hands work on testing and bug fixing, and not branch at all until we have actually shipped 5.1.0.

Maybe we have different goals, or maybe I'm just being unrealistic.

It feels like the Bystander Apathy story, where if 1 person is watching a murder, they're likely to do something, but if 30 people are watching it, nobody does anything, because they all figure that someone else will do something, or maybe there's nothing to do, because if there were then surely someone would do it.

We need to get all hands involved in doing the grunt work of shipping. No bystanders, please!

I remember some dude once saying something like "Software is worthless until you ship it" ;-)

/Lars

Collapse
Posted by Malte Sussdorff on
I work out of head and I'm happy with not branching unless head is in a state that allows us to release. But what happens to changes that come in and actually throw us back again in our "time to release" ?

How do we define the feature freeze. You should not prevent people to write on new things only because some others want to release software. Where shall their code go to in the meantime. I think working off from a seperate repository and doing vendor imports of OpenACS is too much of a fuzz for most developers which is the reason why I think quite some of us still work out of OpenACS repository.

Again, personally I'm in for releasing the way we do and concentrating on bug fixing instead of new features once we have a feature freeze. But I would like to see ways for others that are not commited to release to continue working. After all, what happens if we fail to release quickly.

Unless we don't TIP this and get an agreement on what the steps are going to be when we release, we are stuck dead in the water. As Joel is the release manager it would be great if he could TIP whatever he thinks works out best and let the OCT vote on it. Then at least all of us know what is coming up, how do deal with it aso.