[sakai2-tcc] Strawman - Sakai 2.8 Release Activity Scheduling
Jean-Francois Leveque
jean-francois.leveque at upmc.fr
Mon Jul 26 02:22:00 PDT 2010
Hi,
Looking at the wiki, looks like the feature freeze happens no later than
the ens of Information Gathering on 16-Sep-10 which is about the same
time as the Code Freeze 15-Sep-10.
If we want time between the two, maybe Information Gathering should end
earlier.
I've added a comment to the wiki which deal with lots of issues. Let me
repeat it here.
>
> Personal notes to add to the meeting:
>
> * Help documentation: The reference help documentation in English update should start at code freeze and end before its translation is due. Announcements of English updates ready per help documentation category should be sent to the i18n WG in order to smooth the translation process. I think we need a help documentation coordinator.
> * String Freeze: The string freeze should happen at code freeze to give more time to translators. I don't want 2.8.0 to be lacking translation as much as 2.7.0 is.
> * Translation: If string freeze happens at code freeze, translation of anything but the help documentation should start then with an announcement sent to the i18n/L10n WG. The WG is not the owner of the translations, each language/region/variant is responsible for its own translation. We should also ask for intend to translate or update the translation to the i18n/L10n WG.
> * Information Gathering: Maybe the TCC should own at least part of the Information Gathering. One of us should at least contact in our name all the code owners for code in 2.7 that is not under strict maintenance.
> * Code Freeze and Branch Freeze: How how we avoid anything being committed to trunk between the two? If we cannot, they should be synchronized at least from an svn point of view on a given svn external.
> * Indie Releases: Indie releases should be branched no later than the main branch freeze. All indie work should be at least ready at the same time as main code (Help documentation, String Freeze, Translation ...) and follow the same rules.
>
Maybe the first indie release artifact should be available before the
branch freeze.
WDYT?
J-F
Berg, Alan a écrit :
> Hi,
>
> What QA needs for a good start to testing 2.8 are the new features, what
> changed document. The set of documents is crucial for focusing
> resources for testing and updating changes in help and generating
> release documentation. I would like a coupling between the changes
> document and test plans and use this as the structure for the testers
> wall in confluence. The 2.7 cycle for QA was chaotic, by providing
> better documentation on time will make the process more efficient. Am I
> expected to define a format for the documentation and only test after
> the documentation exists or does the TCC expect the same defacto process
> as 2.7
>
> Alan B
>
> Alan Berg
> QA Director - The Sakai Foundation
>
> Senior Developer / Quality Assurance
> Group Education and Research Services
> Central Computer Services
> University of Amsterdam
>
> http://home.uva.nl/a.m.berg
> ------------------------------------------------------------------------
> *From:* sakai2-tcc-bounces at collab.sakaiproject.org
> [sakai2-tcc-bounces at collab.sakaiproject.org] on behalf of Steve
> Swinsburg [steve.swinsburg at gmail.com]
> *Sent:* 24 July 2010 02:03
> *To:* May, Megan Marie
> *Cc:* sakai2-tcc at collab.sakaiproject.org
> *Subject:* Re: [sakai2-tcc] Strawman - Sakai 2.8 Release Activity Scheduling
>
> Hi Megan,
>
> Actually looking over the doc again, for the main Sakai code, I only
> see a code freeze, not a feature freeze. Could we have a date whereby
> all features that are targetted for the next release are documented and
> Fix Versions set, then later on a code freeze where these features need
> to be implemented (not necessarily bug free) or bumped to the next version?
>
> For indie projects, we could have a similar schedule, but should also
> introduce a date whereby a release artifact must be provided by indie
> project teams, so that it can be included in the QA cycle.
>
> WDYT?
>
> cheers,
> Steve
>
>
> On 24/07/2010, at 12:24 AM, May, Megan Marie wrote:
>
>> Hi Steve,
>> That’s a good point about the indie projects. What do you think
>> would be a reasonable timeframe.
>>
>> Megan
>>
>> *From:* Steve Swinsburg [mailto:steve.swinsburg at gmail.com]
>> *Sent:* Wednesday, July 21, 2010 7:15 PM
>> *To:* May, Megan Marie
>> *Cc:* sakai2-tcc at collab.sakaiproject.org
>> <mailto:sakai2-tcc at collab.sakaiproject.org>
>> *Subject:* Re: [sakai2-tcc] Strawman - Sakai 2.8 Release Activity
>> Scheduling
>>
>> We probably need something that outlines feature freeze and code
>> freeze for indie projects? We have quite a few now.
>>
>> I think the first few stages of the timeline might be a bit early,
>> like tool promotion and deprecation decisions (they are less than a
>> fortnight away). Do we even have a list of these tools?
>>
>> cheers,
>> Steve
>>
>> On 22/07/2010, at 6:27 AM, May, Megan Marie wrote:
>>
>>
>> Hi everyone,
>> At the conference there was consensus that we should release on
>> a time based schedule with a release in early 2011. *I’ve started
>> sketching out the activities that need to occur for a 2.8.0 release by
>> March 1, 2011. *
>> I’ve been doing this using Excel since it’s easier to manipulate than
>> a table in Confluence. The current version is attached and it is
>> also out on Confluence at http://confluence.sakaiproject.org//x/8RkhB
>> <http://confluence.sakaiproject.org/x/8RkhB>.
>> What is missing from this list? Are there items I’ve proposed an
>> insane timeline for? Are the activity ‘Owners’ correct? Past
>> schedules have included a kernel freeze although I can’t remember
>> adhering to one – which begs the question, do we really need it?
>> I’ve purposely left some items off the schedule until the general
>> framework (ie code freeze, tags) of schedule is solid or certain
>> people can weigh in:
>> · Identify times to touch base with QA Leads (Alan, can you
>> weigh in)
>> o Accessibility
>> o Internationalization
>> o Security
>> o Performance
>> o
>> · Potential QA Tag Schedule
>> o Aug 13 - Alpha Tags
>> o Aug 27
>> o Sept 10
>> o Sept 24 - Beta Tags Start
>> o Oct 8
>> o Oct 22
>> o Nov 5
>> o Nov 19
>> o Dec 3
>> o Dec 17
>> o Dec 31
>> o Jan 14 - Release Candidate Tags
>> o Jan 28
>> o Feb 11
>> o Feb 25
>> Looking forward to your feedback,
>> Megan
>>
>> <Sakai_2-8-0.xls>_______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> <mailto:sakai2-tcc at collab.sakaiproject.org>
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
More information about the sakai2-tcc
mailing list