software-store-developers team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Wed, Nov 9, 2011 at 10:32 PM, Aaron Peachey <alpeachey@xxxxxxxxx> wrote:
>
> On Nov 9, 2011 8:27 PM, "Michael Nelson" <michael.nelson@xxxxxxxxxxxxx>
> wrote:
...
>> I guess where I'm going is that we all want it to be fun to contribute
>> - now and into the future. And that means it needs to be both easy and
>> safe to contribute (safe in the sense that the pain that my branch
>> landing today causes you in 2 months is minimised). Up until now, on
>> the server side, my approach has been:
>>  1) Don't require people to write tests themselves, but if they're
>> keen to try, help wherever you can. Then as a reviewer, implement any
>> missing tests for the branch.
>>  2) Related to the above, encourage small branches (~200-600 lines) as
>> it can be not only painful, but very difficult to write tests well
>> *after* the implementation for large changes)
>>
>> How could that approach be improved, relaxed or changed (or abandoned)
>> - thoughts?
> I agree. I would suggest people should be encouraged to write tests for
> their branches to ensure they understand their changes and catch any issues
> that other ad hoc testing didn't catch (this happened to me a few times!)
> I wouldn't recommend changing much else.

Cool, thanks for all the feedback - i'm glad to hear that you found
the process helpful overall, and are enjoying/appreciating the tests!

>> Yeah, definitely, and also the ease with which someone can safely
>> contribute should continually increase (ie. I know my change isn't
>> breaking anything else).
> My only other comment is around the setup process for a local version of the
> server.  it's reasonably straightforward but not overly well documented and
> the chance to run into issues with the build is high. I'd suggest that
> process needs to be made as simple as possible and very documented to ensure
> the time it takes from deciding to write a change and actually starting to
> write code is minimised.

Right - from memory the issue you had was related to setting up a dev
environment using postgres (rather than the normal sqlite) as the
functionality and test you were writing was specific to a postgres
plugin (ordering by debian version).

I was about to write that if you're using the default sqlite, it's as
simple as `fab bootstrap test`... and then I tried that on a fresh
Oneiric vm, realised that that wasn't the case and created the
following MP:

https://code.launchpad.net/~michael.nelson/rnr-server/improve_readme/+merge/81830

If that covers all the issues that you can remember from your dev
setup experience, please add an approve vote :)

Thanks!
-Michael

Side note: Long term, it'd be great if (1) the process was reliable
with one command, and (2) the dev environment matched whatever our
production servers are using (ie. same OS version and using postgres).
A juju charm may be perfect for this as it hides the complexities of
creating lx-containers (ie. creating virtual network bridges etc.),
allows a local dev environment, but at the same time, allows you to
spin up a powerful cloud instance instead (if you're working on a
low-powered or low-space arm device ;) ). Apparently Ricardo tried
this the other day for sso or pay, but found that the lxc created by
juju didn't survive reboots, so that would be a blocker. Other options
are normal vm's or vagrant etc.