[Tinyos Core WG] Instructions for contributing code
Joe Polastre
joe at polastre.com
Fri Dec 1 01:29:10 PST 2006
rathole--;
Point of contrib is that people can (in my opinion) "CONTRIBUTE CODE EASILY"
Institution Name Space is a bad idea because a working group (ie,
something like Apache Labs) should have the ability to commit. If you
want the ability to index by type (ie routing protocol), create a
webpage. That's what they're for, NOT for creating directory
structures.
Let it be a free for all with the only requirement being that a
description has to be provided in the top level directory. Clearly
TinyOS is completely lacking contributions, so any barriers you place
are going to compound the code stifling that already exists.
Best,
-Joe
On 12/1/06, Prabal Dutta <prabal at cs.berkeley.edu> wrote:
> On 11/30/06, henri dubois-ferriere <henridf at gmail.com> wrote:
> > On 01/12/06, Philip Levis <pal at cs.stanford.edu> wrote:
> > > On Nov 30, 2006, at 12:11 AM, henri dubois-ferriere wrote:
> > >
> > > >
> > > > - Top-level organisation: Why organise things by institution name?
> > > > That's in my view one of the drawbacks of the 1.x organization. It
> > > > doesn't seem like a relevant top-level structure (do I typically
> > > > search for "any code from UCX" or for "a routing protocol"?), and it
> > > > also doesn't seem compatible with the hope (I assume that its shared
> > > > by others) that one day a sizeable amount of contributions come from
> > > > individuals working on their own account (like for most other
> > > > successful open source projects).
> > >
> > > The directory structure is mostly for management and to keep related
> > > things close. The index is intended to be the way to find things,
>
> By management, do you mean a convention for managing the directory
> namespace? Since there's no connection between directory structure
> and namespace, I don't see the benefit of this organization from a
> management perspective. Who within, say "UCB", will help "manage" the
> UCB namespace? Will the caretakers do it? Will the first one who has
> write access?
>
> I also question whether this would actually "keep related things
> close." The only relation that is kept close is that the authors all
> labor under the same organizational umbrella or are co-located
> geographically.
>
> > > e.g., "a routing protocol." Levels of indirection considered helpful.
> > >
> >
> > I understand that such a directory structure certainly isnt to make
> > searching and browsing easier.
>
> I would argue that the proposed structure neither makes management
> easier nor keeps related things close in a dimension that is relevant
> to the codebase. But, something organized around functionality, like
> Henri suggests, does make searching and browsing easier and more
> intuitive.
>
> > Can you cite any successful (read: that is not written and used in
> > majority by residents of academia) open source project where things
> > are organised out based on where the author of some module happens to
> > work as opposed to what kind of functionality the module actually
> > offers? I can't.
>
> Value judgement: I think related code being close together is more
> useful than unrelated code created under the aegis of a single
> organzation.
>
> - Prabal
>
> > > Phil
> > >
> > _______________________________________________
> > Tinyos-2.0wg mailing list
> > Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
> >
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
More information about the Tinyos-2.0wg
mailing list