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
