[Arx-users] Real-world ArX usage (was: ArX and simplicity)

[Kevin Smith]

Amine Chadly wrote:
> It seems a little messy to me... As I see it, it is almost impossible to
> talk about common revisions isn't it ?
> People just keep on making merges with other mirrors.
> To have a common revision, one has to create a new mirror from the
> developer he wants to discuss with for example, to exactly know what the
> guy has right ?

I think that's the usage pattern that Walter described when I wanted to
track the official ArX sources, and make my own changes. I would keep a
local mirror of the official archive, and then I would branch that to
have my own sandbox to work in.

Then, I would mirror that to my remote http server, so he (and anyone
else) would be able to see and pull my patches.

The only thing that makes his archive special is that the world
recognizes it as the official ArX archive. It's a human distinction, not
a technical one.

> I am definitely willing to hear the way you'd try to set it up. I have
> myself vague ideas, and I am sure that Walter will correct us if
> something is not correct.
> In any case, I think only good can come from the discussion :-)
> We could try to document the three scenarios, and add it to the wiki.
> I am ready to put together the skeleton of the document from our
> discussions and publish that in the wiki.

Sounds good.

Our team has 3 developers--2 in a California office, and one working
remotely from Florida. This is a Java project which is GPL, but it is
run more like a closed project, so it is important that pre-release
versions not get out. One developer exclusively uses GNU/Linux, and
another exclusively uses MS Windows. We also have a dedicated cygwin
build machine. Two of us actively review *all* code that gets checked in.

Here goes...I'm making this up as I go along!

My vision is that our current CVS server would become our central ArX
server. It would host a "master" archive, which would represent the
official tree from which we would do releases. This master archive would
primarily be controlled by the guy who does the builds, but the other
developers would have the passwords to be able to take over when he is
not available. The master would only be available via ssh.

Each developer would have their own local working archive, which would
be a branch off of the master. We would frequently (~hourly?) do a diff
between the master and our working archive. For each new patch, we would
review the incoming code, and then pull it into our local branch.

As we complete each small coding task, we would run any relevant tests,
review our patch, and commit it to our local archive. As we complete
each related small group of tasks, we would run our full test suite and
then mirror our local archive to a remote copy on the server, via ssh.

Then, I think we would use the patch queue manager to merge each
developer's changes into a staging mirror of the master archive. I
haven't looked at the PQM yet, but we would want a way to trigger it
without using email. In a perfect world, it would monitor each
developer's mirrored archive, and automatically initiate the merge. I'm
not sure whether we would prefer to pull these patches individually, or
as a combined group.

After each merge into the staging archive, the project would be built
and the full test suite would be run. We want to know about any problems
as quickly as possible, so failures would probably trigger emails to the
developers. If the tests passed, the archive would be tagged, and
mirrored from staging into the master archive, and emails would probably
be sent for this case as well. At that point, the changes would be
available to all the developers, restarting the cycle.

For a release, the build guy would use the master archive to go through
an extended build process that includes signing the resulting jars (java
libraries) and creating ISO's and source tarballs. Upon success, he
would tag the master.

Kevin