← Back to team overview

software-store-developers team mailing list archive

Re: Acceptance Criteria and Software Center

 

On Thu, Nov 10, 2011 at 10:20 PM, Michael Nelson
<michael.nelson@xxxxxxxxxxxxx> wrote:
> 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, this is exactly correct. I had three separate
experiences running a bootstrap on two different machines (one with a
VM) and each time I ran into the psycopg missing dependency but every
time couldn't remember how I had fixed it the last time!
And the 9.1 vs 8.4 for pg versions was the source of my inability to
connect to the local pg db. Although my workaround was to peel back to
8.4 and then hack the debversion code to make it work!

Thanks again
Aaron

> 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.
>


References