Re: RFC: Moving to github

Thiago,

On 22.07.2015 14:13, Thiago A. Corrêa wrote:
> On Wed, Jul 22, 2015 at 6:42 AM, Harald Kipp <[email protected]> wrote:
>> 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?

Reality is, that you cannot verify every patch when it is committed. One
day you need a new feature, which is only available in a newer version.
Let's say, your app compiles fine with the trunk, but the linker fails.
You can

1. Patch your old version locally with the new feature.
2. Try to find the cause.

It's a fact, that most developers choose option 1. But lets assume, you
choose option 2 and found the trouble caused be a bit banging driver,
where someone (for the best) replaced the AVR-specific driver with sbi()
by a generic driver using NutGpioSetBit(). Now you can

3. Patch the new version locally with the old driver.
4. Start a mailing list discussion to get this reverted.

Again, most developers will choose option 3.

Wouldn't it make more sense, to create a public fork instead of your
local patch, so other AVR users can benefit and, after everything is
working as expected, offer your change to your upstream repository. If
it is rejected, you still have your working repo and if it is public, if
may also solve my problem.

Not best example, I agree. But who of you knows, that it is typically
bad for a global function to return an int8_t instead of an int? ARM
developers might know, but they may think: "I cannot change this,
because it may hurt 8-bitters." How should they know, that an AVR8 never
returns less than 16-bit.


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

Come on! :-) I'm regularly developing the same application on different
platforms. Higher level application development is much faster on
Ethernut 5 or on a desktop PC with lots of RAM. This portable API is an
essential feature of Nut/OS. Any repository, which doesn't honor this,
won't get much attention. But if a repo optimizes global code by
replacing lots of ints by int_fast8_t (where applicable), I'd support it
and then replace some int8_t with int_fast8_t. That would make the code
better for 8 and 32 bit.


> Merging and cherry picking is a lot easier with git than svn.

Typically yes...except those horrible hashes compared to SVN rev
numbers. The concept of Git is an advantage, but the "user interface"
for daily tasks is horrible, IMHO.


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

Yes, local forks. I'd like to have them available in the public.


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

No, you got me wrong here, see above. Unmergeable code will appear, no
question, like it appeared in Android. But that's not a real problem.
Both, Android and distris based on Linus' master have specific
advantages and can run on different platforms.

Regards,

Harald

P.S. Nobody has the intention of making Nut/OS unportable. Based on
Walter Ulbricht, in response to a question by Annamarie Doherr. ;-)

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion