[p2pu-dev] Suggestion for developemnt process

Fri May 13 23:41:21 UTC 2011

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p2pu.org/pipermail/p2pu-dev/attachments/20110513/b53c5297/attachment.html>