[openbeos] Re: Organizational question

  • From: Niels Reedijk <Niels.Reedijk@xxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Wed, 20 Oct 2004 22:21:43 +0200

> 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.

Naturally there will be different grades. I think it will all depend
on what kind of policy there will be. I envision that we keep the
breakdown in kits/teams. Every team will have a maintainer. If it is a
low-traffic team, all the approval and integration into mainline can
be done via the maintainer. However, if there are a few active
contributors (whose code is accepted without hesitation), it will be
possible that the maintainer will have a special branch that will be
accessible by those people. In that case the maintainer should only
have to manually check and merge the patches from irregular
contributors.
(I have been thinking about the exact technical way to do this. I will
be happy to share it, if someone asks for it).

> IMHO, if the main devs get the same "instant-commit" feature and
> functionality of CVS they are happier (does arch allow this, too?).
> The

Arch is merely a tool for revision control. It doesn't implement a
server, that's up to us. It works over http (webdav), ftp, ssh,
network filesystems, you name it. Whatever one we choose, depends
largely on the policy we decide to implement. Giving the main-devs
their own account is only one of the many options available to us.

Arch might impose a very rigid work flow, but it's transports are flexible.

> 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?)?
>
> AFAIK, arch is very complicated to use (I read a small tutorial). One
> often needs multiple commands to do a simple task which could be done
> with one command.

Arch isn't very complicated to use, it's crude. That might seem
identical, but it isn't. It is true that the comments for arch seem
difficult, or to explicit. However, all commands are consistent and
understandable. As soon as you get into the workflow, you will know
the proper commands for everyday use, and it will be easy enough to
collect other information from the reference for more specialised
tasks.

Niels.

P.S. Sent from another account, as my ISP decided not to relay mail to
freelists anymore ...

Other related posts: