Development branch?

Submitted by epr on Sun, 04/25/2004 - 06:55.

Currently JNode uses single stream development. That means that all developers commit their changes into the HEAD branch. This approach is simple and has little overhead, but make large changes hard to do without a big risk of breaking the system for some period of time.

What do you think about adding a development branch to CVS?

This would imply that all changes are committed to the development branch, which is by definition less stable then the "stable" HEAD branch. When changes are stable enough, they are integrated in the HEAD branch.
Another implication would be that the HEAD branch is write-protected except for those developers that will get integrator access.

We might even setup a development branch per team, which has the advantage of having a stable environment and only those unstable changes that the team is working on. However, it has the disadvantage of having lots of branches for those how work on multiple teams.

Please comment.

Ewout

‹ Remote debugger. Writing jnodedisk.dat to a HD partition ? ›

Do we need it today?

Submitted by lsantha on Sun, 04/25/2004 - 19:43.

The development branch will be a necessity sometime but are we there yet?

Having in mind that JNode is still far from being suitable for any kind of use other then trying to run the code you contribute we should think about whether the benefits of a developer branch worth the extra work of maintaining two branches of the huge code base.

I think that effort would be better used for making the actual code more stable. The final goal would be of course rock solid but at the moment  the next step would be not more than: somewhat usable.

If we look around at the moment there are only a handful of people that make changes in the CVS week by week. A simple habit to work more closely with other people and with the repository could help a lot with the problems that apparently only the developer branch could solve.
This matches also an open source maxim : release often. Which in this case translates to: share your work more often with the other developers.

It is not fun to keep your code held separately with the changes of other people unaware of what you do. Neither is to integrate hundreds or thousands of line of code with the current code base (as it happened with the WT GUI components).

Levente

an assigned task system ?

Submitted by Fabien D on Mon, 04/26/2004 - 10:41.

Hi,

It would be good to have a task system that say which developper is working on what.
This will avoid working on the same task.

I don't know such a system but I am sure it exists (I hope with a free licence).

Who know such a system ? Who want to use it ?

sf project site

Submitted by blind on Mon, 04/26/2004 - 11:27.

The sourceforge project site for JNode has a task manager and many tasks have been created in that a long time ago. Now it is outdated, because nobody has updated it lately, but I think we could use that.
At least it's there.
Andras

Jira

Submitted by lsantha on Mon, 04/26/2004 - 11:00.

is free for opensource projects but where to install it?

install on sourceforge ?

Submitted by Fabien D on Mon, 04/26/2004 - 11:25.

here is the url

It's a J2EE application that manage also bugs and features.

Can't it be installed on sourceforge ? I don't know if they have or can host (open souce) J2EE server.

Bugs follow system

Submitted by galatnm on Mon, 04/26/2004 - 09:32.

Hello,

I think it's important to have a bugs system like bugzilla for an easy way to follow bugs and correct them.

Fabien

You have a point

Submitted by admin on Mon, 04/26/2004 - 07:12.

Hi Levente,

I think you have a point about needing it today.

Let's see who else wants to comment on this.
Ewout

I am for a unique development branch

Submitted by Fabien D on Sun, 04/25/2004 - 09:21.

I am for a unique development branch. I am currently in the case you say : making large changes on the FileSystem part (abstract classes).

The fact is that without any feedback/help from others it will take me a lot of time to be sure things are at least as well as before. So, I can't commit to the HEAD branch, but for the development branch it could be possible. I have also corrected some bugs that I know to be currently in CVS. All of this involve for me a lot of job trying to maintain and resolve conflicts with CVS while updating.

Sometime, changes are correlated between different parts (core, fs, ...). In the case of one development branch per team, it's difficult to use the HEAD branch from one team and the dev branch from another. So, I don't think this is a good solution. But, I must say that for some big changes in only one of the development branch all the teams aren't disturbed by the changes of the other teams.