On Sat, 2009-07-04 at 01:04 +0200, Chris Chabot wrote: > On Sat, Jul 4, 2009 at 12:33 AM, Ian Boston <i...@tfd.co.uk> wrote: > > > > > Scroll down :) > > <snip> > > > > > > I hear what you are saying about getting trunk into production to allow the > > Opensocial and Gadget Developer community to review spec changes, but surely > > anyone pushing to production should be a branch and merging commits to > > stable points rather than expecting head of trunk to be stable at all times? > > If it cant be done with svn because of the rate of change, then perhaps > > cloning the Git mirror of shindig will make a branch viable as it *is* > > (IMHO) better at merging high volume patch streams. > > > > > I kind of tried to cover that in my lengthy rambling too, a lot of the > current contributions are either people developing: > > - spec suggestions > - prototypes for voted in spec changes > - developing new spec items, which they deploy to a sandbox to get > feedback (please do note the *sandbox* part, it's not always directly > live:) > - Someone deploying a recent version of shindig to their platform (you > can easily tell when hi5, linked-in, ning, etc do their upgrade cycle since > that's when we get a storm of patches from them) > > So there is no real 'pie in the sky' type development going on, ie long term > "hey wouldn't it be nice if we did FOO in a couple of months, lets try it", > everything that is being developed is to form the new spec, implement the > new spec, or to fix some issues that came up during deployment on someone's > platform. > > Now while we're implementing a new spec (as we're working on 0.9 support > right now), there's definitely an opportunity for people to jump in and pick > one of the items, especially since the spec is the documentation of what > needs to be implemented; However since we like to see how these things work > in practise so we don't develop a theoretical spec that doesn't work, we > probably do want to keep these iteration cycles relatively short (1 or 2 > months max).
> And while I'm writing this, it also occurs to me that maybe the barrier of > entry for shindig is higher since we implement a spec (so half of the good > stuff, the design, happens in the spec process), and don't really allow wild > changes in shindig that would break away from the spec, or new features that > are not part of the spec (for obvious reasons, if we had 10^99 versions of > OpenSocial, it wouldn't be a usable platform anymore). > > That's probably not so exciting and inviting as some other open source > projects where people have much more of a free hand. (though do note: by > participating in the spec process, you do actually have the opportunity to > help determine the design, it just happens on a different list since we like > the spec to be implementation neutral and not tied to just one vendor or > implementation) Two suggestions: * anyone interested in helping, just come and ask. If shy, feel free to ask me privately * make frequent releases. With frequent releases, the pressure to use trunk is vastly reduced. If there are releases every two weeks, that at least gives me the chance to break things at the beginning of the next release cycle. Folks are more likely to make their release cycles match those of Shindig if it means they get slightly better tested code as a result. Upayavira
