[openbeos] Re: Organizational question
- From: "Niels Reedijk" <n.reedijk@xxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Wed, 13 Oct 2004 22:15:13 +0200
> 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:
