Proposed IcedTea 6 release

[Andrew Haley]

Mark Wielaard wrote:

> On Mon, 2009-08-10 at 10:31 +0100, Andrew Haley wrote:
>>> Right. I think the confusion comes from where people think we are in the
>>> release cycle. It would be good if we had more timed releases, say every
>>> 6 weeks on a Monday (or something similarly random, but consistent).
>> At the moment, we release when new features warrant it.  By releasing
>> periodically you impose a schedule where none is needed.
>
> I think you are mistaken, these recurring "release now?" discussions
> seem to show a more regular periodic release schedule would make the
> whole process go more smoothly.

Maybe.  However, it's a big change to make to the way that we work,
and it seems a lot simply to avoid pointless discussions.  Not that
I'm against avoiding pointless discussions, but I doubt that it would
work: we'd end up still having the discussions, but with the extra
overhead of a fixed release cycle.

>>   You also raise
>> the absurd possibility of a new release with no new features.
>
> I think that is a fear that isn't very likely. We make improvements, bug
> fixes, adding features all the time. Even if there are no "major" new
> features having regular update releases with "just" feature improvements
> and bug fixes would be really good. IMHO.

Well, again maybe.  It's a lot of extra work, especially for those
with a great many platforms to test.  And I doubt the value of it,
frankly.  I've worked on projects with regular timed releases and with
feature-based releases, and the feature-based releases work better.
They're much more aligned with what users want: no-one wants Release
1.9, they want Feature X.

You are proposing a change that has costs associated with it.  For
that to work, we would have to have buy-in across the IcedTea
community and a commitment to do the work.  Without that, releases
would not be tested.  And if there is one thing that we must not do,
it is to make untested releases.

>>> Then it is clear that when the release manager says that a release is
>>> coming, you know when you must have had your code in, testing done and
>>> that a branch is imminent.
>> A release has been proposed, and we're having that discussion.  Rather
>> than saying "A release will be made on Date X and if your code isn't
>> ready, tough", I'm asking "When will your code be ready?"  This is a
>> far more sensible approach.
>
> I thought the question was more "everybody ready for a release now?" Not
> about whether or not some new code would be ready in some future.

The question is "Is this a good time to release?"  If the answer is
"Well, I'll have Feature Y ready in a couple of weeks" then we can
talk about it.

>> We're discussing it now.  This is the notice that a release is proposed.
>>
>> Let's get concrete.  As far as I know the trunk is almost in a state where a
>> release branch can be made.
>>
>> Who has work that they want to get in the next release?  When can it
>> be readied?
>
> OK, agreed.
>
> I believe the following additions are in, tested and ready for release:
> - Plugin and netx improvements (largely complete 1.5/6.0 jnlp spec
>   support, cookie support rewrite, and numerous other stability and bug
>   fixes)
> - security updates.
> - systemtap java method entry/exit tracing.
> - updated hotspot (hs14b16)
> - updates to shark for newer LLVM api interface changes.
> - Build fixes and general bug fixes (execvpe, cacao, gcc 4.4,
> - Cleaned up configure support for --with-openjdk and
>   --with-additional-vms
>
> Not ready yet? but would definitely be nice:
> - sync with oj6, unknown when/if it can be updated, but icedtea6 already
>   contains the important bits missing from current oj6 (security
>   updates, updated hotspot).
> - new arm stuff.
> - new Xorg header updates (currently not certain how to detect, distros
>   patch themselves).

Right.  So, are any of these worth holding up a release for?  I think
the ARM interpreter is, particularly as I am assured it is ready to
go in.  It offers very significant benefits to some users.

Andrew.