← Back to team overview

software-store-developers team mailing list archive

Re: Acceptance Criteria and Software Center

 

On Wed, Nov 9, 2011 at 5:45 AM, Aaron Peachey <alpeachey@xxxxxxxxx> wrote:
> Hi all,
>
> Sorry for the long period of absence and silence - my work has been
> taking up all of my time and for the foreseeable future I can't see
> much changing so it's unlikely I'll be writing much code for at least
> a month or so. Keen to get back into asap though!

Hi Aaron! I hope you're able to do some interesting stuff for your work :)

>
> Congrats to everyone on achieving some great progress with the release
> of USC in Oneiric.
>
> Re Gary's policy, it all makes sense and will be a good control
> mechanism for us to ensure quality.
> Having written a few changes for rnr-server and experienced a more
> stringent merge proposal process I envisage USC moving more towards
> that type of thing, where relevant unit tests and written and passing
> in order for a peer review to be approved. Something we don't
> necessarily do when proposing merges for USC is write test cases and
> run all tests to ensure we haven't regressed anything.

Given that you're one of the few client-people who have contributed to
rnr-server, it'd be great to capture more of your thoughts there, so
that we can together improve and evaluate the way we do this (it may
be that our server-side review process has been too stringent?) In
particular:

 * how could the process of getting your branch landed been more fun
(or less frustrating)?
 * was it clear that you weren't required to write the tests yourself
- or how could that have been clearer, or was it even a helpful
suggestion?
 * given that you did go and write the tests (and wrote great tests
:-)), after your branches landed, did you feel that it was a
worthwhile experience, or something that you'd find easier next time,
or something that you'd avoid next time?

And this last question comes more from the fact that I (personally - I
know everyone is different) find writing tests first much more fun
(and often in my limited experience, leads to better implementations):
 * Does your experience leave you feeling interested in trying a
branch (not now of course, just when you've time) where you go through
the pattern of: (1) write test that fails, (2) implement the fix and
confirm test passes, (3) refactor if necessory, or leave you with no
motivation (or somewhere between)?

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?

> When I'm trying
> to get changes written I hate nothing more than fixing regressed tests
> and essentially it means a longer lifecycle time and potentially more
> re-work until a change gets merged

Yeah, I hate that also. But I see that as either (1) an issue with the
state of the test suite, (2) an issue with the state of the code base,
or (3) an issue with the process I'm using to make my change. From
memory, you experienced (1) with one of your branches (a test that was
failing when run against Postgres that wasn't related to your branch),
and that was something that we could improve (we weren't at the time
running our tests against Postgres), and did improve - hopefully
reducing the pain for us all in the future.

> but the quality of trunk as a
> result of the process should be higher result (and the number of bug
> reports for anyone using development releases should decrease)

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

Thanks Aaron, and totally understand if you don't have time to reply :)

-Michael

>
> cheers
> Aaron
>
> On 11/9/11, Michael Nelson <michael.nelson@xxxxxxxxxxxxx> wrote:
>> On Tue, Nov 8, 2011 at 4:50 PM, Michael Vogt <mvo@xxxxxxxxxx> wrote:
>>> On Mon, Nov 07, 2011 at 08:08:19PM -0500, Gary Lasker wrote:
>>>> Hello Software Center devs!
>>> Hey Gary,
>>>
>>> [..]
>>>> And make no mistake, the idea here is to increase development velocity
>>>> by increasing code quality and knowledge sharing, etc. It is most
>>>> definitely *not* intended to slow things down with heavyweight
>>>> processes. In fact, the changes for our team will likely be fairly
>>>> minimal as we already have all of the important pieces in place in our
>>>> process today (code reviews, automatic unit tests, etc.).
>>>>
>>>> Further, we, as a team, have the freedom to implement the processes in
>>>> such a way as we see fit to make them work best for *our team*. The idea
>>>> is to *increase* the enjoyment and satisfaction we all get from our work
>>>> on Software Center. If at any point anyone feels like the opposite is
>>>> happening, let's talk about it right away and fix it.
>>> [..]
>>>
>>> Thanks for this great summary of the changes. I can only second what
>>> you wrote, I want this to be something that we enjoy doing and were we
>>> feel that folllowing these principals of peer review and good test
>>> coverage gives us better code as a result (and better code leads to
>>> more fun, right ,)
>>>
>>
>> On that note, read jml's "How to feel better (or, some tips on
>> refactoring)":
>>
>> http://code.mumak.net/2011/11/how-to-feel-better-or-some-tips-on.html
>>
>> which is not strictly about writing tests, but how to continuously
>> improve your code so you can enjoy programming more :)
>>
>> --
>> Michael Nelson
>> Canonical Ltd.
>> +49 176 491 53481 (mob)
>> michael.nelson@xxxxxxxxxxxxx
>> IRC nick: noodles (noodles775 on Freenode)
>> Ubuntu - Linux for human beings | www.ubuntu.com | www.canonical.com
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~software-store-developers
>> Post to     : software-store-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~software-store-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~software-store-developers
> Post to     : software-store-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~software-store-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Michael Nelson
Canonical Ltd.
+49 176 491 53481 (mob)
michael.nelson@xxxxxxxxxxxxx
IRC nick: noodles (noodles775 on Freenode)
Ubuntu - Linux for human beings | www.ubuntu.com | www.canonical.com


Follow ups

References