Forum OpenACS Q&A: Re: OpenACS 5.1 Released

Collapse
4: Re: OpenACS 5.1 Released (response to 1)
Posted by Don Baccus on
We did apply all "show-stopper" bug fixes but some were de-prioritized for a variety of reasons.

We want to increase our frequency of releases rather than await perfection in each release, because awaiting perfection takes an enternity of time ...

Ideally of course we'd apply every patch - but that would require every patch be obviously correct (they aren't, indeed sometime submited patches are incorrect) and easily tested (patches rarely come with test cases and sometimes not with enough documentation to generate test cases).

An example would be the patch to fix group drops submitted for 5.1.  This patch had a serious flaw: no corresponding patch had been written for Oracle.  We don't want to patch one version while leaving a bug hanging in the other.  Also the patch was a narrow fix for a more general problem.  Rather than apply the patch to PG only that didn't fix the underlying general problem I've been working on a more general solution and will implement it for both Oracle and PG for 5.2.

Hopefully the person supplying the patch won't be demotivated by learning that the bug report and suggested patch have led to an effort to fix a bunch of related problems all at once.

Collapse
5: Re: OpenACS 5.1 Released (response to 4)
Posted by Gabriel Burca on
I was thinking about some of the simple patches that are as you call them "obviously correct" like #480 that adds noquote, or #489 which fixes an obvious SQL syntax error like:

u.first_names || ' ' u.last_name

In the case you mention, I think the patch should be marked "rejected" with an explanation that someone is working on a more general solution. That would also indicate to others that  it might not be a good idea to patch their local copy of oacs with it. At the same time, if the patch is for something that's obviously broken, why not include it for the interim releases until the general fix is available? Even if it only fixes one of the DBs.

I hope patches are not rejected simply because they do not fix both Oracle and PG (as long as the db that's not fixed is left in the same-or-better state after the patch).

Collapse
7: Re: OpenACS 5.1 Released (response to 5)
Posted by Jeff Davis on
The patches you mention are both for things outside core, which is why they did not get applied before the core release. When doing the release, the release criteria is to have no pri2 bugs outstanding on core, and that is burden enough in getting the release out.

If more people step forward to test and apply patches I imagine more would get applied. I am not happy about how many are still outstanding but on the other hand it's a non-trivial amount of work to do it (often more work than the patch itself, eg with a patch for a plpgsql function w/o a corresponding oracle fix or upgrade scripts).

Our track record with this stuff is reasonable in that there have been 508 patches submitted and 421 applied or refused (and many of the current outstanding patches have problems but have not been refused since the patch often points to the problem better than anything else). Oh, and some have been applied but not marked accepted since the person who applied it forgot to do so.

I think people who have been involved with OpenACS see that the current release management has improved enormously (thanks almost entirely to Joel Aufrecht) and I don't think making releases more burdensome is a reasonable thing to do at this point.

That said, I would love it if more people stepped forward to test and apply patches...

Collapse
6: Re: OpenACS 5.1 Released (response to 4)
Posted by Randy O'Meara on
I'm not demotivated. I took the issue to the extent of my experience. I'm glad that it's going even further. Thanks, Don.

/R