2.5 Release Planning-5 (20071010)

Agenda

• Update and Review of Action Items
  • Last week there were a number of problems with the tags due to a variety of reasons. We shouldn't expect to see similar problems here on out.
  • Megan's updates on action items: IU will write a newsletter article about the GB for the next newsletter; call out has been made to community for mysql conversion script testers, created a JIRA for move to cp30 on 2.6 SAK-11877, John Bush from rSmart fixed the DB blocker. I have not yet responded to the kernel proposal - plan to do so this week.
• Updates from Development and QA
  • OSP (Erica will only be here 1st 15 minutes so I'd suggest starting with her)
  • Conversion
    • Number of changes occurred this week.
    • One outstanding Blocker for missing piece SAK-10990
    • Currently need community to step forth with testing mysql script as we don't have resources. J.Hall @ UDel has indicated they have an instance to do local testing with, but have not reached that point yet
  • E-mail Notification testing
    • Inbound email is not configured on any QA server. We're working on getting that set up on QA3-US, but it's slow going. Would recommend beginning this after QA tag for outbound. I had a volunteer to coordinate testing, but not sure of their availability right now. Any volunteers? This would involve setting up a site for people to join, posting out different notifications in Assignments, Announcements, Resources, syllabus, Messages, ect).
  • Attachments - Protection for Attachments Directory SAK-10743 - Chuck Severance
    • Folks at CS in Australia testing this
  • Update on Web services Testing - Steve Githens
• The dual between IE6 and IE7: Official Supported Browsers of the Sakai Project
• Review items for inclusion in the .007 tag. (see Below)
• Review of open Blockers: http://bugs.sakaiproject.org/confluence/display/QA/Pre-Release2.5BranchMgmt
• Discussion of Release Proposal: http://confluence.sakaiproject.org/confluence/display/SAKDEV/Kernel+Release - Aaron Z
• Demo Build Changes
  • More Drop down enabled (Peter)
  • Any template changes?

Attendees

Facilitator: Peter Knoop
Scribe: Steve Githens
Other Attendees:

Action Items

Notes

Paraphrased by Steve G

Megan is gone, Peter is taking over today

Open Blockers 8932 Chris is not here
11278 Ian is not here on road for next 48 hours
11211 Chen is not on the call, this is a new
Thomas from UC Davis was about to install the assignment cleaner today to give the assignment problem a try.

<< I got kicked off of skype. Still talking about duplicate issues with assignments. >>

9683 : Meta place holder for upgrades to various things. Done for most things. Upgraded jquery?
11130 : Localization breaking default folders and messages. Anyone from Indiana who can comment.

Erica Ackerman: There is a problem with the profile tool. Changing one persons name can break the profile tool for a number of people.
This is SAK-11876. The action that caused the problem was that I was editing a matrix in one browser as a particular user and then in another browser (IE) logged in as Admin, changed the users name to make it easier and it caused problems. Will file detail in the JIRA.

Update on OSP testing. a number of bugs reported, especially by students at Marist. Some might be feature requests. (Erika leaves call)

Aaron: 11211, is that in there by accident?
Peter: Yeah, it's in there by accident, it's for 2.6.

Peter: Reports from folks doing QA? Pain points?
Next on the agenda, the fixes that have been proposed, no comments on not merging them, so we will plan on merging all of these into the tag that is cut today.
Jim: Are we talking about the ones on the bottom that aren't part of the filter? Mike has been sending things to the QA list, so some of them may not be corresponding.
Peter: Everything is done by emailing Megan and QA on SAK merges.
Jim: ok
Michael: Sounds like we should out a clarification email about this process.
Peter: I'll ask Megan to send out an email about that.
Michael: It looks like this is being pulled straight out of Jira, so you shouldn't have to edit the wiki page at all. Should all come from meta data on the jira.
Peter: Yeah, this is what needs to be clarified with Megan and Andrew. At this point we don't know of any issues that folks have with any of these merges.

Peter: SO that looks like the whole agenda? Any other thing son the agenda
Kate Ellis: I'm supposed to be testing the email notification, and she said it would be configured. It seems to be taking longer than expected, I will send out an email when Megan has it all set up. Any else different to test from last week?
???: We're also checking on some of the url handling.
Chuck: One more thing is to test a couple email clients like Outlook and others make sure they look ok.
Michael: I can help test too, have like 6 email clients here as well.
Peter: It would be great if you save these as test cases as well as you do them in the confluence space.
Chuck: If you can set up a test site and send these test mails to them, we can all subscribe and everyone can check it out. We can continue to chat on the QA server list for a bit to test the mail.
Michael: Could have a matrix of email clients sending and receiving in plain text and html format.
Chuck: And in particular throw in some little attachments.
Kate: I've started a matrix, will complete it and send it to Megan
Michael: Send this to Megan as well.

Aaron: While we're on email, how do we QA the digests.
Chuck: Harder to test because you have to wait.
Peter: No one signed up to test.
Aaron: Not much has changed until we had to patch because it was crashing our database. Fixes this, but could break the rest of the world, just checking to see how it would get QA'd.
Kate: Would like to get a server configured for inbound mail through the mailarchive. Hopefully this will happen next week.
Aaron: Cool, just wanted to check.
Eng: That crashing sound like a different problem than the encoding of the email? Is this a separate issue.
Aaron 11841 fro all the details. Has nothing to do with encoding.

Peter: Any other topics?
Seth: Can we go down the list of topics.

Seth: Protection for attachments directory patch.
Chuck: Did you have questions about this patch. Talked to Jim. Jim thinks my solution is incomplete and dangerous. It would blow up if your trying to create attachments for things like Calendars and stuff. I think Jim was going to be able to fix this.
Jim: The biggest issue, was that if someone was able to write to all those directories, then it is a problem. We're using security advisors to handle these problems. The biggest problem was creating submission to assignments. But they needed permissions in the realm. This should have been taken care of a while back.
Chuck: With Jim's fix this is usable now.
Peter: says it's been fixed in the first tag. Merged in before the first cut.
Chuck: Megan said there were some questions.
Peter: The agenda says to mention.
Jim: This is flagged as a security issue.
Chuck: Weren't we going to change it so we could talk about it in the release notes.

Jim 11651, not a security issue, in tag 002.
Peter: The reason we wanted to make it separate, is so we could surface this has being a change in behavior.
Chuck: This is pretty open, doesn't need to be shielded. Can be listed as a new feature, is the right thing to do.

Peter: This is a feature change from 2.3 to 2.4.

Peter: Moving on down to the new list.
Conversion is here as a topic. Andrew?

Andrew: We've been running them for each QA deployment. What's there seems to be working fine. Nothing there that we're waiting on for conversion from. We restore the old db each time and convert it.

Eng: And Ian's conversion utility for content? I think it's been in since the first tag. We've been doing some tweaking of it, seems ok, but something to look at.
Andrew: Is this automatic.
Eng: Yeah, kicks off some special stuff <missed details>
Andrew: Is there an option to do just in time or all off line?
Eng: There is some code that will never run unless you're in off line mode. At some point you might want to do the offline conversion in order to run the new code.
Andrew: So we should schedule a test for this on the next tag.
Peter: Documentation?
Eng; In an email still, I need to dig it up.
Peter: We should create a jira to make sure it gets in the release notes.

Me: my web service testing update

Peter: IE6 testing. Hoping that folks can get things working with fixes for IE6.
Lance: There are some places that can and cannot twist their users arms. Here at UI we had to unfortunately cut the number of browsers because we couldn't QA all the browsers. What's the answer for Sakai? Our ability to provide fixes for IE6 right now may be limited.
Some suggestions for handling of this as a community. Wondering if institution that depend on IE6 support can do more qa on that browser and perhaps send some fixes.
Eng: Some people sent a specific email to the list yesterday with specific issues. Maybe we need to star a list on confluence with a list of these issues. If the resources tool has scripting issues that fail in some browsers would defiantly do that because it's so heavelily used. Getting a better handling on the magnitude of issues, would be good.
Lance: Point of clarification. When we worry about them less, do you mean by testing or patching? (for various tools). Equally concerned about problems we don't know about.
Eng. Right. Am worried about undiscovered things as well, but we do want to at least have a starting point. I think a lot of the information comes from use in production, and if we get Jira's coming out of production that are pointing to a particular browser, but if there are tools were that isn't a prolbem, then it at least focuses the issue.
Lance: generally agreeing, just want to push back. When we say "We support browsers X, Y, Z". So far we've never have a list of officially supported browsers.
Michael: We have a list of browsers, we have tested with. Probably not ready to change this policy at this point in the release cycle. It's hard to imagine schools making sure all uses have to upgrade to the latest browser. Probably need to anticipate needing support browsers one release back. Should perhaps set a priority on which browsers are fixed first.
Lance: Longer term, from a product perspective, for us to be able to say we have officially supported browsers would be a good thing. One thing that swayed us to remove IE6 was the IE7 high priority update. However around the rest of the world a number of folks are running OS's that don't even support IE7
Michael: Realistic, I don't think we can just say that for us, defiantely need to think one version back.
Peter: hopefully we can rely on schools that do have these browsers with testing and patching.
Michael: The action item here, is that we're getting good information on what browser and version number they are using so that we can build up that information. So hopefully, overloaded folks, like Lance's team, could coach them on how to fix things.
Lance: Nothing new to add. Major question is how do we address these issues as they arise. will have to be a more of a group effort.

Peter: Can continue this off list.

Demo build changes. Megan or Andrew are going to send out a new set of instructions.
Andrew: I've got a note for Megan.
Peter: More drop down? The question was where to run it on? Release and demo?
Lance; Yes and yes.
Peter: Active team on this one to fix bugs.

Haines: Is turning it off not going to be QA'd?
Peter: It has been turned off the whole time?
Seth: It's turned on in the latest release that all the QA servers are using.
Peter: Just asking to try the off situation to see if it works?
Haines: Is there an effort to qa?
Peter: should do at least one qa cycle with it toggled the other way?
Michale: Risk of going one tag with it turned off?
Peter: We get to find out if it works.
Michael: We could loose one cycle of testing for more sites. But it seems to worth it. The other alternative is to split the servers 50-50.
Seth: I think Megan has a plan for this. It's probably only been on for one tag. Should wait for Megan.
Michael: right , should get back to Megan. Would like to be a bit more methodical. If Megan has a plan cool, if not we can forumately one

Peter: Aaron's' release proposal
Az: Wasn't expecting this to be a long conversation. Just trying to get some thoughts about how this may effect the QA process. Just want to get some comments from folks directly involved in QA.
chuck: I had one question as this evolved. Time line, freeze in Dec etc etc. I had though that would be the 2.5 release and that 2.6 is the next release. Just wondering if you feel it would be too rushed. I thought we weren't going to have a 2.5 release. Just wondering if we thin things like content really won't change for a whole year.
Az: May have to defer to Michael. In the proposal there's actually no mention of time, someone else should decide that timeline. We just want to stabilize the kernel for an entire release, regardless of the timeline. Not sure whether that effect something like Content .Up to team members. Mostly want to determine a procedure for getting stability and what not.
Michael: Unfortunately, I'm about to be double booked here and might have to jet. I don't have strong opinions about the timing of this. people at institutions on timelines really need to think hard about the rramification of a septate kernel and enterprise release. One thing we're wanting to achieve with any changes to the release process, is a release at some point of the year, where someone who is not a sakai develoepra can run and deploy with confidence. I think folks can agree that 2.4.0 was not something that was ready for usage. I want to avoid putting releases out for public consumption that don't work very well.
Peter: A lot of folks to have opinions about this, so we probably don't want to make a decision in the middle of QA.
Aaron: what I'm mostly hoping for is for folks to make a decision about the stability issues and the separation of the kernel and rest of packaging.
Chuck: I think the first time we do it, should be after the first of the year, and not a big zip file for folks to download. Should be a refactor. Not sure if there is energy to do it as part of 2.5 since we are panicking. Folks that are in the kernel would have a problem right now finishing 2.5. Would great to make this a 2 part thing of 2.6
Lance: I read an announcement on slashdot about the new Linux kernel feature release. But at the end of the day is that's not going to be in a kernel release. First, is the separation definition accurate. Then for the release, if we are going to freeze, then we could freeze it.
Chuck: You can freeze the kernel today for an entire year.
<<discussion heating up>>
Michael: Since we are over, can we set up a separate hour long call to discuss this issue. Will work with Peter to set up a good time for both sides of the world. Gotta jet.
Lance: Sounds good.
Lance: We have the bridge for 20 minutes, can hang out and talk.
Peter: Need to share the notes.
<<people leaving>>
Chuck: If we try to freeze this today, and something happens, then how do we patch it.
Lance: Not really at that level of detail yet. Need to look at the proposal. However, we have some stuff in there that is pretty stable, so if separate these out, we can really move on with the tools.
Chuck: I'm ok, except for the fact that content hosting is under heavy development.
Eng: If we froze today, then half the things would have to be thrown out, because none of these follow the best practices.
Chuck: This will be useless a the moment until we improve the modularity of our software.
Lance: at a high level like the idea.
Chuck: Yes.
Lance: You seem to be worried more about the logistics.
Chuck: Yes, because you want to freeze today. Let's not code freeze it yet, too many dependences.
L: Not getting hung up on date. the important thing is to separate out the process. should the kernel have any tools? This is a discussion item.
Chuck: That's Az's proposal.
Eng: The cafe is
<< Huge Discussion about how to test a kernel >>

Az: I don't thin we should get hung up on terminology. I don't think Lance is actually suggesting that we freeze the code. I'm talking keeping API's stable. There is no reason that we can't roll new code into a kernel. I want API stability defined for a major release.

<< Discussion cools down, it's agreed that Lance didn't actually mean we should freeze our code tomorrow >>

<< Chuck has to prepare a lecture >>

<< stuff about marking methods deprecated >>

Haines: Sounds like we need a list of API's.
Jim: This will continue to change as Ian and I keep hacking.
Lance: Chuck, I am throwing you a straw dog.
Let's a cut of the kernel API's today. they refactor and come back. The way we validate is by running the 2.5 set of tools against those API's. The kernel development would occur and then we would meet up at the path.
Chuck: I would really like a branch for this scarer stuff that I can check out and see. So we can react to tangible things. We make branches. It's what people do.
Lance: I am making a branch right now so we have something tangible to look at.
Chuck: It's cool. Aaron is cool.
Jim: A kernel project.
Chuck: I'm guessing it would be an externals and then a set of branches for those projects.
Az: Yes.
Lance: Az: Question about QA. Sorry I haven't looked at the proposal. Does the proposal say whether tools should be included. How is the kernel QA's.
Aaron: 2 parter. Tools included: no tool included ideally. But may not be good to enforce first pass.
Jim: Should be no tools the first time around.
Chuck: I understand it can be hard. It's a hard matter to just split all these directories up. If we can implement this it's a pleasure.
Az: Right.
Az. Tests that run at compile time and tests that run after it's starts up. We're shooting for an awesome set of tests that run after the kernel has started up. These are tests to QA the code. The idea behind doing that is that A: We can establish performance benchmarks. along with that we are testing our interoperability that is hard if you have to mock things up. This doesn't replace unit testing, but this important for testing the interactions.
This does not mean we don't need GUI QA testing, but this is an extra layer of awesomeness. It's a long term vision but we have to start moving towards it.
Lance: These are integration tests then
Az: Yes
Jim: my biggest worry, is that Ian has gone through a year and a half of working gone jcr ,and going from branch to branch etc. And now we're talking about
Az: I don't think anyone is suggesting

<< I had to talk, and was unable to type for a couple minutes >>

Eng: Folks with play with .externals then.
Az:

Chuck: Can we have a regular meeting about this. More than just email, so we can throw things at each other.
Az: Sure.

Lance: Depending on the folks on the call, we could meet ea...