On Wed, Oct 31, 2012 at 11:23:47AM +0100, Lieven Hollevoet wrote:If you try something risky or a redesign, you fork the git repo, do your own
> I understand that we need a phase where we keep both repositories alive. I
> plan to track the changes that are committed to SVN for a while and
> merge them into the git repo. However, I don't really see the difference
> between SVN and git what the risk is concerned. You state that people can
> experiment without putting the SVN repo at risk. I think they can do the
> same without putting the git repo at risk.
and experiment in your playground without breaking the one you forked from.
With svn you can't easily do that. Yes, there are branches, but that's
really not the same.
Small changes would be made in the main repo and ideally reviewed by someone
> I don't see why we would maintain two repositories next to each other for
> a very extended time. What would be the advantage of making a difference
> between small and big changes?
else if they're going to common code. If they're going to a driver that only
you know about anyway, then getting a review isn't as useful.
I mis-spoke and you are correct. Sure, you can add accesss for my marcmerlin
> I tend to disagree. There should never be a single person (and hence a single point of failure) maintaining the main source tree. If you want access, please let me know and I'll add you as a collaborator to the git MH repo.
That sounds reasonable to me. You seem to have more time and know git better
> As the last tag was set more than 5 years ago, wouldn't it be time to create a new one that people can download? There has been some discussion on this topic some time ago. Anybody has an idea on the naming convention to use? I think we would need one for the master branch and a separate one for the insteon branch.
than me, and have my full blessing :)
Cool. Good job doing a nice import.
On Wed, Oct 31, 2012 at 11:13:58AM +0100, Lieven Hollevoet wrote:
> One immediate advantage is that github allows for easy comparison between the trunk (called 'master' in git) and the insteon branch:
Right. That's indeed much better than a diff by email.
> One important thing to do is to make branches for every change you plan to share. This means every change, even if it is a typo fix. You can do this in your own repo very easily. The reason to do this is because then you can easily create a so-called 'pull request' for the branch you made. This pull request will show up in the original repo (the one that I created) and can be applied to this repo with a single push of the button (currently only by me, but read on...).
Don't know how much review time I'll have yet, but now you only need at
> Next to the previous way of working, I will give other people that are willing to help full access to the repository I created. This means that they can immediately create branches in the main repo, commit to it, and that they too can accept pull requests for inclusion in the main repo. If we can come to some 5 or more people that are willing to help maintaining the repo in this way, I think we should be able to manage proposed changes to the MH code base quickly and efficiently.
least another 4 :)
Do however compare with patches people write on their own copy and are never
On Wed, Oct 31, 2012 at 09:49:44AM -0400, Jason Sharpee wrote:
> I love github and use it both personally and professional, however, I have
> mixed feelings about moving this to GIT. I dont know if MH can survive
> anymore fragmentation.
able to even contribute back at all (the current state).
I appreciate the kind words :) but I really only added a few drivers and
> Marc has done a wonderful job of keeping a working version going and having
fixes for stuff I found. Like a few others did too.
Lieven pointed out how we can have a master branch on github, so I don't
> a single official SVN repository makes that easier. Github is going to
> enable all sorts of interesting development, but with the lack of any sort
> of standards and unit testing in the code base I doubt any of the branches
> will be of any greater success than the one Marc is maintaining.
think it's a great fragmentation problem. If it all goes to hell somehow
(don't think it will), we can still go back to the svn branch though.
That's a bit job with no one to currently do it though.
> My 2 cent advice would be to focus some effort on determining what the core
> functionality is, get some unit tests to cover it, and deprecate the other
> code before moving it to yet another repository.
I also still don't see the point of deprecating drivers. Them being there
does not hurt and can only help some if they do have the hardware.
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/