Re: Squid development environment & bazaar / arch

Sorry its been so long replying, had a buuusy patch.

On Sun, 2005-01-09 at 00:41 +0100, Henrik Nordstrom wrote:
> As some of you know Robert finally convinced me at the code sprint that
> Arch in the form of Bazaar is sufficiently mature to be used as the main
> tool for Squid development, but there is a few housekeeping tasks
> remaining for us to be able to switch over fully
>
> a) Main tree policy.
>
> - How to commit to the main tree
> - What is the main tree in the view of arch users

I suggest we have a shared repository on squid-cache.org, in a
group-accessible directory on disk, which any of us can commit to, and
which we tell the users is the main tree. Then we all register it via
sftp.

I suggest we have a dedicated user with our ssh keys in
its .ssh/authorised_keys file, as that prevents and issue with file
ownership (baz doesn't alter the umask of files).

For arch users then, this archive can have the official branch, and any
branches that we want to officially bless.

> b) CVS syncronization

There are three ways we can do this.
1) commits via baz trigger CVS commits on a cron job, CVS is deprecated
- no one commits to it anymore. (my preference)
2) aggregate syncing - commits to CVS or Arch trigger a rolled-up commit
some time later. This may have trouble with the different policy on
auto-tool generated files.
3) changeset based syncing from CVS to Arch. This will require the most
love and care, and TBH I don't think its worth it.

> c) Documentation
>
>
> After some thinking I always come to the same conclusion, wimilar to what
> was discussed at the code sprint:
>
> 1. Define a central Arch / Bazaar repository shared by all core
> developers, and from which other developers create branches for their
> work. This is also mirrored into CVS. Commits to this repository should be
> signed.

Yes!

> 2. Some form of developer central, keeping track of the current
> developments and where they are published.

The wiki kinkie put up seems like a good place to me.

> 3. Some bits and pieces of documentation to get the newcomers going
> quickly.

I can write up a HOWTO once we agree on the way things look.

> 4. Some kind of public repository hosting where developers without their
> own web servers can publish their work in a seamless manner.

We've got a project in the pipeline where I work, which will support
this, its getting close to readiness.

> Item 1 should be set up on the squid-cache.org server, outside of Roberts
> tree. Here I see three options
>
> a) Branch off from roberts squid--HEAD--3.0 tree.
>
> b) Create a new tree by importing the CVS again.
>
> c) Somehow clone roberts squid--HEAD--3.0 tree.
>
> 'a' has the benefit that it preserves the existing arch relations
> undisturbed.

Which should not be underestimated.

> 'b' allows for a bit of cleanup but breaks the existing arch relations
> based on Roberts tree, but provided the two trees sync up proper this
> should not be a significant problem. Existing trees just needs to get
> updated to Roberts tree past the sync point before they can switch over to
> merging from the common tree as the patch info of past commits does not
> match.
>
> 'c' probably makes arch very confused and doesn't work very well..

I'm in favour of a, as we can always go and look in CVS if we want
history from before I started using arch.

> Item 2 and 3 probably would do good if moved over from
> devel.squid-cache.org to a Wiki or other dynamic environment. The current
> devel.squid-cache.org web environment is a bit too static to fill it's
> purpose well. There is also numerous pieces from www.squid-cache.org which
> would do good in getting moved over to a more dynamic environment.
>
> For item 4 there is several available choices. For me it is OK if
> community members publish their repositories on devel.squid-cache.org (we
> have plenty of space available there), but I am also fine with any other
> public services used for the purpose as long as their location gets
> registered somewhere. One very prominent beauty of arch is that it is not
> critical to keep central repositories.

Exactly.

Cheers,
Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.