> > >> > up to know it was solved via commit hooks on lyx.org server. > >> > i guess we could proceed with lyx.org again, but it would be > >> > substantialy more work than gitorious. do you feel like working on it? > >> > (maybe Lars can help?). > >> > >> I can. If I am to do anything with this I am more likely to go the > >> gitolite way. > > > > Lars, Are you willing to set up a git repo on our server ? Gitolite seems > > interesting indeed. I will have a closer look on it. > > I can look at it. Pity that the server uses debian, I am a lot less > familiar with that.
It would be nice if you could try anyway. I'm sure you'll be able to manage. > >> You really do not want to have all devvies pushing commits. > >> Make a small cabal of people to do this instead. > Hmm.. the LyX devvies are a small cabal of people.. right ? >> This seems in general to be the policy, but I'm not sure I want to have >> too many restrictions. The idea was to let all devvies push into their >> own branches > I don't think that is a good idea. Developers should have their own > _repos_, at the server. > That could be a possibility. I didn't want all developers to create a fork on github or gitorious or the like. However, I don't know how things will be when all devvies have a repo on the the server. Another thing I don't want is that we have to depend on one person to do the merging. If this person does not have time for a while, other people might get angry and demotivated if their features are not pulled into trunk-devel for some time. That's why I proposed that people with svn commit rights would be able to push themselves and merge their branch into trunk-devel. A script will then easily pick up the branch and will put it in the process which will eventually get it to merge into trunk-stable. > (merging to the main repo will not be any harder because of that, but > a lot of cruft can > be kept out. (after all deveopers come and go)) > > > and > > let them merge it into trunk-devel (which is a temporary branch). I will > > then merge > > it into trunk-stable. > > I must admit that I don't see the point in having two trunks. (I see a > real danger in one being tested all the time, and the other almost not at > all.) > The idea is that all features that are well tested and seemed to be ok are merged into the trunk-stable branch. In theory, it should not be needed to extensively test this branch because all separate features have been tested before. Secondly, it will be attractive to much more people to test trunk-stable as it won't have serious problems from time to time. > Sure several release branches might be ok, (even if I'd even then > would prefere multiple repos) The trunk-stable branch will be basically the "release branch". > > In all things git one really should look hard at the linux kernel > development model and see what > would fit and would would require modifcations. > I'm looking at the Git development model and adapted it to our needs and to the feedback I got on the devel-list. Vincent
