Shindig Stable version and Check-in process

[Rajdeep Dua <ra...@google.com>]

Are we having a process followed while check-ins are made to make sure

   1. Check in by developer in one language doesn't break something for the
   other language., this is especially important as there are some common files
   shared between PHP and Java version
   2. Make sure that the unit tests are run for both the versions are run
   before a check-in is made
   3. Have stable source code tree tagged and documented for reducing
   developers efforts in trying to build and run an unstable version.

Thanks
Rajdeep

Re: Shindig Stable version and Check-in process

[Chris Chabot <ch...@xs4all.nl>]

On Jun 14, 2008, at 1:24 PM, Rajdeep Dua wrote:

>   1. Check in by developer in one language doesn't break something  
> for the
>   other language., this is especially important as there are some  
> common files
>   shared between PHP and Java version

>   2. Make sure that the unit tests are run for both the versions are  
> run
>   before a check-in is made

First of all when ever a patch is to be applied that is known to  
affect one or the other language, there is coordination between the  
developers to make sure it doesn't break things. In my recollection  
this has only occurred twice though, and in general since the nature  
of the 2 versions is so closely related (and we're both implementing  
the same spec) this doesn't and won't happen a lot.

That doesn't exclude the accidental mishaps though where there was a  
hidden bug in one of the 2 languages, take the broken container.js  
configuration parser on the php side as an example .. it's a bit  
kludgy since the json parser in php is much more sensitive then the  
java one, so when a http://uri resource comes along for the first  
time, poof it crashes because it thought it was a comment that was  
meant to be stripped. In such situations, there's enough people using  
the svn repo directly that this will get noticed and fixed a very  
short time after it occurring.

Keep in mind that there is a fine balance between development  
efficiency & easily allowing people to make contributions, and rules  
about how to proceed with contributions. I think that requiring all  
java developers to have and maintain a full PHP deployment on their  
development systems would prevent a good few of our top java coders  
from being able to work on shindig, and visa versa for the php guys.  
It would require something unrelated to their skill set to be able to  
contribute, and that's something i think non of us wants.

In a sense it's the nature of working out of an open source svn repo..  
if it breaks you get to keep both pieces :-)

The version in SVN is usually production ready unless otherwise  
announced. Keep in mind that both versions touch a -lot- of end users,  
 > 200 mil for the java versions and soon > 100 mil for the php  
version ... so believe me when i say we all want to keep things  
running smoothly and if mistakes do happen they are addressed quite  
quickly.

>   3. Have stable source code tree tagged and documented for reducing
>   developers efforts in trying to build and run an unstable version.

Our current intention is to have an release when we completed 0.8  
specification support and we feel it's ready to be blessed as a real  
'release'. Thats what we are collectively currently working towards.

However things aren't often 'unstable' though as mentioned above, so  
even working from svn is quite doable at the moment. Most containers  
take a snapshot of svn when they feel it satisfies their needs and  
work from that . (tools like Piston: http://piston.rubyforge.org/ can  
help with that btw)

	-- Chris

Re: Shindig Stable version and Check-in process

[Kevin Brown <et...@google.com>]

The first two items aren't an issue. The third won't be once 0.8 is fully
implemented and we're ready for our first release, and we won't commit to
not changing anything before then -- we've got to get it right if we want to
have software that's useful. If you have an issue with that, you may want to
wait until our first release. We're not intentionally breaking anything, but
we're also not going to go forward with a bad design when we haven't had any
official releases yet.

That said, define "stable". We have strict requirements on code quality (see
our style guides at http://cwiki.apache.org/SHINDIGxSITE), but that doesn't
mean that there won't be lots of internal change. We're confident enough in
the quality of our project to use it to run the entire OpenSocial deployment
at Google. We're much more cautious about breakages at integration points,
of course, but the internal code changes a lot. That's why we require
thorough tests.

On Sat, Jun 14, 2008 at 4:24 AM, Rajdeep Dua <ra...@google.com> wrote:

> Are we having a process followed while check-ins are made to make sure
>
>   1. Check in by developer in one language doesn't break something for the
>   other language., this is especially important as there are some common
> files
>   shared between PHP and Java version
>   2. Make sure that the unit tests are run for both the versions are run
>   before a check-in is made
>   3. Have stable source code tree tagged and documented for reducing
>   developers efforts in trying to build and run an unstable version.
>
> Thanks
> Rajdeep
>