Re: [Jack-Devel] Get the git repos rolling?

On 25/01/12 03:01, Nedko Arnaudov wrote:
> However the only official jack repo, the repo.or.cz jack2 repo is bad
> target for this. IMO a new repo is needed. So far github and
> jackaudio.org seem to be the best choices. I'm ok with both. github has
> nice colaboration features though. Like pull requests, code comments and
> the nice web based access control management for repositories based on
> teams (groups of users). We can also have a git-shared repo hosted at
> repo.or.cz but this way we loose both github features and jackaudio.org
> identity.

jackaudio.org itself could be hosted at jackaudio.github.com as long as
regular server side scripts are not needed, this way, even the main site
is under Git and forkable for pull requests.

> trac (wiki, bugracker) workflow will somewhat suffer if we choose
> github. If this is actually problemantic we have the option to switch
> bugracker and wiki from trac to github. Data migration needs additional
> research. I'm sure that data export from trac is possible because its
> all in a mysql database but I'm not sure about import features of
> github.

Just start from scratch at github, zero effort. The issue tracker
supports tags so Features and Bugs, even Discussion, can be separated.

It's not an overly sophisticated issue tracker but that could be
considered a good thing for non-techie users. The best part is that
all the issues can be received and REPLIED to via email. That feature
alone is worth the price of admission.

> If we choose to use github we probably want some kind of data backup
> that will not ruin the jack project infrastructure in case of github
> shutdown.

Turn the current jackaudio.org into mirror.jackaudio.org and use
commit hooks to update everything to it. With a 5 min DNS TTL it
could become jackaudio.org fairly quickly, for any reason... or at
least just a cgit frontend to a normal mirrored Git based repo.

> If we choose to use jackaudio.org we will have to handle additional
> administrative tasks. One problem for example is that Trac instance is
> ancient and unsupported upstream. I doubt we will be able to make the
> current trac instance (0.10.4) work with git.

A switch to Github could be all finished in a day. Job done.

If, for any reason it proves unsatisfactory then a move to anywhere
else is almost painless because everything would be in Git. There is
almost no negative downside to moving to Github with the possibility
of a lot to gain... if the move itself only achieves condensing the
whole project to a set of Git repos that ultimately could end up
being hosted elsewhere. In the mean time the Gitub "social coding"
aspect is very real.

1327426916.7773_0.ltw:2,a <4F1EED36.6030500 at renta dot net>