Repository cleanup and build system

[Felix Morgner]

Hi Martin

I'm still currently working on the timeout issue reported by one user. While working on this i came to wonder if:

1. we should fuse the branches back together into the master branch and have only two branches (master,experimental)

2. why the project uses autotools.

Let me explain in a little more detail. First off the branches thing. I feel like most of the branches don't undergo any development anymore and the only real work is done in the ipv4 branch. It looks to me, that it would be a better idea to merge (or drop if they are outdated the) the old branches back into master (as at least to me it looks like ipv4 could be regarded as the stable branch) and remove them from the remote. I believe, that they are not needed anymore and just clutter up the repo. Please correct me if I'm wrong.

Second the build system. Is there a specific reason, why autotools is used in the project? I'm in the process of transitioning to cmake for my fork because i like it a lot more. It is just easier to use when transitioning between different platforms (darwin, linux and netbsd in my case). Could you please explain that to me?

Regards,

Felix

[Martin Johansson]

Hi!

2014/1/10 Felix Morgner <felix....@gmail.com>

Both questions have the same answer really: lack of time. The master branch has ipv6 support but somewhat broken. It was contributed by a user but after merging I realized it was lacking quite a lot of stuff so I started fixing it but ran out of time and energy to make it releaseable. Since other stuff was added in between I created a ipv4-branch before the ipv6 merge and cherry-picked commits to it from master. So now, yes it's kind of a mess.

The autotools stuff was also contributed by a user. I personally have close to zero interest and knowledge about both cmake and autotools.

It'd be nice to just 'rename' the ipv4-branch to master and 'rename' master to a ipv6-branch, but I don't know if that's easily feasible with Git. Do you know a way?

If you want to add cmake support I'd be happy to include it :)

Regards

/Martin

[Felix Morgner]

I know these problems far too well, so I'm totally with you when you talk about time constraints :). I struggle with some of my projects a lot too. 

Renaming branches in git is pretty straightforward. Basically what you need to do is rename the branch locally, delete the remote branch and push the renamed branch. But you have to be careful, you need to have the branch you'd like to rename checked out (at least it has happened to me in the past, that things got messed up when I was renaming a branch that wasn't currently checked out.). The sequence would be as follows:

# git checkout master

# git branch -m master ipv6

# git push origin :master

# git push origin ipv6

# git checkout ipv4

# git branch -m ipv4 master

# git push origin :ipv4

# git push origin master

This should basically "exchange" the branches. Also I think it should not mess with other peoples forks/clones, at least I read that all should be fine :). The important things are the colons in front of the branchname in the first push (git push origin :master) and the third push (git push origin :ipv4) as this basically translates to "delete that branch in the remote" (a more precise explanation can be found here: http://stackoverflow.com/questions/9524933/renaming-a-branch-in-github). If you are running git 1.7 or later you could alternatively do "git push origin --delete master" and "git push origin --delete ipv4" respectively. If you like, I will try this out on my fork, before we mess up the original repo ;).

Regarding cmake, as I said i prefer it because in my opinion, its much easier to handle when crossing platform border as we do. I am currently working on the cmake stuff and hope to have it ready by sunday evening.

Lastly I would be happy to help out on the IPv6 stuff as it would be a great opportunity to delve deeper in to this matter which would be good for my studies in computer science :).

To sum it up, I'll try the branch-magic when I'm finished with the cmake transition and afterwards start working on the IPv6 implementation.

Regards,

Felix

[Martin Johansson]

2014/1/10 Felix Morgner <felix....@gmail.com>

I know these problems far too well, so I'm totally with you when you talk about time constraints :). I struggle with some of my projects a lot too. 

Renaming branches in git is pretty straightforward. Basically what you need to do is rename the branch locally, delete the remote branch and push the renamed branch. But you have to be careful, you need to have the branch you'd like to rename checked out (at least it has happened to me in the past, that things got messed up when I was renaming a branch that wasn't currently checked out.). The sequence would be as follows:

# git checkout master

# git branch -m master ipv6

# git push origin :master

# git push origin ipv6

# git checkout ipv4

# git branch -m ipv4 master

# git push origin :ipv4

# git push origin master

This should basically "exchange" the branches. Also I think it should not mess with other peoples forks/clones, at least I read that all should be fine :). The important things are the colons in front of the branchname in the first push (git push origin :master) and the third push (git push origin :ipv4) as this basically translates to "delete that branch in the remote" (a more precise explanation can be found here: http://stackoverflow.com/questions/9524933/renaming-a-branch-in-github). If you are running git 1.7 or later you could alternatively do "git push origin --delete master" and "git push origin --delete ipv4" respectively. If you like, I will try this out on my fork, before we mess up the original repo ;).

Ok. Sounds like a plan! 

 

Regarding cmake, as I said i prefer it because in my opinion, its much easier to handle when crossing platform border as we do. I am currently working on the cmake stuff and hope to have it ready by sunday evening.

Ok. No stress :)

Lastly I would be happy to help out on the IPv6 stuff as it would be a great opportunity to delve deeper in to this matter which would be good for my studies in computer science :).

That would be great. I really would like it to support IPv6. The current implementation 'works' but it's ugly in some parts and the banlist doesn't work at all.

 

To sum it up, I'll try the branch-magic when I'm finished with the cmake transition and afterwards start working on the IPv6 implementation.

Great! I will merge your pull reqest tomorrow.

/Martin

[Felix Morgner]

Hi Martin

I've made some progress with the cmake environment. It rund on OS X and NetBSD but has still got some issues on Linux. I'm working on fixing them and hope to have them ready in on Wednesday evening. It seems, that at least under Debian there is no pkg-config file for protobuf-c, but I've found out, that there is a default package included with cmake for protobuf support. I just wanted to let you know that there is some progress. If your curious, you can fetch my cmake branch on github and check it out, but if you're running Linux it just might not work.

Felix

[Felix Morgner]

I think cmake should no be ready to roll. I've tested it against Gentoo, Debian, NetBSD and OS X and it's building fine. The only thing i can't answer by now is, if it works for embedded systems but i can't test for that. The original behavior of choosing PolarSSL as the default is of course preserved with the new environment, and it is possible to specify which SSL library should be used via passing -DSSL=<your_ssl_lib_of_choice> to cmake. The "good practice" workflow for cmake is as follows:

- mkdir build

- cd build

- cmake ../

- make

As you can see it is pretty straightforward.

I've also moved the branches around in my repo and it turns out i wasn't to far off with my idea on how to do it. The actual sequence is as follows (nevertheless keep a backup if something goes wrong!):

# git checkout master

# git branch -m master ipv6

# git push origin ipv6

# git checkout ipv4

# git branch -m ipv4 master

# git push -f origin master

# git push origin :ipv4

This does the trick (at least it did for me). The -f in "git push -f origin master" is important, because otherwise git tries to fast-forward merge and fails. With that part of the work done, I'm now going to focus on IPv6.

Felix