[WG: Sakai QA] [sakai-pmc] [Building Sakai] [cle-release-team] Proposal: towards a releasable trunk for Sakai 10 (and beyond)

Berg, Alan A.M.Berg at uva.nl
Thu Nov 14 13:03:20 PST 2013


Another excellent EDIA tool, used by many institutions.
Don't mind QAing if it gets included.

Mark Breuker <mbreuker at loi.nl> wrote:



Hi all,

May I suggest to include the Skin Manager tool in the main distribution? It has been around for quite some time and makes it much easier to deploy new skins into a running Sakai instance.

https://confluence.sakaiproject.org/display/SM/Home

Also I think there are quite some institutions running this tool although I don't have any hard evidence. Perhaps people using it can reply to this message ("Say aaai!" :).

The latest version is compatible with Sakai 2.9.x I would be willing to put some effort in making it compatible with Sakai 10.

BTW: what are the criteria for inclusion?

Cheers,

Mark
________________________________
Van: sakai-dev-bounces at collab.sakaiproject.org [sakai-dev-bounces at collab.sakaiproject.org] namens May, Megan Marie [mmmay at iu.edu]
Verzonden: donderdag 14 november 2013 21:16
Aan: 'Anthony Whyte'; Adrian Fish
CC: Sakai QA; sakai-pmc at collab.sakaiproject.org; Developers Sakai-Dev; cle-release-team at collab.sakaiproject.org
Onderwerp: Re: [Building Sakai] [WG: Sakai QA] [cle-release-team] Proposal: towards a releasable trunk for Sakai 10 (and beyond)

When would be the cutoff for those proposals?    Work that will be in prior to the January branching?

Megan

From: sakai-qa-bounces at collab.sakaiproject.org [mailto:sakai-qa-bounces at collab.sakaiproject.org] On Behalf Of Anthony Whyte
Sent: Thursday, November 14, 2013 12:54 PM
To: Adrian Fish
Cc: Sakai QA; sakai-pmc at collab.sakaiproject.org; Developers Sakai-Dev; cle-release-team at collab.sakaiproject.org
Subject: Re: [WG: Sakai QA] [cle-release-team] Proposal: towards a releasable trunk for Sakai 10 (and beyond)


How do we decide what the v10 capabilities are?

The proposal process.  There are a number of new capabilities/new practices that people have suggested for Sakai 10 (e.g., signup, roster2, help content).   For instance, expect a lazy consensus proposal from Steve Swinsburg regarding roster2 inclusion in the next day or so.  Other contrib candidates for inclusion need to surface an actionable proposal on the sakai-dev list (at a minimum) or risk being left out of the release.

Additionally, Neal is tracking other trunk changes targeted for 10 [1].  My understanding is that the list of tickets noted on the page may need updating but it will give you a sense of where new development on current capabilities is occurring.

Proposal-making is not limited to PMC members.  Any contributor can offer a proposal on issues of import to the community.  At a minimum it should be raised on the sakai-dev list (other lists may also require notification).   Provide a rationale, make sure the proposal is actionable (i.e., backed by a solid implementation commitment--no unfunded mandates please), and provide ample time for objections to be raised.

Note that in the proposal below, I neglected to list a close date for the raising of a material objection.  I'll make it five business days or Wednesday, 20 November 2013.

Cheers,

Anth

[1] https://confluence.sakaiproject.org/pages/viewpage.action?pageId=86245732


anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu<mailto:arwhyte at umich.edu> | 517-980-0228


Mark Breuker
Product Owner
Tel.: +31 71 5451 203

Leidse Onderwijsinstellingen bv
Leidsedreef 2
2352 BA Leiderdorp
www.loi.nl

________________________________

[Nederland wordt steeds slimmer. Leidse Onderwijsinstellingen]

De informatie verzonden met dit e-mailbericht (en bijlagen) is uitsluitend bestemd voor de geadresseerde(n) en zij die van de geadresseerde(n) toestemming hebben dit bericht te lezen. Gebruik door anderen dan geadresseerde(n) is verboden. De informatie in dit e-mailbericht (en de bijlagen) kan vertrouwelijk van aard zijn en kan binnen het bereik vallen van een wettelijke geheimhoudingsplicht. Indien u deze e-mail ten onrechte ontvangen hebt, wordt u verzocht ons daarvan zo spoedig mogelijk per e-mail of telefonisch op de hoogte te stellen, en het ontvangen bericht (en de bijlagen) te wissen zonder deze te lezen, te kopiëren of aan derden bekend te stellen.

P  Denk aan het milieu voordat u dit bericht print

On Nov 14, 2013, at 11:36 AM, Adrian Fish wrote:


Hi Anth,

How do we decide what the v10 capabilities are? In other words how do we find out what we can/should be working on up to the branch date?

Cheers,
Adrian.

On 14 November 2013 15:00, Anthony Whyte <arwhyte at umich.edu<mailto:arwhyte at umich.edu>> wrote:
Proposal
As a community we shift to a "releaseable trunk" mindset.   For the Sakai 10 release, we commence this mind shift by branching trunk to 10.x at the end of January 2014 rather than now, targeting ApereoCamp as the moment we freeze development and branch with a trailing string freeze date set accordingly.  Between now and then we focus development and quality assurance efforts on trunk, generating QA tags at regular intervals directly from trunk for deployment on community-provided/funded QA servers.  Contributors should focus on 10 activities; post-10 development, if any, should be held back in a working branch during this cycle.  Going forward we continue to refine our practices in order to ensure a high quality trunk capable of being released quickly and efficiently [1].

Rationale
By long tradition trunk is branched months in advance of a Sakai *.0 release.  This practice I regard as counterproductive.  Branching prematurely is costly.   It lowers our velocity as well as our agility.  We let trunk quality slip as we attempt to focus our limited quality assurance efforts on the *.x release/maintenance branch.  We burden ourselves with more work; unproductive work.  Our penchant for alpha/beta phasing also has us thinking we need to branch early (I suggest we simply issue sakai-10.0-qaX labeled tags between now, the freeze date and beyond until we've eliminated all blockers and issue the first RC).  We incur additional branch management overhead in the guise of branch managers, additional Jenkins build jobs and branch-specific QA servers long before it is truly necessary to do so.  We let trunk sink to the status of a pass through branch for fixes destined for the *.x release/maintenance branch for far too long a period of time.

There are also timing issues to consider as regards 10 work.  There are a number of potential new capabilities under consideration for 10 that need to be prepped for inclusion, evaluated and moved to the core svn.  I doubt we can get all that done before December.

In short, I propose that we endeavor to put trunk into a releasable state first before we shift our focus to branch activities.  The trick of course is in the determination of when to branch; our ability to measure certainly requires refinement but I believe we are currently capable of moving towards a releasable trunk without adding undue risk to the project.  Moreover, if we shift our QA efforts to trunk earlier an opportunity exists to reinforce the view that Sakai QA is a vital year-round activity rather than a cyclical affair that slowly cranks itself up and down according to our long drawn out release cycles.

Implications
Developers engaging in post-10 work will need to hold back their changes in a working branch until after trunk is branched to 10.x.  That said, developers looking beyond 10 should weigh carefully considerations of 10 throughput if new work is prioritized over bug fixes and other tasks required to prep trunk for the next release. 10 dev activities will require more on-list visibility, the trunk commit stream will require closer scrutiny and the upcoming code and string freeze dates will need to be regularly communicated.

To date, two QA servers (Longsight, UvA) have been committed to the 10 effort.  More will be needed.  Neal Caidin will coordinate the server build up as well as general QA efforts directed at trunk.


A material objection raised by a Sakai PMC member will block this proposal.  Other opinions are welcome, indeed encouraged.  Silence equals consent.

Cheers,

Anth

[1] As Zach Thomas has pointed out we can and should refine our trunk development techniques. See his suggested readings for an outline of new approaches that we can incorporate:

http://paulhammant.com/2013/04/05/what-is-trunk-based-development/
http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/
http://martinfowler.com/bliki/FeatureToggle.html


anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu<mailto:arwhyte at umich.edu> | 517-980-0228<tel:517-980-0228>




_______________________________________________
cle-release-team mailing list
cle-release-team at collab.sakaiproject.org<mailto:cle-release-team at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/cle-release-team


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20131114/6ab2dccb/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nwss_loi8e0757
Type: image/gif
Size: 4378 bytes
Desc: nwss_loi8e0757
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20131114/6ab2dccb/attachment-0001.gif 


More information about the sakai-qa mailing list