[Nut-upsdev] Experimenting with Git and GitHub

Charles Lepple clepple at gmail.com
Sun Nov 27 18:58:38 UTC 2011


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).

> - 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.

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.

> 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.
> 
> 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

> 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.


More information about the Nut-upsdev mailing list