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
b) CVS syncronization
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.
2. Some form of developer central, keeping track of the current
developments and where they are published.
3. Some bits and pieces of documentation to get the newcomers going
quickly.
4. Some kind of public repository hosting where developers without their
own web servers can publish their work in a seamless manner.
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.
'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..
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.
Regards
Henrik
Received on Sat Jan 08 2005 - 16:41:10 MST
This archive was generated by hypermail pre-2.1.9 : Tue Feb 01 2005 - 12:00:02 MST