[Uml-devel] Project coordination

Jens Krüger jens_krueger at frm2.tu-muenchen.de
Fri Jul 19 04:08:04 UTC 2002


Only some last remarks from me.
Am Freitag, 19. Juli 2002 12:09 schrieb Luis De la Parra:
> > 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
>

At this time where nobody knows the current state of the cvs, it is correct, 
that I should not create a new branch. I agreed with you. Let Paul or anybody 
who has write acces to the CVS fix the problems. And then we can start in any 
form discussed here.

> yeah, but if you branch now, with the code that is at the moment in cvs,
> you are only going to have 2 completly broken branches. as I said, I dont
> know what's in cvs at the moment, but for the mails to the list it is
> unusable. I think the branch should be made after cvs is working, if not
> you are only going to have to fix the two branches (separatly, which will
> make it more difficult to merge later)
>
> I agree with you in doing all new development in a separate branch, but I
> think it'd be best to branch from a usuable code than branching from a
> broken
> code.
> what do the others think?
>
> > 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).
>
> you dont have to send any pattches through the world!  =), keep working on
> your new features in your copy. then get the development branch from cvs
> (when
> it's there), put all your new features in this branch and commit to cvs so
> that we all can have it.
>
> > you have enough time for preparing and testing the release. There is no
> > time
> > pressure.
>

My idea was, let us access to developments of other developers in shortest 
times to test their developments or to avoid developments double times. I can 
wait for feature as an user (That's is the reason for my engagment in this 
project) but I can not wait for a long time as an developer, if I want to 
develop new features or improve the implementation of existing features, if I 
think I have a better idea.

> exactly!!, no time pressure, we are trying to develop a very nice app, but
> we are trying to have fun as well while doing it. so I dont see why you
> could
> not wait a couple of days to commit your new features.  It's only going to
> be
> a bigger commit if you do it in two or three days that if you commit your
> code every night, but I dont see any big problem with that.
> I would certanly love to see all your new features, but I still can wait a
> couple of days for them.
>

I agreed.

> so.. to close this topic (for the moment and from my part at least) I think
> fixing cvs before branching can only do good, and I dont see such a big
> problem in having to wait a little before people can commit new features
> (which are going to be put in the devel branch anyways, not in the
> "realease"
> branch).
> You (Jens) obviously think blocking is not a good idea and (I think) you
> (Jens) are
> propossing to just make a branch now.
>

Ok. I will respect their decision too.

> I suggest now some other people give their point of view and Paul and
> Jonathan (is he the new project coordinator?) take a decission.  donst see
> much sense in me and jens discussing this over and over. I tried to explain
> my reasons here, but I dont want (and I can not) force any decission,  so
> all I said is just MHO. Jens has said his oppinion as well, with wich I
> dont agree, but which I fully respect.
> now the coordinator has to take all points into accound and make something
> about it.
>
> 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