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

Thu Nov 14 14:38:36 PST 2013

Mark can you work that up into a proposal for inclusion and send it out?
Include some background and maybe ask around the lists for some people that
are running it in production. Then we can discuss it in a thread of its own
and get it voted on.

Cheers
Steve

sent from mobile device
On 15/11/2013 7:43 AM, "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 | 517-980-0228
>
>
>
>   Mark Breuker
> Product Owner
> Tel.: +31 71 5451 203
>
> Leidse Onderwijsinstellingen bv
> Leidsedreef 2
> 2352 BA Leiderdorp
> www.loi.nl
>
>  ------------------------------
>
> [image: 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> 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 | 517-980-0228
>
>
>
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20131115/70e435bf/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 4378 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20131115/70e435bf/attachment-0001.gif 