[Uml-devel] branching

[Thomas Baumgart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

on Monday 29 July 2002 19:44, Jonathan Riddell wrote: 

> > The other point I suggest is, after creating a release (in the future of
> > course) we should create a branch, that contains the released version.
> > The development should go in the main trunk, and the branch should only
> > contains the bugfixes of the released version. The main trunk should
> > automatically go to the next release. (as described in the kmoney2
> > handbook).
>
> That sounds about right.

As author of the referenced document, I want to throw in my $0.02 here. It 
seems, that you want to follow the plan outlined in the kmymoney2 project 
handbook. All you (developers) need to do, is to agree to this plan 
(numbering scheme, what goes where, etc.). We've done it similarly in the 
kmymoney2 project. Have someone to document what you decided (you are welcome 
to use my project handbook as a template) and release it on the web-site. 
Then, every other person in the world can read how it is supposed to work.

> > I agreed to you. Do you have an idea how we can improve the hunting for
> > the inherent bugs? My idea is: stop the introduction of new features at
> > this time, find most of the bugs by testing or/and code review, and if we
> > are sure, the most bugs are found, release it and put it for downloading
> > on the web page.
>
> Good plan.

In the kmymoney2 project, we distinguish between 'feature freeze' and 'release 
freeze'. Only the 'release freeze' is documented in the project handbook as 
far as I can remember. The feature freeze is announced by the release manager 
and should be followed by all developers. That means, after this point in 
time, no more new features go into the main branch. The time between 
'feature' and 'release' freeze is when we stabalize the program and hunt 
bugs. Once confident, we release it.

As the release manager of the kmymoney2 project, I usually start a survey 
among the developers when they will have the necessary features in and how 
long it will take them to get them stable. When I have these dates, I setup 
and announce a release-plan which will also be posted to the web-site (we ran 
through this cycle once in the past and did not post it to the web).

> > Does anybody know, whether the bugtracking works at SF, especially for
> > UML Modeller? If yes, we should use it.
>
> It should do except that we don't have privilages to do anything with it
> yet.  Hopefully we will soon.

One more little advise to the project administators of the uml project: Get 
more developers involved in the project administration. From what I read, 
there is currently a problem to get certain things done, because one person 
(or his HW) is not available. The core developers (those that have sent in 
patches in the past) should all have CVS access directly. This will take some 
burdon of those, who have to apply these patches on top of their own work on 
the project. CVS is a great tool and allows to revoke a change very easily. 
That is just, that you're concerned that code is added to the project that 
you don't want to have.

The same applies to the bug tracking tool in SF. All developers with CVS 
access should have full access to the bug tracking area.

As I already mentioned, just my $0.02.

- -- 


Regards

Thomas Baumgart

home: thb at net-bembel.de              WWW: http://www.net-bembel.de/
Check the KMyMoney2 open source project at http://kmymoney2.sf.net/

public key available at http//www.keyserver.net under thb at net-bembel.de
GPG-FP:  E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
- -------------------------------------------------------------
A crash turns an expensive computer into a simple stone!
- -------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Visit S.E.S.A. AG at http://www.sesa.de/

iD4DBQE9RjWEBEBpXFzzndgRAhRJAJ4u8/29O1ZOSSiuwyrXeFphXSjuogCY7+Zs
fhIbXpe2EDqsu0uGCNniGA==
=05LJ
-----END PGP SIGNATURE-----