[En-Nut-Discussion] RFC: Moving to github

Ole Reinhardt ole.reinhardt at embedded-it.de
Thu Jul 23 00:58:48 CEST 2015


Hi Uwe,

Am 20.07.2015 11:52, schrieb Uwe Bonnes:
> beside the current storage problems and the questionable new sourceforge
> philosophy (some seamingly dead projects were taken over and ad-ware was
> added) Soureforge offers:
> - Good product presentation pages
> - Mailing lists
> - bug tracking
> - multiple adminstrator access

Which of those services do we use now?

- The Website is hosted by Egnite
- The mailinglist is hosted by Egnite,
- Do you use your administrator account regularly? And to do what?

Ok, bug tracking. To be honest, the SF bugtracker for our project is not
really used, isn't it? And the issue system of github offers at least
more or less the same functionlity.

> Free Github only offers "issues" and "pull requests". 

At least you can also colaborate with several team members on one git
repo on github. We do it practice with our hackspace github group.

> Git vs SNV can be
> decided by the user himself with "git svn" and the git svn tarball offered
> on sourceforge. 

git-svn is a way to deal with SVN using a local git repo. But it realy
is not a solution. In practive it makes things only more complicate and
does not offer you the benefits of the different git workflows, if you
want to collaborate with others and do not want to work on your local
repo copy.

> So I am not so fond on a switch to github.
> 
> B.t.w. I urge developpers to use git-svn.
> This would help against commits like
>     git-svn-id: svn+ssh://svn.code.sf.net/p/ethernut/code/trunk@6084 1ca430b3-8271-4a6b-9b0e-3dcac98a8924
> 
> nut/crypto/sha384.c:3: trailing whitespace.
> + * 
> nut/crypto/sha384.c:5: trailing whitespace.
> + * 
> nut/crypto/sha384.c:6: trailing whitespace.

Yes, some extra whitespaces might have got cleaned up automatically...
But does this realy matter?

This is a good example where a real git workflow would help me a lot to
maintain the Nut/OS axtls Port. axtls itself is an own project, which I
patched and integrated it into Nut/OS. So with each new axtls version I
also merge the patches to the Nut/OS repo.

The facility to pull changesets from different origins together with the
fork or feature branch workflow would help me a lot to keep track of
both projects and to merge axtls changes into Nut/OS.

Bye,

Ole

-- 
kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de


More information about the En-Nut-Discussion mailing list