[cle-release-team] [sakai2-tcc] 2.9.0 key issues [short] list

[David Haines]

At the moment, given the difficulty of testing the changes, we're leaning
towards not using KNL-725 and KNL-734 at Michigan.

- Dave


On Tue, Oct 30, 2012 at 1:56 PM, Matthew Jones <matthew at longsight.com>wrote:

> Well Seth is on record in the "Sakai Book" with this quote:
>
> "Have you any bad practices for a system admin that you would like to
> share? Running a .0 release. In general, this is a bad idea, but Sakai has
> taken this to a new level. I recommend following the maintenance branch
> (.x) instead."
>
> Right now though it feels like the biggest problem(s) with the .0 release
> are a bunch of things that could really be put into the documentation. I
> feel that whether we release 2.9.0 this week, or wait a month this release
> is a solid release for the people who are either well connected to the
> community, hosted by a commercial affiliate (Longsight has a few clients
> already on 2.9) or involved with the weekly release management process to
> use.
>
> There are a ton of lurkers on sakai-dev out there, many on 2.6,2.7 and 2.8
> who only tune in years after problems are surfaced who will likely still
> run into issues if they don't pay attention to the obvious gotchas that
> everyone on this list knows about.
>
> At the moment we've got-
>
> - KNL-725 - Probably won't want to convert this column for Oracle, I'd
> just change the timestamp in the conversion script and advise Oracle users
> to either restart after every daylight time switch or set the property
> expired at org.sakaiproject.cluster.api.ClusterService=4200
> So that clusters won't expire for 1 hour 10 minutes (default 10 minutes).
> This will catch the daylight expiration in either case.  I don't currently
> have Oracle so can't test this out, and was hoping IU or Michigan would
> commit this change or advise further.
>
> - SAK-22801 - Normally wouldn't be a problem as the node has to crash
> while triggers are being fired. There is a database cleanup workaround, and
> it might not even affect Oracle or all versions of Mysql. There might be a
> property fix that can be added to a 2.9.x release as well, but just useful
> to know about if your system isn't starting up. (Though I've not seen this
> one yet, so seems unlikely)
>
> I'm sure there's other stuff that needs to be better documented like
> optimized cache properties, not to mention all of the other 2.9 properties.
> But nothing that's super serious.
>
> In either case, I'll still go through with releasing rc03 (hopefully
> today). Should the tcc have a vote this week on a "go-no-go" on 2.9.0 and
> waiting until all documentation is done? Or just putting the "Seth
> disclaimer" 2.9.0 release. :)
>
> On Tue, Oct 30, 2012 at 1:15 PM, Neal Caidin <
> nealcaidin at sakaifoundation.org> wrote:
>
>> The Oracle scripts do sound like a potential blocker as well, or if we go
>> forward with the release this week ,  clear release notes.
>>
>> I am starting to feel torn about the 2.9.0 release.  On the one hand, if
>> we can get 2.9.0 released this week (or early next) , then we can make that
>> announcement at Educause, but perhaps more importantly it will enable us to
>> start thinking about what comes next, for 2.9.1 , which will be essential,
>> and then for 2.10. To me, freeing up that energy to focus on the future is
>> one of the main drivers for getting 2.9.0 released.
>>
>> On the other hand, maybe it is worth cleaning these things up before the
>> release, which would mean a delay in schedule. If we cannot announce at
>> Educause, that is a loss, but not the end of the world. I'm more concerned
>> about keeping things moving forward with CLE. Which will keep things moving
>> forward with the CLE more effectively:  moving forward with the release and
>> immediately planning a 2.9.1 with all these things fixed, plus more? or
>> delaying the release, and having a cleaner 2.9.0 but pushing out the work
>> to have a 2.9.1 ?  If we go for an RC04 (which will be necessary because
>> there is no way to get this all in RC03 at this point), we will likely be
>> delayed till December.
>>
>> My gut feeling is that we should push on for 2.9.0, get it out the door
>> and start planning 2.9.1, but I'm open to the alternative.
>>
>>
>> -- Neal
>>
>>
>>
>> On Oct 30, 2012, at 9:55 AM, Seth Theriault <slt at columbia.edu> wrote:
>>
>> > On Tue, Oct 30, 2012 at 8:53 AM, Neal Caidin
>> > <nealcaidin at sakaifoundation.org> wrote:
>> >
>> >> Does anybody disagree with the proposal to move forward with the 2.9.0
>> release?  I would like to hear
>> >> concerns in advance of Thursday's call, if at all possible, especially
>> given our tight timeline.
>> >>
>> >> FYI, I'll highlight these as the top 3 known issues in the release
>> documentation.
>> >
>> > Another very large problem are the Oracle timezone-related changes in
>> > KNL-725, KNL-734, and KNL-735; see a previous sakai-dev discussion.
>> > Now, these are in 2.8 and later 2.7s --so they are not new and not a
>> > blocker -- but we need to do something about them. Matt Jones and I
>> > have been discussing them, but we are not sure how to proceed other
>> > than some possible documentation.
>> >
>> > If you haven't made the Oracle SQL changes, you should probably NOT
>> > make them to maintain current behavior.
>> >
>> > Seth
>>
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20121031/42f22dc2/attachment-0006.html