2.6 Release Planning-7 (20081205)

Owned by Former user (Deleted)
Last updated: Dec 04, 2008Version comment
4 min read

Attendees

Pete Peterson, Peter Knoop (aka the DJ), Anthony Whyte, David Horwitz, David Haines, John Hall, Jean-Francous, Adam, Megan

Kernel 1 Update (Anthony)

 6 of the 8 that need to be verified. One is flagged critical (Anthony's change on property check KNL-70). Anthony is satisfied but wants someone else to review. Pete will email dev list to see about getting help on verifying the issues so David isn't assuming the entire burden. 

Stealth presentation and mailtool (Anthony)

Anthony wanted to know if this is something that we should do now or if it will impact QA testing. Megan piped up with her opinion (always!) and said it should be fine to do. People testing can use the admin tools to add these tools back in. Anth also pointed out that the QA server local properties could also override this if folks objected

Decision
To go ahead and stealth.

Description
There are 491 pom.xml files in trunk; of these 31 include a <!- copyright statement -> of the type that graces our Java class
files. I'd like to remove these statements in order to maintain 1) consistency across poms as well as eliminate 2) redundancy, given
that the Maven POM definition includes a <license> element that we define in our base pom.xml.

The Maven way: http://maven.apache.org/pom.html#Licenses

(as evidenced in our base pom.xml):

<licenses>
<license>
<name>Educational Community License, Version 2.0</name>
<url>http://www.osedu.org/licenses/ECL-2.0</url>
<distribution>svn</distribution>
</license>
</licenses>

The few projects where the "copyright" poms reside are as follows:

content-review
mailtool
osp
rwiki
samples
usermembership

The osp poms in particular could use a bit of tidying up since their copyright statements include $URL and $Id references that suggest a content project ancestry:

<!--
~

. . . -->

We have not defined any best practice in this area as regards pom files and references to our copyright. Both polls and the
emailtemplateservice poms offer variations on the Maven approach (see below), making use of the <comments> element to embed portions or all of the copyright statement. Whether embedding <license> information explicitly in all pom.xml files is necessary or simply rely on base pom inheritance is a subject worth discussing. I would think that in most cases the latter approach is sufficient, i.e., relying on inheritance, but others may prefer a more explicit approach, especially as we consider a gradual decoupling of our monolithic
release process as has been achieved recently with the kernel.

polls:

<licenses>
<license>
<name>ECL-2.0</name>
<url>http://www.osedu.org/licenses/ECL-2.0</url>
<distribution>repo</distribution>
<comments>Copyright 2003, 2004, 2005, 2006, 2007 Sakai
Foundation</comments>
</license>
</licenses>

emailtemplateservice:

<licenses>
<license>
<name>ECL-2.0</name>
<url>http://www.osedu.org/licenses/ECL-2.0</url>
<distribution>repo</distribution>
<comments>
Copyright 2003, 2004, 2005, 2006, 2007 Sakai Foundation

Licensed under the Educational Community License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.osedu.org/licenses/ECL-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
</comments>
</license>
</licenses>

In any case I prefer the Maven way over inclusion of the <

!-- Copyright . . . . --> statement as has been adopted by a minority of projects. I plan to jira the removal of the <|width=32,height=32!

-- Copyright . . . – > statement from the 29 pom.xml files that include it, starting the cleanup by Thursday, if there are no objections.

Cheers,
Anthony

Actions
Anthony hasn't heard any objections and will start work today. Will start with trunk but also wants to work on 2.6.x. He'll take them out directly.

Conversion Scripts (Megan)

I updated the scripts. Still need to scour the logs to check that everything is in there.

  • Testing on the QA/Oracle instance showed 1 problem. Need to follow up on that
  • Don't have a QA/MySQL script. UCT however is running mysql and hasn't run into any problems
  • Will also put a call out to dev list for others to test scripts.

2.6 Testing Update (Pete)

  • Pete working on getting updates from folks.
  • Pete/Angela is working on templates for reporting testing. Looking for uniformity in reporting.
  • Should get solid feedback from folks in the next week or so.
  • Megan reported on some security testing

Update from UCT (David)

  • Generally, the 2.6 build is looking good. They don't have a single patch applied to their local build - the first time
  • Wrapping up local mods.
  • Some of the issues Stephen flagged are a concern.
    • Most of the new ones relate to the SV functionality: 6 open issues at the moment (assigned to Lance). Not at the moment they aren't blockers for UCT. Would like to see them fixed before Feb.

Misc

Pete mentioned that we'll be cutting a 2.5.4 tag and it should be released before the new year