Look at the confusion Gregg's insteon branch caused.   Now imagine being 10x more branches due to the ease of branching in Github.    How is the "master" github repo you have going to review all of the pull requests and support all of the regression issues?

I guess what I am trying to say is that regardless of the repo change, how is the community going to handle an influx of new development?   I have been scared to change much in the core because even after 12 years of working with the code I still dont understand what all of the dependencies are to make a core state change or change the loop nature of processing.   

I wrote things like the IVR menu / WAP interface / Telephony, etc that I doubt are in use and add to the complexity of refactoring.  Why dont we just review what we have and deprecate some of this?

-J






On Wed, Oct 31, 2012 at 10:28 AM, Marc MERLIN <marc_mh@merlins.org> wrote:
On Wed, Oct 31, 2012 at 11:23:47AM +0100, Lieven Hollevoet wrote:
> 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.

If you try something risky or a redesign, you fork the git repo, do your own
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.

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

Small changes would be made in the main repo and ideally reviewed by someone
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 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.

I mis-spoke and you are correct. Sure, you can add accesss for my marcmerlin
account, thanks.

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

That sounds reasonable to me. You seem to have more time and know git better
than me, and have my full blessing :)

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:
> https://github.com/hollie/misterhouse/compare/master...insteon

Cool. Good job doing a nice import.

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

Right. That's indeed much better than a diff by email.

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

Don't know how much review time I'll have yet, but now you only need at
least another 4 :)

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.

Do however compare with patches people write on their own copy and are never
able to even contribute back at all (the current state).

> Marc has done a wonderful job of keeping a working version going and having

I appreciate the kind words :) but I really only added a few drivers and
fixes for stuff I found. Like a few others did too.

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

Lieven pointed out how we can have a master branch on github, so I don't
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.

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

That's a bit job with no one to currently do it though.
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.

Marc
--
"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/



--
Jason Sharpee
jason@sharpee.com

5929 Graburn's Ford Dr,
Charlotte, NC 28269
704-405-5893