[Uml-devel] Project coordination

Jens Krüger jens_krueger at frm2.tu-muenchen.de
Fri Jul 19 02:48:03 UTC 2002


Am Freitag, 19. Juli 2002 11:24 schrieb Luis De la Parra:
> > Hi,
> >
> > Why do you want to block the cvs? I think it is not necessary to block th
> > e
> > cvs. A better way is, to define some TAGS and open some branches for test
>
> ok, I admit I'm not a cvs-expert, but I am not propossing to block cvs
> permanently (that we all have to send the code to some "coodrinator" and
> only he can commit.. NO, I didnt mean that)
>

Is this really necessary to block for day? I understand the reason, but it is 
not the solution. I think the maintainer should say: Hi, I plan to release 
the project.
>From this point all developments of new features should start in a own branch 
and all other work has to do on the main trunk to get a release. If the 
project is released the maintainer has to create a branchpoint for bugfixing 
the released version. After releasing the project you merge all developments 
from the development trunks in the main trunk in the way to the next release. 
I think so you can avoid the problems of blocking the CVS (you can't work on 
new features without sending a lot of patches through the world). Otherwise 
you have enough time for preparing and testing the release. There is no time 
pressure.

> I only suggested to block it for a couple of days, to make sure no one
> commits code in one or two days and give time to the coordinator to
> straight things up and fix all problems in cvs. after that cvs should be
> open again and people can commit direct (of course, AFTER updating its own
> copy and making
> sure they dont break anything and that no one else modified the same code
> they
> modified, in which case they should first solve all conflicts before
> commiting)
>
> branches would be a very good idea if, for example we want to stabilize uml
> for the next release, which everyone wants to make soon without stoping
> new-features development. we could have the release branch and the
> development branch, but now I'm only talking about stabilizing things so
> that we can later branch and merge more easily.
>
> everyone can still code on its cvs copy, but then after cvs is fixed, the
> first time you commit have to get a fresh copy, merge your changes to your
> new
> cvs copy and then, if everything works ok,  commit. from that point on its
> easy.. it's only getting everything fixed the first time which is
> problematic since everyone seems to have
> completly, uncompatible, cvs version (for example, the CR/LF problem, etc)
> and just applying diffs is not easy. there has to be a lot of manuall
> merging. (diffing the CR/LF files will tell you they are completly
> different, and in reallity maybe only 2 lines changed and all the others
> can be fixed with dos2unix, but this has to be done and tested manually by
> someone. that's why I inist in first ONE person fixing cvs, and then the
> rest of us has to adapt to this "new" code
>
> so, I still propose to block, fix, and then reopen.
> if Jonathan is willing to do this work, Paul agrees, and Jens and everyone
> else accept this we could take Thomas' and Jens' tips so that everyone can
> commit with out accidentaly fucking things up for everyone.
>
> regards,
>
> Luis

-- 

Jens Krüger

Technische Universität München
ZWE FRM-II
Lichtenberg-Str. 1
D-85747 Garching

Tel: + 49 89 289 14 716
Fax: + 49 89 289 14 666
mailto:jens_krueger at frm2.tu-muenchen.de
http://www.frm2.tu-muenchen.de




More information about the umbrello-devel mailing list