howto make a reliable release-0.22

It sounds like all of us would like to see the 50 non closed 0.22-related
issues fixed,
before we create release-0.22. Only then we want to get back to work on
trunk.

But lets face it: We do have 200 open issues at the moment in total.
But if you look on the other side of the coin, i think some of us are
running trunk as
productive system. So it can't be soo bad, no ? I myself am running trunk
since
7 months on at least 4 Scarab instances and i am quite happy with it.


IUnstead of freezeing trunk, we still do have alternative ways to go.
I see 3 options:

1.) freeze trunk, all "new" features go to branches.

pros: all efforts go into the release.
        next release could be stabilized faster.

cons: continuous work is full stopped.
        never ending discussions about what is a fix, what is a feature
        all new features/enhancements go to branches,
        so each developer is isolated from the others.
        branches must be maintained separately.
        espcially take must be taken to later be able to merge back to
trunk.


2.) branch to a release branch, all release fixes are ported back into the
trunk

pros: We do have a definitive cut, so new features in trunk don't disturb
release fixing.
        work on trunk can continue

cons: less resources for the release fixing.
        more effort on backporting release fixes.
        danger to loose fixes, so that a bug fixed in release x might
reappear in relase x+1


3.) Just continue as we do right now. Occasionaly we hear somebody moaning
about Scarab is
    dead, no release since 2 years. Yes you are all right. But i guess, we
do have a capacity
    problem...

pros: allow developers maximum efficiency
        keep testing as efficient as possible (no branches to be tested
separately)
        allow for quick turn arounds, since every commit is equivalent to a
microrelease.

cons: no defined release in the classical sense

summary: To me it looks like everybody wants a new release, but nobody wants
to, or has the
time to actually do the release work. I don't exclude myself. I cna
understand that.
I have done release work in the past and it is a frustrating job which needs
a huge amount of
effort especially because many bugs are almost not reproducible, or need
significant care
taking to setup an environment so that such a bug can be efficiently tracked
down. from my own
experience i remember, that we started a release branch for the last
revision, and it took us
several weeks to get the release actually done. I simply do not find the
time to get into
another release cutting session. And i am afraid, there is no big pressure
on anyone of us to
actually do such a move ...

So here is my personal conclusion: I personally opt for keeping Scarab
development as it is
for the moment. My own tasklist involves quite a few usability enhancements,
which might very
well make many open issues silently become obsolete. I very strongly opt for
making a
release-branch and keep trunk what it is, the development branch. And
freezing the development
branch doesn't sound too good to me ;-(


And here is my proposal:
Create the 0.22 release branch and fix branch-related issues there as needed
and as time can
be found. I will help too and put my hands on release-fixing issues, but
with a low priority.
As soon as all 0.22 related bugs are fixed in the release branch (and
hopefully also ported to
the trunk) Scarab is ready for release 0.22. Doing so, might help to make us
feel much more
comfortable:

- we have established a well defined release-branch, containing everything
relevant for  the release
- we can stabilise in a very controlled way. No move from trunk to release.
- trunk is free for contineous development.

So what do you think ?

-- 
View this message in context: http://www.nabble.com/howto-make-a-reliable-release-0.22-tp21347530p21347530.html
Sent from the Scarab - Dev mailing list archive at Nabble.com.

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=455&dsMessageId=1011274

To unsubscribe from this discussion, e-mail: [[email protected]].