[openbeos] Re: Organizational question

Hi,
distriuted development is very nice if you want to fix a bug, but it is
really annoying for the main devs if their changes are not immediately
available (i.e.: someone commits it or a patch-email must be received
and processed by some server). I also doubt someone would take on the
annoying job of applying each patch manually. This is time-consuming and
does not improve anything.
IMHO, if the main devs get the same "instant-commit" feature and
functionality of CVS they are happier (does arch allow this, too?). The
problem is that non-members cannot commit changes easily which often
prevents them from fixing a bug. Does p4 solve that issue (or could we
use two separate branches or repositories and sync them?)?

Additionally, not long ago I read a tutorial on arch and I found it too complicated in most situations.

Bye,
Waldemar

Niels Reedijk wrote: 
On 2004-10-11 at 19:05:23 [+0200], Mikael Jansson (mailing lists) wrote:

Please do not flame me, this is just a question:

Seeing how Perforce was used at Be, for OpenTracker, and for NewOS,
what is the arguments for and against using it for Haiku?  I use it
myself for all my development, and find it very easy to use and
maintain.


You will be pleased to hear, that this is one of the options currently
discussed on the admin list. :-) Since changing the source control system
also means moving away from SF -- a solution that works at least mostly
well enough -- a decision will not be made precipitant.



Hi all,

Good to hear that something is being discussed. The cons of sourceforge (the
fact that it only offers cvs which is flawed and the fact that it is very
slow) might not outweight the pros, but that's something you're probably
already discussing. However, don't keep this discussion restricted to
perforce vs cvs. I urge you to consider a whole different analogy of version
control.

The cvs analogy of a central server with numerous clients of which some can
change content on the server is basically flawed when you consider open
source projects. In such projects you have different levels of contributors,
ranging from die-hard developers to people who solve a bug that is haunting
them. Furthermore, many developments run parallel (different people work on
different components) developments.
What I envision for the method of development in the future is that
there will basically be one 'maintainer' - or team lead who will decide what
code is ready for integration and what is not. Thus there will be one (or
two) centralised mainlines. Within a team, it is reasonable to expect that
multiple features or changes will be worked on simultaneously. This doesn't
necessarily have to be recorded on a centralised repository, a few
developers might want to develop it more or less privately first until it is
ready for inclusion, thus creating another branch. When one developer works
on a feature, he will probably want to keep a history of small changes
before merging it into an upstream branch. When a developer goes on a
journey to a place where toilet paper is a luxury (so internet is too), he
might want to keep track of his changes on a private branch. When a
distributor makes some customizations on the mail app but wants to be kept
up to date with mainline changes, he must branch himself too. All the situations described above are impossible to solve with a
centralised repository. The analogy is basically flawed, and if we are
moving revision contol systems, it might be a good idea to adapt to the way
(open source) development really works.

I have been working with arch now for a while (www.gnuarch.org and
wiki.gnuarch.org) and I basically fell in love with it. It is a very
powerful tool, albeit a bit crude, that will definitely be the development
model of the future. I have been making some personal notes on how this tool
could be implemented in this project, and I will be able to elaborate on it
a bit if anyone cares. After all, wouldn't it be cool to be able to pull the
latest stable revision of haiku including an experimental kernel and
experimental usb2 support?

Niels






Other related posts: