[p2pu-dev] Suggestion for developemnt process

[Jessica Ledbetter]

Would we like to try out a new coding/testing schedule this milestone?
If so, the first week is almost up.

I've started filing bugs on the current code in github (and looks like
Zuzel and Vladimir have knocked them out -- awesome!). I put them as
0.6 milestone so that we can fix the dev bugs before going into
production. Does that work alright? Or should we do a more sprint
mentality where we all focus on finding/fixing bugs at the same time?

I have a few tasks to do this weekend then can focus on finding/fixing
bugs introduced in 0.6 or continue new "functionality."

For what it's worth, I love the idea of an alpha/staging server that
exposes the release before the release so that people can test. Can
we?

On Wed, May 11, 2011 at 1:54 PM, zuzel.vp <zuzel.vp at gmail.com> wrote:
> We just have django tests -->
> http://docs.djangoproject.com/en/dev/topics/testing/
>
> At this point i think a CI server is an overkill but in the future
> when the project grows it will be nice to have it.
>
> --
> Thanks,
>    Zuzel
>
> On Wed, May 11, 2011 at 7:06 AM, Nadeem Shabir <ns at talis.com> wrote:
>> Zuzel what level of automated testing do we have at the moment?
>> I'm a little out of sync with our current development process ... but ...
>> Should the development process not be tied into / supported by a continuous
>> integration process? I.e. every check in into trunk is checked out by a CI
>> server that builds, deploys, and runs any automated tests.  Should we be
>> aiming to have a suite of unit tests, and a suite of acceptance or more
>> functional tests written in something like Selenium that verifies that the
>> application is working consistently across different browsers.  I've been
>> using tools like SauceLabs to run a Selenium based test suite against
>> multiple browser and os versions - and the net result is all developer
>> checkins are tested automatically by the build server, which obviously means
>> releases can then be deployed to live with confidence.
>>
>>
>>
>> On 11 May 2011 10:15, Philipp Schmidt <phi.schmidt at gmail.com> wrote:
>>>
>>> On 11 May 2011 03:49, John Britton <public at johndbritton.com> wrote:
>>> > This is part of the argument against moving to the new site earlier. I'm
>>> > not
>>> > opposed, but because we're going to have more and more real users on the
>>> > new
>>> > site we'll have to spend a fair amount of time making sure things work
>>> > before we push them. The alternative is to be ready to fix things if
>>> > they
>>> > are broken after we push them (I tend to prefer this approach).
>>>
>>> I suspect the right solution is somewhere in the middle. The old site
>>> is really starting to hurt us, and it would be great if we could move
>>> sooner rather than later. But I agree with John that we don't want to
>>> slow down development too much, and we also don't want real users to
>>> get frustrated by serious bugs. Could we keep pushing (push-then-fix)
>>> for now, and start increasing the testing / staging phase by a day at
>>> a time as we take on more users?
>>>
>>> It might also be useful to have an alpha.p2pu.org where those with
>>> interest and time, could always access the latest snapshot of
>>> development progress, and help test.
>>>
>>> P
>>> _______________________________________________
>>> p2pu-dev mailing list
>>> p2pu-dev at lists.p2pu.org
>>> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>>
>>
>> _______________________________________________
>> p2pu-dev mailing list
>> p2pu-dev at lists.p2pu.org
>> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>>
>>
> _______________________________________________
> p2pu-dev mailing list
> p2pu-dev at lists.p2pu.org
> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>



-- 
Jessica Ledbetter
http://jessicaledbetter.com