How to 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 
seperatly)
      allow for quick turn arounds, since every commit is equivalent to 
a microrelease.


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 ?

-- 

SAXESS Software Design GmbH
Neuenhöfer Allee 125
D-50935 Köln

Dr. Hussayn Dabbous

Fon: 0049 (0)221 56011 0
Fax: 0049 (0)221 56011 20

http://www.saxess.de
http://www.cinemacchiato.com
http://blog.machinimatrix.org
-----------------------------

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

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