[mc1322x] Contiki tree resync

[Mariano Alvira]

On Fri, Oct 30, 2009 at 11:01:07AM -0400, Jon Smirl wrote:
> On Fri, Oct 30, 2009 at 10:12 AM, Mariano Alvira <mar at devl.org> wrote:
> > On Thu, Oct 29, 2009 at 11:00:42PM -0400, Jon Smirl wrote:
>
> Git is very different than CVS, with git no one else needs server
> access.  Linus is the only person with access to his tree.

Yes. But Linus isn't the only one with repositories on kernel.org ---
which is more what I was talking about. So if there is anyone on this
list who would like to use devl.org to put their repo's in a public
place then please feel free to contact me.

> 
> Everyone else makes patches in their own local git repositories. When
> these patches are ready they get posted to the email list (there are
> git commands for this).

Yes, generally this is the workflow I like.

> Before you approve something, you should make a new branch, apply the
> patch and check it out. If you don't like it, send some email comments
> and delete the test branch. If you like it, merge the test branch into
> your main branch and push the result out. You function as a
> gatekeeper. It's up to you to do some basic testing before accepting
> things into your mainline. Linus does that pretty much full time, but
> his project is a little larger.

Hence the need for "basic testing". Right now we, as well as Contiki,
has "next to none". 

I'd also prefer something "basically automatic".

> In our case this is complicated by the existence of the CVS
> repository. 

> If you could get Contiki to switch to git you could eliminate the need
> for you to do the maintainer role. Adam would end up doing it instead.
> You'd become a trusted lieutenant like GregKH is for Linus.

Well, _I'm_ not going to be the one to email Contiki and tell them to
use git... :)

I feel Contiki might have too many "trusted lieutenants". I see it
more as the u-boot scenario where each developer gets the thing they
need to work, working, however they can, and then they get it into
mainline without much consideration to the overall program. I think
OpenOCD has a similar issue. I suppose it's a challenge for any
software that is meant to run on a variety of hardware. Certainly a
lot of the code for Contiki is nicely modular with clear interfaces
and separations (e.g. RIME). Other places need work. (e.g. coffee and
the sd card interface).

> CVS makes it hard to rearchitect things. There's no easy way to push
> out a repo with a new core API and then get the ARCH maintainers to do
> fixes for their ARCHs and then commit everything simultaneously.
> 
> Maybe they can be talked into doing development in git and using
> sourceforge CVS to simply track the git repo.

I don't know if they can be convinced or not. I'm pretty new to
contiki and haven't seen that discussed on the list. I certainly agree
with you though about CVS making it hard for the ARCH maintainers.

> For my application I need to get the TCPIP support working (either V4
> or V6). I've been playing with V6 and 6lowpan. I keep getting bogged
> down because I'm simultaneously working on a new CPU, with new
> hardware, new protocol (6lowpan), etc. Right now I'm trying to figure
> out why wireshark isn't fulling decoding 6lowpan packets. If I can't
> decode the packets it is hard to see what is wrong with them.

Yeah, that's a whole lot of 'new' to be handling all at
once. 

I haven't done much here. My only experience has been to generate a
pcap from a sniffed channel and look at 802.15.4 frames. 

I have new hardware that I've been meaning to get to. It's a Redbee
ethernet gateway using the ENC28J60 MAC/PHY. We've used that part
before on a PIC based design and uIP. So that takes out some of the
unknowns for us. I've haven't done anything with ipv6 other than to
read a book about it. And I've skimmed the 6lowpan RFCs... looks like
a big mess. My hope is that Dunkles et. al. will sort it out.

-Mar.