-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
As you
are probably aware over the past 2 weeks I have been repairing
the
bugs blocking R14 listed in Bug 2014. At this time the vast majority
have
been repaired, with less than 10 remaining.
As a result we are very close to R14 release.
*****If you have any open bugs that you think should block R14, now is
the
time to add them.
It will take several weeks to fully rebuild the Debian/Ubuntu archives;
at
the end of this process if all bugs blocking Bug 2014 are resolved we
will
proceed with release.
Thank you to the rest of the TDE development team for keeping things
going
and helping with the overall bug load, especially Slavek, Michele, and
Darrell!
Don't jump the shark. :) Not every app or feature gets used every day.
Despite the huge movement forward, there might be some nit-pick
regressions associated with the latest commits. There are only a handful
of us using git in a meaningful manner. That is, limited testing and
eyeballs. Thus even after the list is reduced to zero, provide sufficient
time for developers and testers to actually run everything for a week or
two. We have gone this long with the official R14.0, another few weeks
will not bite anybody and might even help. :)
Sure. I'm expecting that list to go to zero pretty quick, and then it's
wait and see on any new bugs as you say. Right now I'm shooting for RC1
Oct. 15 or so (provided I can kick the build farm back into high gear) and
will be working on the website/wiki during that time.
We still should roll through a formal RC1, RC2, .
. . cycle and
announcements. RC announcements tend to motivate some users to install and
test.
Agreed. However, I would like to have R14 out the first half of November
as I have a press opportunity around that time (already been delayed for
far too long) that could really help revitalize this project with more
users and maybe even some developers. 3.5.13.2, while rock solid, is
dependent on HAL and has other issues that R14 does not. Unfortunately,
as I have seen before journalists are more than happy to broadcast these
deficiencies even if R14 is "right around the corner". Given our
strange/uneven development pacing I can't blame them! ;-)
Documentation needs attention, although with all
of our schedules and
energy I don't know how much we can do about that.
I don't doubt it, though from what I have seen it seems to be much better
than it ever was before, thanks largely to your continued efforts.
When was the new wiki and web site to be unveiled
(which need to be tested
by community users)? With the official announcement of RC1?
I will likely cut over the Wiki first with the old site still active
(probably in the next few days if not sooner). If I can get the new site
in production form in time then yes, new site comes with R14 RC1. :-)
BTW, Francois helped a lot too. :)
Yep, I realized I'd left him off almost as soon as I sent the message.
Sorry Francois!
Tim
I also favor a "non-rushed" release, after all the time and effort that
we have put into it it would be silly to overlook something. Once the
list is down to zero, would something like this be reasonable?
1) hard-freeze v14.0.0 (perhaps in a week or so)
2) allows 2 weeks for internal testings (mostly us developers)
3) freeze, build and release RC1 (end of October or beginning of
November). Tim could use the press opportunity that he mentioned to
announce the release of RC1 and upcoming schedule for RC2 and final
v14.0.0 release.
4) allow 3 weeks for RC1 testing and eventual documentation improvements
(no code changes, unless blocking stuff)
5) freeze, build and release RC2(4th week of November)
6) allow 3 weeks for RC2 testing. No code changes allowed, unless
blocking stuff.
5) final v14.0.0 freeze, build and release around middle of December,
just in time for a nice Xmas present :-)
This would also give enough time to:
1) polish up the new website
2) do proper migration testing (3.5.13.2 to v14.0.0)
3) *** IMPORTANT *** prepare a good press release pdf as discussed
almost a year ago in