Re: [B.A.T.M.A.N.] RFC: Migration to a new git server backend

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

Hey,

On Sun, Jul 22, 2012 at 01:43:25AM +0200, Sven Eckelmann wrote:
> Hi,
> 
> maybe some of you have seen that I talked in the channel to Antonio whether we 
> should migrate to a different solution to serve our git repositories. This is 
> (in my opinion) a good idea because gitosis [1] (the software that we are 
> currently using) isn't maintained anymore and will be dropped [2] in the next 
> version of Debian. My preferred replacement is gitolite [3].
> 
> I already talked with Simon and discussed what side effect this could have. 
> Maybe side effects is not the correct word to describe it... lets call it 
> options. Gitolite allows to define access rights for refs. For people that are 
> not familiar with the storage in git: You can for example say that people can 
> only commit to branches with a specific prefix.
> 
> Just to give an example. We want that only the release team can create tags -> 
> refs/tags/ is only marked for the release team as read-write. Now we have more 
> interesting features like ordex is only allowed to write in branches starting 
> with ordex/ -> refs/heads/ordex/ is marked as rw for ordex.
> 
> Now the question is: Do we want to use this feature or not. We had following 
> ideas:
> 
> 1. 1 repository per project
> 
>    use only one repo for each project (batman-adv, batctl, batmand, ...) and
>    use branch namespaces for individual users:
>    * master, next, maint for the main stuff
>    * ordex/ (for example ordex/dat), hundeboll/, ... for users
>    * tags only for release team
> 
> 2. 2 repositories per project
> 
>    use one official repo for each project (batman-adv, batctl, batmand, ...)
>    and one for other people
>    * master, next, maint in both repos (synced from the main one)
>    * ordex/ (for example ordex/dat), hundeboll/, ... for users in the second
>      repo
>    * tags in both repositories allowed (but in the second repo only with
>      user prefix)
>
> 3. 1+x repositories per project
> 
>    Keep everything like now
>    * master, next, maint for the main stuff
>    * each user has his own copy of the main repo in his user folder
>    * tags can freely commit in his own repo
> 
> Special repositories with big differences like linux-merge are kept in a 
> special repository.


I'd prefer to go with option one, or maybe two. To me, it looks like having tags 
is the main practical difference? (I don't use any, but maybe others do ...).

Changing the repos is more a cosmetic change IMHO and may decrease administration
work. I have no practical concerns whatsoever, but git.open-mesh.org will look
more beautiful :)

Cheers,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]