[Box Backup-dev] wiki page changes

[Martin Ebourne]

Nick Knight <nick@omniis.com> wrote:
> The page I have added it to is
> http://boxbackup.hostworks.ca/index.php/Source_code_repository.

Excellent, thanks Nick. That was a good base. I've gone in and made =20
some changes to make it reflect a combination of what we already do =20
and where I thought we should go. I liked the idea of the features/ =20
directory for branches so went with that and extended it.

I didn't quite get time to finish what I wanted but I can see Ben has =20
gone in and made some edits, so I'm guessing he agrees with the =20
general direction. We both didn't see the need for a bugs branch so I =20
removed it.

A few things I'd like to discuss (and email is better than a wiki page =20
for that :)). If people could review the page and then follow up with =20
ideas that would be great.

1. Looking at the current repository top level I felt it was getting =20
too cluttered so some cleaning up was in order. Using Nick's feature =20
branches I think that should cover all significant extensions to box, =20
including ports. I also think all personal branches should be together =20
out of the top level.

2. The way release branching is done at the moment is a little =20
confusing. I think we should have the concept of tagging an exact =20
release and I think that is the intention for the RELEASE directory =20
which is fine.

But then the 0.10 release branch/tag also had a last minute fix merged =20
into it which confuses things. :) A common way projects handle =20
releases is to branch the trunk into a maintenance branch for that =20
codeline. eg. maintenance/0.11. Then any last minute fixes can be =20
added to this. When the tarballs are actually cut this is copied to =20
RELEASES/0.11. Then if any serious bugs are found before 0.12 is ready =20
they can be fixed on the maintenance/0.11 branch and a 0.11.1 cut from =20
it.

Ben wonders if we have enough people for this, but really it's only a =20
couple of svn commands above what we already do. In the event that we =20
had important bugs we wanted to put fixes out it would be quite easy.

A crucial rule here would be that nothing is ever committed directly =20
to a maintenance branch, only ever merged from trunk. If you follow =20
this it becomes very easy. Only the testing for a bugfix release would =20
be a lot of work but by that time we presumably all think it is =20
worthwhile. And from last time we seem to have plenty of users to help =20
us with that.

> With introducing this page it would be good to re-introduce a bug
> tracking facility - I introduced one last year but it looks as though it
> hasn't really been used, it is all too easy to lose track of bugs which
> are not tracked properly - any ideas welcome... I am happy to host
> whatever solution - or perhaps integrate with the wiki somehow.

Ben did say he was going to install trac, which would be great (works =20
well with svn), but then I think he went to do it and was put off by =20
the difficulty of installing it on OpenBSD. :-(

The problem with hosting these things externally is hooking them into =20
the version control system. If it doesn't integrate properly into svn =20
then it won't get any use. The wiki is rubbish for bug tracking, but =20
fine for feature tracking (much better than a bug tracker in that =20
case). My bug tracking for box consists of keeping emails that discuss =20
bugs in my email folder until there is a bug tracker so I can go back =20
and reenter them. I don't really like it though, folder's getting =20
quite big. :-/

Cheers,

Martin.