Re: Release schedule

[Alexander Malmberg]

Adam Fedor wrote:
> 
> I think that the way I handle stable releases may be too complicated,
> or perhaps it's that people are afraid to commit even bug fixes to the
> release branch. So I am trying to think of different things to do the
> next time. Just for your information, I typically make a pre-release
> version and then fork a branch in CVS for bug fixes for the release. I
> then make a release about a month after the pre-release.

I think part of the problem is that, at least from what I've seen,
nearly nobody uses the pre-release or branch. In #GNUstep, I think just
about everyone is either using cvs directly (ie. HEAD) or only stable
releases, so that's what gets tested and where they want bugs fixed.

> One thing I might try next time is to make multiple (perhaps weekly)
> pre-releases, so that people feel comfortable putting in bug fixes
> knowing that they will be tested. Let me know if you have other ideas.

My suggestion is to avoid branches for now and simply have a steady
stream of releases (of HEAD) at semi-stable points, ie. not in the
middle of large changes, but as soon as possible after them, and often.
I'd argue that most of the useful testing is done by people running very
recent versions, and things often move so quickly that apps end up more
or less requiring a version newer than the last release.

By providing releases often, those who want to use released versions
would still be able to run new (versions of) apps and give meaningful
bug reports, and those who currently use cvs only because they have to
could use these releases instead (and even for those staying with cvs,
the release tags would provide relatively safe points to update to; "is
it safe to update now?" is a common question in #GNUstep).

> ---
> 
> Also, after much procrastination, I hope to update the upcoming
> goals/schedule for GNUstep:
> 
> http://www.gnustep.org/developers/schedule.html
> 
> If you have any thoughts on what our major goals should be for the next
> few releases, let me know.

Printing is very important. If I could print (or just get valid .ps
output) from TextEdit, I would start using it as my primary text editor
(for formatted text). (Note that this isn't a text system issue;
printing the text view works. It's the multi-page mode that fails
horribly: the pagination is messed up, the code to detect printing (to
avoid drawing some things) in TextEdit fails (arguably, TextEdit is
broken here; asking the context for this information would be much
cleaner; however, -gui is also broken wrt this), and text views (in this
case subviews of the printing view) seem to be drawn in an unflipped
coordinate system.)

I've only looked at this enough to see that there's a lot of code in
-gui to handle printing already, so I can't say if these are minor
issues or if there's a lot left to implement. Either way, I think it's
very important to be able to print properly (even if it's unoptimized,
or even cumbersome to get it to the printer).

- Alexander Malmberg