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

[Thiago A. Corrêa]

Hi Harald,

On Wed, Jul 22, 2015 at 6:42 AM, Harald Kipp <harald.kipp at egnite.de> wrote:

> > We would have n people tracking m repositories for each change and
> evaluate
> > if it is worth cherry picking. I don't see it working on the long run. At
> > some point the changes are unmergeable.
>
> For a new project that might become difficult, I agree. Nut/OS is quite
> old and changes done during the last months are quite manageable. To me
> it is more important to maintain backward compatibility. We are still
> using Nut/OS a lot for 8 bit AVR.
>

The problem here is code size, been there. Can't we deal with it in another
way? Make modules or disable features?

Worst case scenario: Nut/OS for 8 bits and Nut/OS for 32 bits, we have 2
versions (branches, repos, forks) instead of n where n is number of
developers or architectures.


>
> It may not work for general changes, like IPv6. But specifically for
> IPv6 I came to the conclusion, that it would be better to create a fork
> and abandon backward compatibility.
>

I'm all for it in a Nut/OS 6.0.
That's what Qt does, major versions may do source incompatible changes. If
we state it clearly should be no problem, we would then simply merge bug
fixes back in Nut/OS 5.x
Merging and cherry picking is a lot easier with git than svn. Or rather
saying, the tool does a better job, one still has to find out how to do it
in StackOverflow website.


>
>
> > The linux kernel has a huge number of different repositories for
> different
> > archs or whatever new stuff someone is working on, yet there is an
> official
> > tree.
>
> Sorry, but this is simply not true. There are many Linux kernel
> repositories, which offer special versions or features, some of which
> will never make it into Linus' master repository or, like Android, live
> side by side for years with little merging only.
>


The only one that can be called Linux is Linus tree, anything else needs
qualifiers such as "fork that does that" or "Android". As I said earlier,
there will always be forks, we don't really need to force them into
existence :)


If we do say, create a repository for each Arch, it would only be natural
to start getting rid of the arch independent layers such as GPIO, typedefs,
configuration system, etc. Unmergeable code would soon follow and Nut/OS
advantages would start to fade.

I use Nut/OS because it allowed me to migrate to different architecture
(not 100% painless, but didn't have to rewrite everything), it has simply
the best serial port driver available, threads, TCP stack and it's source
code is not horrible to look at, unlike alternatives out there.

Ole's BSD like select saved me when I was running out of stack space,
allowed me to reduce the number of threads in an application. Effectively I
have at least 3 people working with me who knows stuff I'm not familiar
with. I wouldn't be able to spend a lot of time tracking 3 repositories for
changes, finding common ancestor and evaluate if change a depend on change
b I don't want to merge (or rewrite). I would on the other hand deal with
source incompatibilities in Nut/OS and adapt my own code that I'm familiar
with to incorporate changes.

I suppose the others feel the same.