> It is true that from originally expected "small" update the
> work has grown greatly. 3.5.13.1 now contains a large number of fixes. If
> we were release updated versions more often, it could be now for
> example 3.5.13.5 :)

In that light I'd like to resurrect a recent proposal:

A project goal of regular point releases.

A proven method of discouraging people is to create a to-do list that is too large. Over the summer that happened to us. The bug tracker grew without a respective proportional resolution response. We feel overwhelmed.

A proven method for slow production is a lack of goals.

Seems this summer we adopted a "Yawn, release whenever..." philosophy. The project seems to be stagnating. We seem unable to attract talent. We want to restore our motivation and vigor. We do that with goals and organizing those goals into workable sizes. We use project goals or we get lured into apathy and discouragement.

I prefer a sensible balance between the "release when ready" and "release early, release often" philosophies. We can embrace both philosophies and benefit as well.

For the very near future, we finalize the 3.5.13.1 release. Get that release out the door as soon as practical. Based upon Slavek's reports I believe we are very close to that moment. As soon as tarballs are available we start final testing and prepare a news release for the big day.

We set a project goal to release R14 three months after officially releasing 3.5.13.1.

Presuming 3.5.13.1 is released officially no later than Sept. 30, we release R14.0.0 Dec. 31.

R14 becomes our stable branch with the main GIT being our R15 development branch.

We embrace these goals while avoiding feelings of being overwhelmed.

That means evaluating R14 and the bug tracker in a realistic manner.

For R14 we focus on those bug reports that must be fixed for a stable release. That does not mean all build issues need be resolved when a short-term work-around is known. We can live with build issue work-arounds for the short-term but we can't live with usability breakage. We resolve as many build issues as practical, but we focus on serious usability bugs.

To avoid discouragement we remind ourselves that releasing a stable product does not mean releasing a perfect product. Anyone involved with software development knows that perfect code does not exist. A perfect product is a laudable goal but a stable product is a realistic goal. The point release schedule helps us support both goals.

We support point releases (R14.1.0, R14.2.0, etc.) every 8 weeks, but we don't overwhelm ourselves with biting more than we can chew.

As a small project, only 10 to 12 bug fixes need constitute a point release. That equates to only one to two bug resolutions per week. We can and have been doing that. This slow-but-steady approach helps us resolve certain irritants, such as improving TDEHWLIB to replace HAL; fix unknown libpng, gcc, and glib2/c bugs; building koffice with libwpd >=0.9; etc.

Much of the time bug fix patches will be applied to both the development and stable branches. Yet point releases contain only non ABI/API breaking bug fixes and enhancements, much like the patches that have been backported for 3.5.13.1.

Serious security patches are released as needed (R14.0.1, R14.1.1, etc.), regardless of our schedule. Serious security patches do not modify the normal point release schedule. Most of the time we don't need a special security release --- security patches can be slipstreamed into the regular point release.

With regular point releases we avoid the impossible task of resolving everything all at once. We avoid apathy and discouragement. We instead resolve bugs and enhancements in a steady methodical manner.

Regularly scheduled point releases embraces the "release early, release often" philosophy. Including ABI/API breaking patches only in the development branch embraces the "release when ready" philosophy.

To support R15, which includes ABI/API changes, we maintain a separate GIT development branch. We already do this by supporting R14 and 3.5.13.1. Basically, after we release R14, 3.5.13.1 gets semi-frozen with only the most serious patches being backported, R14 replaces 3.5.13.1 as the stable branch, and the main GIT becomes R15. Serious patches for 3.5.13.1 are released as patches --- we don't release new tarballs.

By releasing point releases every 8 weeks we keep Trinity in the news. We have failed miserably at that. Publicity is a must-have for a project as small as ours. We all admit we are falling behind and starting to drown. Publicity is a great way for us to attract talent. With a point release every 8 weeks, end-users start believing the project is not only alive but active. End-users start believing _in_ the project. This slow-but-steady progress encourages distro maintainers and third-party packagers to include Trinity in their favorite distro. The effect is a proverbial snowball rolling down a hill.

And we do this without overwhelming ourselves.

By embracing these goals we steadily reduce the bug tracker size and avoid discouragement. By doing that we provide a healthy atmosphere and feeling among the community because everybody observes regular progress and hopefully, we read increased online positive reviews. Everybody feels good. Everybody wins. Trinity stays healthy and vibrant.

Darrell