Forum OpenACS Development: Release plans for 5.1 (feature freeze 22 Feb!)

I've updated the schedule for 5.1: https://openacs.org/projects/openacs/5.1/milestone

Feature freeze is planned for 22 Feb 2004.  This means that checkins to HEAD after that date which introduce new features are likely to be rolled back.  Pre-scheduled late checkins are possible if you can get a core member on standby to review the checkin.  We will branch to 5-1 as late as possible - ie, not until someone has new work which must be committed to HEAD.

Now that we have install-from-repository and rules for assigning packages to versions, we will be much more likely to release core 5.1 without worrying as much about applications, as long as the openacs-5-0-compat versions of the main applications are also openacs-5-1-compat.

The branching strategy for non-core is not wholly determined.  We can branch everything, like we have done before, or we can branch just core, which means that non-core packages which need branching (because they have substantially different 5-0-compat and head versions) will have to be branched manually.  Comments welcome.

Collapse
Posted by Tom Mizukami on
Is the integrated automated testing/TclWebTest going in 5.1?
Thanks.
Collapse
Posted by Joel Aufrecht on
Yes.  Improvements to automated testing are mostly implemented on head (thanks Til and Peter) and just need a bit more work (on the report gathering end), bug-testing, example tests, and documentation, all of which should be done in time for 5.1.
Collapse
Posted by Don Baccus on
How late is "as late as possible"?  I'm going to have a bunch of stuff to commit in a couple of weeks.  This is why delaying  branching is a headache for developers ... I personally use CVS as a sort of backup mechanism for my OpenACS work - I check in work regularly whenever I reach logical points in the development process where my work is internally consistent.

I'll say again what I've said before ... closing the repository to check-ins is a different style of working than I've seen elsewhere.

Collapse
Posted by Guan Yang on
Don: I think a lot of people work this way, using CVS as a sort of backup, but there are a lot projects (namely the BSDs) that regard commits a very sacred ritual which is only done when a new feature is ready for testing.
Collapse
Posted by Malte Sussdorff on
Please branch 5.1 on feature freeze date :). This way changes can be added to HEAD (no rollback necessary) and people could continue to work. As we do not have package maintainership, branch packages as well. This makes it easier for people to jump in and fix things if they are broken.
Collapse
Posted by Joel Aufrecht on
1) Don, do you have enough pending work that is both likely to be complete soon and useful in 5.1 it's worth delaying the end of coding and thus delaying the release?  On the one hand we want to release more often so that new work doesn't sit inaccessible on HEAD; on the other hand we don't want to go through the non-reusable overhead (doc updates, tags and merges, announcements, manual testing, etc) of a release more than necessary ; on the third hand our gradual improvements in automated testing should make the alpha/beta/rc cycles much shorter because HEAD should always be closer and closer to a releasable state.

2) On freezing HEAD: here are some examples one way or the other:

http://www.gnomedesktop.org/article.php?sid=162.  "Mozilla.org has closed the tree to approved checkins only, starting as of 12am Wednesday, and will do so until 0.9.8 has branched."

Here's FreeBSD's branch status, showing HEAD as "semi-frozen": http://www.freebsd.org/releng/index.html.

Here's Mozilla's roadmap, showing freezes on HEAD: http://www.mozilla.org/roadmap.html

Perhaps part of the problem is that we all seem to use openacs.org:/cvsroot as our working repository.  If we instead developed locally and committed in bulk and only after running local test suites, we would have fewer freeze and stability issues.  On the other hand, I'm not sure how to do this with CVS without losing lots of revision history; it would up the local setup burden for developers, and we don't currently have extensive test suites.

So perhaps OCT can make a decision:

1) freeze at code complete; branch on freeze
  - easier to enforce freeze because default commits won't go to the branch
  - HEAD is never frozen
  - easy to understand process
  - bug fixes made on branch are either delayed getting back to HEAD or require duplicate effort

2) freeze at code complete; branch some time between freeze and RC
  - no place to commit new work during freeze
  - freeze takes work to enforce
  - easier to fix bugs on HEAD
  - may encourage necessary bug fixing in priority over new work

Let's discuss and then I'll TIP.

Collapse
Posted by Alfred Werner on
Ecommerce upgrade by next Thursday. Mostly bug fixes and noquote/schema and HTML validation fixes, not a real feature release. I'll be out of town so I'm reserving a spot ! :)
Collapse
Posted by Lars Pind on
What's the goal?

To me, the goal is to get as many hands as possible to help fix bugs, so we can get the release out quickly and merge the branch back.

Branching early seems to detract from that goal in that it encourages people to continue working on new features, when they should be helping testing and bug fixing the release, so we can move on.

Branches are also painful, because bugs are going to be discovered, researched, and fixed twice, meaning wasted effort.

Ideally, I'd have all hands work on testing and bug fixing, and not branch at all until we have actually shipped 5.1.0.

Maybe we have different goals, or maybe I'm just being unrealistic.

It feels like the Bystander Apathy story, where if 1 person is watching a murder, they're likely to do something, but if 30 people are watching it, nobody does anything, because they all figure that someone else will do something, or maybe there's nothing to do, because if there were then surely someone would do it.

We need to get all hands involved in doing the grunt work of shipping. No bystanders, please!

I remember some dude once saying something like "Software is worthless until you ship it" 😉

/Lars

Collapse
Posted by Malte Sussdorff on
I work out of head and I'm happy with not branching unless head is in a state that allows us to release. But what happens to changes that come in and actually throw us back again in our "time to release" ?

How do we define the feature freeze. You should not prevent people to write on new things only because some others want to release software. Where shall their code go to in the meantime. I think working off from a seperate repository and doing vendor imports of OpenACS is too much of a fuzz for most developers which is the reason why I think quite some of us still work out of OpenACS repository.

Again, personally I'm in for releasing the way we do and concentrating on bug fixing instead of new features once we have a feature freeze. But I would like to see ways for others that are not commited to release to continue working. After all, what happens if we fail to release quickly.

Unless we don't TIP this and get an agreement on what the steps are going to be when we release, we are stuck dead in the water. As Joel is the release manager it would be great if he could TIP whatever he thinks works out best and let the OCT vote on it. Then at least all of us know what is coming up, how do deal with it aso.

Collapse
Posted by Don Baccus on
Joel, I don't expect to have stuff ready for 5.1 - 22 Feb is two days before I return to the States.  I don't think we should delay on my account.  I'm working with Barry Books on high-level Tcl API for the definition of object types (an extension of my original work on such definitions for CR stuff) and we'll be experimenting until we satisfy ourselves, then TIP'ing, then dumping code in ...

As far as requiring all core developers to shove new development to the side in order to work on bug fixing ... that's impractical IMO in an environment where so many are dependent on client contracts for survival.  When such work results in approved changes to the core, I see no reason why one should be asked to ice their client and to switch mode to bug fixing.  Contractors need to hold client deadlines in high regard, as we all know.

I plan to help with bugs when I get back home, but I'm not planning to switch to that mode 100%.  Dropping ongoing work entirely is really inefficient ... I don't know about others, but I find it hard to step away from a problem for two, three or four weeks then to jump back in.  Takes time to regain the mental thread that's driving development.

We've been following the branch-at-freeze paradigm for, oh, four years from now and IMO it has actually served us quite well.  Yes, merging is a pain, I realize that.

As Joel points out, using local repositories followed by massive checkins of finished code results in the loss of history.  It's also a PITA, IMO ...

We all know that CVS is a very, very imperfect tool ... I think the problem is one of finding a solution that's the least painful to the largest set of developers, rather than finding a solution that's really wonderful.  Call me a pessimist.

Collapse
Posted by Joel Aufrecht on
Okay, here's where we're at with 5.1:
  • Timo's changes for acs_object were rolled back and are now slated for 5.2.
  • We now meet the α complete criteria with the exception on one unverified bug
  • By our current criteria, there are 132 bugs to fix to reach β complete.
  • 5.0.4 should be merged back to HEAD - it's mostly new translations. After that, we can branch and release the HEAD core freeze any time.
Collapse
Posted by Malte Sussdorff on
Can we get a "community" Oracle server to fix all those Oracle bugs? I think one of the reasons why we see so many of them is that the occasional user does not bother to fix things on Oracle and/or has not the ressources (aka: Oracle installation) at hand.
Collapse
Posted by Joel Aufrecht on
Collaboraid has a machine on order to use as an Oracle test server (cph03 was looking a bit under the weather hosting so many test servers, we didn't want to put Oracle on it as well)
Collapse
Posted by Don Baccus on
It looks like Peter's closed that last bug

Also I want to work on fixing bugs for beta (I fixed a new bug that would've been an alpha blocker a few days ago) but have felt like we should concentrate on pushing this alpha out the door ... is it time, now?

Having an Oracle server at Collaboraid will be great.  Also Dirk, who knows Oracle much better than me (a situation I want to encourage!), has kindly volunteered to look into ripping out the remaining Java code in OpenACS/Oracle so it will run on Oracle/Mac OS X ... that will help several of us in our Oracle bug fixing and development efforts.  Well, at least one of us - me! :)

Collapse
Posted by Malte Sussdorff on
Also Dirk, who knows Oracle much better than me (a situation I want to encourage!), has kindly volunteered to look into ripping out the remaining Java code in OpenACS/Oracle so it will run on Oracle/Mac OS X ... that will help several of us in our Oracle bug fixing and development efforts. Well, at least one of us - me! :)

I can only second that. At least this would be a good reason to finally install Oracle on my Powerbook.

Collapse
17: Re: Ripping out Java (response to 15)
Posted by Dirk Gomez on
OK, I started ripping out Java. My main issue is that I don't know how to test the whole thing...I can submit a patch to the bugtracker and some CR wizard takes a look at it.

There are a few Java packages remaining in acs-content-repository/sql/oracle/packages-create.sql and we could just make them dummy pl/sql functions that return foo and I start reimplementing the *necessary* pl/sql code.

Don (or someone else for that matter): is the Java in Oracle code *really* used in OpenACS? It somehow looks so unused.

Collapse
Posted by Don Baccus on
The code to copy blobs is used in a couple of places, yes, though unfortunately I don't remember quite where.

grep through the CR and CMS though and I think you'll find all that counts.  I think there are a couple of copy routines in PL/SQL that in turn rely on the Java blob copy code.

These changes shouldn't go in 5.1, though - don't commit until we branch! :)

Collapse
Posted by Jeff Davis on
These changes shouldn't go in 5.1, though - don't commit until we branch! :)
Which we have done. The new branch (oacs-5-1) was created friday.
Collapse
Posted by Dirk Gomez on
No intention to commit yet. I am doing this off the 5.1 branch because HEAD doesn't setup, it choked on kernel right away on Thurday when I last tried.