Re: Nylon liveth (but on in OE?)

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Saturday 02 March 2013 18:46:24 Martin Dietze wrote:
> Nylon is the distribution with which the 4G Meshcube/AccessCube
> was shipped. As a former 4G employee I took over maintainership
> and started re-integrating Nylon into org.openembedded.dev in
> 2009. However Nylon was and still is based on an old toolchain
> and a 2.4 kernel. This lead to increasing problems keeping the
> code buildable, as more and more code would no longer work on
> a basis that old. Thus Nylon is now obsoleted in OE (and I'd
> say rightly so).
> 
> Not having had the time to work on this in the last years I've
> now decided to go the easy way and simply fork at some time in
> 2009 when the code was still more or less working and continue
> from there. The main benefit from using my work rather than the
> original 4G toolchain (which was itself a fork from a much older
> OE snapshot) I see in having a larger set of recipes to add
> components from if needed and also some updated components in
> the base system
> 
> This work has now been done, and I wonder where the code should
> live from now on. I would thus like to ask if keeping my branch
> in the OE repo would be an acceptable option to the project
> maintainers. Doing this we could probably just remove all the
> remaining mtx-[12] artifacts from the .dev branch (I am not sure
> if mtx-3 is maintained by anyone any longer, at least it is not
> by me).
> 
> I know that there's possibly only very few people interested in
> this, but I'd really like to avoid forking completely, also
> the idea of still being able to grab some recipes from the .dev
> branch if needed would be nice, and it would simplify contributing
> for others. If this idea is not an acceptable option for you, of
> course, I can still push my fork to github.
> 
> What do you think about it?

I don't have a personal interest in this particular distro/hardare, but if the 
fork you have made is working then I can't see a compelling reason not to host 
a branch for it in the OE-Classic repository; at least that keeps things more 
or less in one place.

However, is there any chance you'd be able to look at moving up to be based on 
top of OE-Core which is where OE is at currently? Obviously toolchain and 
kernel would be the first hurdles. For bringing any needed metadata up-to-date 
though the community can provide help where needed.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre