I&#39;d be happy to help test new features but at this point am not able to run my own test environment.<br><br>Could the dev server be updated with the new release at the functionality freeze? I&#39;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.<br>
<br>P*<br><br><div class="gmail_quote">On 10 May 2011 18:55, Jessica Ledbetter <span dir="ltr">&lt;<a href="mailto:jessica@jessicaledbetter.com">jessica@jessicaledbetter.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, May 10, 2011 at 12:28 PM, zuzel.vp &lt;<a href="mailto:zuzel.vp@gmail.com">zuzel.vp@gmail.com</a>&gt; wrote:<br>
</div><div class="im">&gt; Forwarding to the development list for feedback.<br>
&gt;<br>
&gt; On Tue, May 10, 2011 at 11:38 AM, Vladimir Támara Patiño<br>
<br>
&gt;&gt;<br>
</div><div class="im">&gt;&gt; Week 1. The big changes are introduced (new features), pull<br>
&gt;&gt; requests of new features are reviewed and possibly integrated.<br>
&gt;&gt;<br>
&gt;&gt; Week 2. Functionality freezes and the developers concentrate in testing<br>
&gt;&gt; and fixing bugs, only pull requests that fix bugs are accepted.<br>
&gt;&gt; Localization is expected this week.<br>
<br>
</div>I agree about paperwork being done close to the release/week 1. I tend<br>
to wait till Zuzel updates the milestones, then grab what I can as I<br>
can. As I mentioned in the community call, last week I didn&#39;t have<br>
much free time so my commits/merges were lower than normal.<br>
<br>
I think we should run tests more on our development code, definitely.<br>
The tests are broken again but we can move that to a higher priority.<br>
For example, if we make changes, we write a test for it? Also, if we<br>
make changes to a model, we make a migration. I like migrations so I<br>
don&#39;t lose all my test data. I guess I could make fixtures but that&#39;s<br>
another step too :)<br>
<br>
We have a few QA experts on the team so maybe they can help us with testing.<br>
<br>
I agree on functionality freezes. I tend to stop development on<br>
Saturday before a release so that Zuzel has time to go through<br>
everything and make sure the code is good. Some things I had problems<br>
testing like the subscribe edits because of the use of the external<br>
site and she needed to test that. Also, I forget about Drupal users ;)<br>
But yes, whatever is needed to allow the best possible testing<br>
procedure is fine by me.<br>
<br>
Also, since we&#39;re an international team, maybe we should figure on an<br>
international cutoff? Example: functionality additions end at 03:00:00<br>
UTC Thursday before milestone release and code commits stop at<br>
03:00:00 UTC Sunday before milestone release.<br>
<br>
Converter: <a href="http://timeanddate.com/worldclock/fixedtime.html?month=05&amp;day=19&amp;year=2011&amp;hour=03&amp;min=0&amp;sec=0&amp;p1=0" target="_blank">http://timeanddate.com/worldclock/fixedtime.html?month=05&amp;day=19&amp;year=2011&amp;hour=03&amp;min=0&amp;sec=0&amp;p1=0</a><br>

<br>
So 0.6 schedule could be:<br>
May 19 03:00 UTC Functionality freeze<br>
May 22 03:00 UTC Code freeze<br>
<font color="#888888"><br>
<br>
<br>
--<br>
Jessica Ledbetter<br>
<a href="http://jessicaledbetter.com" target="_blank">http://jessicaledbetter.com</a><br>
</font><div><div></div><div class="h5">_______________________________________________<br>
p2pu-dev mailing list<br>
<a href="mailto:p2pu-dev@lists.p2pu.org">p2pu-dev@lists.p2pu.org</a><br>
<a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
</div></div></blockquote></div><br>