[p2pu-dev] Suggestion for developemnt process

Fri May 20 15:00:28 UTC 2011

https://github.com/p2pu/lernanta/wiki/alpha.p2pu.org

On Fri, May 13, 2011 at 7:41 PM, John Britton <public at johndbritton.com> wrote:
> I would like to set up a CI environment in the future, especially so that it
> is easy for new contributors to test their work and know that it passes.
> Right now this may not be top priority, but I do see it as fairly high on
> the list.
> I'm on board for creating dev.p2pu.org or similar to continue pushing out
> new features for testing on non-prod data. In the future I would like to see
> us roll out features as configurable roll-outs. I'll write more on this
> subject when it becomes relevant.
> --
> contact info:
> http://www.johndbritton.com
> @johndbritton - http://twitter.com/johndbritton
>
>
> On Fri, May 13, 2011 at 4:17 PM, zuzel.vp <zuzel.vp at gmail.com> wrote:
>>
>> Lets try out the Thursday feature freeze (midnight EST) to see how it
>> goes. The rest of the time after Thursday we can concentrate on small
>> fixes and translation. I will try to setup a basic alpha.p2pu.org (not
>> the full setup like in production -- and we can improve it in the
>> following milestones) so people that does not have a dev environment
>> setup can try out things before Monday.
>>
>> --
>> Thanks,
>>    Zuzel
>>
>> On Fri, May 13, 2011 at 10:57 AM, Jessica Ledbetter
>> <jessica at jessicaledbetter.com> wrote:
>> > 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
>> > _______________________________________________
>> > 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
>
>