2011/11/27 Charles Lepple <[email protected]>: > On Nov 26, 2011, at 6:26 AM, Arnaud Quette wrote: > [...] >> git is an excellent tool, and the one that will replace our good old (NUT) >> Subversion repository. >> github seems to offer nice features, though I've not gone very deeply ATM. >> >> Before we can switch to git, I see 3 remaining points to address: >> - ensure that all active developers are ready to move to git > > What about Eaton's open source team? I think the rest of the NUT team is > ready (looks like Michal Soltys was using some form of DVCS for the apcsmart > updates, and not many other people have contributed recently).
Fred has already worked with git on ext4 Emilien should ramp up easily I'll have to check with Prachi for the transition. Praveen has just quit Eaton, and I don't think Chetan will commit again (gotta check) >> - ensure that continuous integration (Buildbot) will continue to work (not a >> problem since BB supports git) > > Yes, just a configuration issue. > >> - clarify the link between alioth (hosting main git repositories?!) and >> github. >> Ie, will there be an automatic sync between both, as we have with your Trac >> instance? > > Should be possible, but why should Alioth be the main source repository? A > mirror could be useful, in case Github has trouble. works for me > Synchronizing between git repositories is a lot less brittle than between SVN > repositories. We should be able to just "git push <remote>" for each mirror. sure, we can even test it since Alioth has no limitation on multiple VCS. well, the only one is that just one VCS is linked to the users page (https://alioth.debian.org/scm/?group_id=30602) >> Until we have at least closed the 2 latter points, we won't progress much. >> Ie, I'm not going to commit on github, then ask you for a pull request, and >> finally have you pushing back to the main Svn repo... > > No, but the idea was that non-core developers could do that as an alternative > to signing up for an Alioth account, and getting full commit rights to the > repository. ah, right, I forgot that one. As discussed, the only show stopper for switching to git for release is the ChangeLog. But you already know, and there is now a tracker for this too: https://alioth.debian.org/pm/task.php?func=detailtask&project_task_id=487&group_id=30602&group_project_id=327 >> A transient solution may be to: >> - switch BB to git (using github:clepple/nut) >> - have developers switching progressively on git using github, ie clepple >> and aquette first. >> - in the meantime, you (Charles) continue to sync git with Svn, for those >> still committing on Svn, >> - once all active developers have switched, we can also switch Alioth >> repository. >> >> What do you think about it? > > How much of this changes given GitHub's updates to SVN support? > > https://github.com/blog/966-improved-subversion-client-support interesting! I'll dig that since it may be a better transient solution, if needed. >> As a final note, I'm still looking for the Forge that would suits all our >> needs: >> - state of the art UI >> - continuous integration and QA features >> - better general work-flow to handle requests, bugs, roadmap >> - better glue between elements, like being able to close trackers through >> commit (a thing Debian offers for long) >> >> I'm currently considering Tuleap: https://tuleap.net/ >> But there is again the hosting issue... >> Ideas and comments welcome! > > ESR's point about scriptability is key - many of these features are easy if > you have hooks for scripting. true. cheers, Arnaud _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
