[p2pu-dev] Suggestion for developemnt process
public at johndbritton.com
Wed May 11 07:49:24 UTC 2011
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).
@johndbritton - http://twitter.com/johndbritton
On Tue, May 10, 2011 at 10:10 AM, Pippa Buchanan
<Pippa.Buchanan at gmail.com>wrote:
> I'd be happy to help test new features but at this point am not able to run
> my own test environment.
> Could the dev server be updated with the new release at the functionality
> freeze? I'd be happy to test on that. It would also be really useful for
> Ali and I to create screencasts and promotional text about new features if
> we could see it in advance.
> On 10 May 2011 18:55, Jessica Ledbetter <jessica at jessicaledbetter.com>wrote:
>> On Tue, May 10, 2011 at 12:28 PM, zuzel.vp <zuzel.vp at gmail.com> wrote:
>> > Forwarding to the development list for feedback.
>> > On Tue, May 10, 2011 at 11:38 AM, Vladimir Támara Patiño
>> >> Week 1. The big changes are introduced (new features), pull
>> >> requests of new features are reviewed and possibly integrated.
>> >> Week 2. Functionality freezes and the developers concentrate in testing
>> >> and fixing bugs, only pull requests that fix bugs are accepted.
>> >> Localization is expected this week.
>> I agree about paperwork being done close to the release/week 1. I tend
>> to wait till Zuzel updates the milestones, then grab what I can as I
>> can. As I mentioned in the community call, last week I didn't have
>> much free time so my commits/merges were lower than normal.
>> I think we should run tests more on our development code, definitely.
>> The tests are broken again but we can move that to a higher priority.
>> For example, if we make changes, we write a test for it? Also, if we
>> make changes to a model, we make a migration. I like migrations so I
>> don't lose all my test data. I guess I could make fixtures but that's
>> another step too :)
>> We have a few QA experts on the team so maybe they can help us with
>> I agree on functionality freezes. I tend to stop development on
>> Saturday before a release so that Zuzel has time to go through
>> everything and make sure the code is good. Some things I had problems
>> testing like the subscribe edits because of the use of the external
>> site and she needed to test that. Also, I forget about Drupal users ;)
>> But yes, whatever is needed to allow the best possible testing
>> procedure is fine by me.
>> Also, since we're an international team, maybe we should figure on an
>> international cutoff? Example: functionality additions end at 03:00:00
>> UTC Thursday before milestone release and code commits stop at
>> 03:00:00 UTC Sunday before milestone release.
>> So 0.6 schedule could be:
>> May 19 03:00 UTC Functionality freeze
>> May 22 03:00 UTC Code freeze
>> Jessica Ledbetter
>> p2pu-dev mailing list
>> p2pu-dev at lists.p2pu.org
> p2pu-dev mailing list
> p2pu-dev at lists.p2pu.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the p2pu-dev