[Commotion-dev] Draft Roadmap

[Hans-Christoph Steiner]

On Jul 27, 2011, at 9:07 AM, Josh King wrote:

> Hey everyone,
>
> I have published a draft roadmap for the project at:
>
> http://tech.chambana.net/projects/commotion/wiki/roadmap
>
> This is rough so far (and software focused, still working on adding in
> more documentation and outreach tasks), but I think serves to give an
> overall view of how the project is laid out and where it's heading.
> Recognizing that the project is made up of a large number of different
> pieces on different platforms, I've made a few structural decisions as
> far as the roadmap (and a coincident refactoring of the website):

Its good to see a overview of the time and the chunks.  I just noticed  
that you have listed "native mesh network configuration GUI" for  
Windows and Mac.  That sounds like the best plan in the long run, but  
perhaps it makes sense to have a cross-platform Java or something GUI  
to get the ball rolling.  I'm not sure yet which approach is best in  
the time frame.  Writing native apps for each platform will be more  
work, but I'm a big believer in having things feel seamlessly  
integrated, and often native apps are the most effective approach.

> * The project has been re-structured into a number of subprojects,  
> as it
> didn't make sense to me to put a large number of projects with
> substantially different codebases into one git repository. I realize
> that if we end up having a large shared codebase at the end then we  
> may
> want to re-integrate, or create a shared repository drawn on by all
> sub-projects. Other people may have other takes on this. In any event,
> there are subprojects "Commotion-Openwrt", "Commotion-Android",
> "Commotion-Windows", etc. I hope that this will also help to clarify
> confusion between Commotion the overarching project and Commotion the
> OpenWRT embedded firmware (now Commotion-OpenWRT). All issues from
> subprojects are visible in the existing "Commotion" superproject.

I agree it makes sense to split up into multiple git repos.  The most  
useful rule of thumb I've seen for where to make the dividing lines is  
thinking about it in terms build automation: any commit to a repo will  
trigger a build, is that build going to be relevant to the commit?   
One example we have is an app suite for J2ME, Blackberry and Android.   
All Java, all the same goals and features, currently all on git.  The  
J2ME and Blackberry code ends up being very much interwoven, while the  
Android code ended up being unrelated.  The next step might be to  
split out the common Java code into a library, then make separate git  
repos for J2ME, Blackberry, and Android.

The Android OS is also a good example, it is made up of many many git  
repos. That reminds me of another rule of thumb for where to set the  
dividing lines for git repos:  ideally, it should be possible to have  
the git commit messages make sense without having to add the context  
to the message itself.

.hc

> * The roadmap is structured into a number of 'releases.' The first one
> is a pre-release at the end of October, which will serve simply to  
> pull
> together all of the disparate software elements in their current form,
> as well as give me some time to work on some features for the
> Commotion-OpenWRT firmware to bring it up to feature parity with some
> other firmwares out there in order to make it more useful to the
> community networks we're working with to deploy and test it. Past  
> that,
> there are 4 "Developer Releases" which are split up in roughly 2-month
> increments through the year, with a "Finished Release" next summer. I
> structure it in this way to recognize that we need some general
> milestones to hit, but that each piece of component software has its  
> own
> versioning and there's no need to try and change that, and the DR1-4
> naming scheme is not likely to strongly conflict with any other
> versioning scheme in use. Feedback around this is welcome, and the
> timeline is likely to change slightly as the release date as  
> required by
> OTI's Internet Freedom grant award is predicated on when we actually  
> get
> the check from the US State Department, which is not yet.
>
> I'm currently still putting items from the roadmap into the issue
> tracker as it makes sense, and adding users from the existing project
> into the subprojects (Redmine doesn't automatically migrate them).
> People should feel free to add to the roadmap for now, just ping the
> list when you do so to help me keep track of what's changed.







----------------------------------------------------------------------------

Programs should be written for people to read, and only incidentally  
for machines to execute.
  - from Structure and Interpretation of Computer Programs