IcedTea7 2.0 Branched for Release

[Matthias Klose]

On 09/30/2011 12:04 AM, Dr Andrew John Hughes wrote:
> On 14:05 Thu 29 Sep     , Matthias Klose wrote:
>> On 09/29/2011 12:58 AM, Dr Andrew John Hughes wrote:
>>> IcedTea7 2.0 has now branched for release.  I plan to do the release
>>> on Monday evening here in the UK, pending major issues.
>>
>> I disagree.  If this release is needed for some deadline, then call it a
>> pre-release.  
> 
> The pre-release is already available.  This release is already long
> overdue and I want the first feature release out of the way prior to
> the upcoming security update:
> 
> http://www.oracle.com/technetwork/topics/security/alerts-086861.html
> 
> There's also 7u2 coming soon and I don't really want to have restart testing
> again due to importing all those changes.  The current tree has seen a lot
> of testing, both by me and via the builds in Fedora.
> 
> I'm prepared to go to Wednesday to give it a full week, but my
> impression is that all bugs have been fixed at this stage.  Certainly,
> there are no longer any dependent bugs on
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=712 and that
> has been available since the 11th of May.
> 
>> There are still long outstanding issues.
> 
> Not that I'm aware of.
> 
>>
>>  - You did hijack release-management from existing release
>>    maintainers, did change commit and release policies on
>>    your own, and disallow others in editing these policies.
>>    The request to change this behaviour is now ignored for
>>    months [1].
>>
> 
> Frankly, that's a lie because there are several replies in that thread,
> and contributions to the policy documents from other *active* developers.

Speaking about "lies"?  No, the issue that you do changes on your own as Andrew
Haley did mention in this thread. No, you didn't address this.

> Even back then, this was just a statement of the existing working model --
> as you would know if you were actually involved in this project.

This is wrong. Up to at least IcedTea6-1.9 we had a so called release manager;
changes on the branches did need the approval of the release manager for this
branch.  You did change this model on your own, people did ask you to get
approval for this model first, which you do ignore until today, and you do
reserve the right to be the only person in the project to change this model.

> I presume by 'hijack[ing] release-management', you mean actually doing
> the release work when such maintainers fail to do anything?

Has there been anything wrong with any release branches?  What do you complain
about?  It was *your* own offer to prepare the security updates for the
IcedTea6-1.8.x branch.  Thanks for that.  No thanks for using this as a pretext
to accuse somebody else of inactivity.  No thanks for pedantically defining
activity by ChangeLog entries, which do not see changes when backporting to the
branches, or testing pre-releases.

> A situation
> which would otherwise leave release branches with open security vulnerabilities?

Again, when did that happen?  Afaict IcedTea did release security fixes in a
timely manner, even with incomplete fixes provided by upstream, or provided on a
short notice.  If you do not want to do these anymore tell the release manager
of these branches, and don't announce the retirement of a branch on behalf of
the IcedTea project.

> As far as I can tell, your objection is to us actually *reviewing* release branch
> patches (the only change I'm aware of), which means you can't just shove whatever
> patches in you want in a rush because you failed to plan sufficient time for review.

The release manager of the IcedTea6-1.6 branch did shove in tremendous backports
into the branch which did break nearly all zero builds.  If you can't test
these, don't backport these for convenience.  The changes for the IcedTea6-1.8
branch were discussed in bug reports and on irc and committed to the
IcedTea6-1.8 branch. This conforms to the release policy for the IcedTea6-1.8
branch, not on the policies which you are setting for yourself.

>>  - The movement to the "forest" development model doesn't
>>    help many people, only a few.  
> 
> This is the first complaint I've heard and the forest has been
> in use for over two years:
> 
> 2009-05-07  Andrew John Hughes  <ahughes at redhat.com>
> 
>         * Makefile.am:
> 	Support downloading and extracting from
>         the forest repositories rather than one megatarball.
> 
>>    It's not communicated,
>>    only a few more equal IcedTea developers have commit
>>    rights, 
> 
> Everyone who has commit rights to the IcedTea trees can write to the forest.
> 
>>    the regression testers use the icedtea7 branch,
> 
> What is the issue with this???

changes get only testing when these appear on the icedtea7 branch.  So with a
broken zero import, I often hear "fix it in the forest", and the icedtea7 branch
remains broken until the next import.  And during this period you won't get any
results from the regression testers.

>>    Throwing over changes from the forest is not communicated,
> 
> I don't know what you're referring to by this.
> 
>>    and it does break alternate VMs on a more or less regular basis.
> 
> If you're interested in maintaining a non-standard build option like
> Zero, Shark, CACAO and JamVM, you need to do actual work on it.  Xerxes
> has done some excellent work in adding JamVM and keeping it up to date.
> You can't expect other developers to maintain code they have no use for
> on your behalf.

If you are not interested in Zero, Shark, CACAO and JamVM, please get your
changes to the build system approved/reviewed by somebody else. Not only on
release branches, even on the trunks.

>>  - As communicated before, releases should be announced at
>>    least a working week before the release, better two. Letting
>>    people to have 1-2 work days before a release with the last
>>    dump from the forest only two ore three days past is ridiculous
>>    (and then having the release day on a bank holiday).
> 
> I wasn't aware Monday was a bank holiday; it's not in the UK and I don't have
> the dates of every bank holiday in the world in my head.
> 
> Maybe Monday was a little eager, but this has been dragging on for a
> long time and there's an impending security release.  Oracle released
> 7 at the end of July and there's demand from a number of quarters for
> us to provide it as well.  Both Fedora and Gentoo are waiting on a new
> release, for instance.

I assume you did know this at least a few days before writing your email. Or
even before the last dump from the forest?  This could have been communicated
earlier.

>>     If
>>    you do have a deadline, cut a pre-release.  The time is
>>    too short to even run tests on some architectures, or
>>    even better to give time to address these.
> 
> This is a note to start *final release testing*, not to start testing period.
> If you want to ship IcedTea7, you should have started testing it longer before
> we reach this juncture.  It has been around for three years.

You know that at least since the first OpenJDK7 release. Please send this
earlier so that people can plan for it.  Your cleanup in the last dump did at
least break one build according to
  https://buildd.debian.org/status/package.php?p=openjdk-7
  http://buildd.debian-ports.org/status/package.php?p=openjdk-7
Damien told me that he'll address these issues this time.  Such changes should
not be made that short before a release.

Implying that I only did start testing last week is just one more rant.

>> To go forward, I propose to set the release date to Mon, Oct 17 (or Tue, Oct 18
>> if this is a bank holiday in the UK/US).  This also gives time to address the
>> issues about commit and release policies.  
> 
> The release date will be Wednesday, October the 5th.  Suggesting the
> week of the 18th just shows you're not only inactive in IcedTea
> development, but also unaware of the security release process:
> 
> http://www.oracle.com/technetwork/topics/security/alerts-086861.html
> 
> There's not going to be any time in the early months of October, due
> to preparing these security updates, and delaying to November means
> that what we have now, which has been fairly well-tested, because more
> and more outdated.

Well, wondering how many developers within IcedTea were aware of this.

> You haven't raised any actual *technical* issues above as far as I can
> see, and I don't see any reason to delay this release by such a long
> period.

I did. Not being able to complete test builds, needed fixes and another round of
builds.  I am not sure what the release criteria is for Gentoo or Fedora, but
the current state of OpenJDK7 in Debian now raises one release critical issue.

>> The project is still called IcedTea,
>> not AndrewsTea.
> 
> It is. It's also not called MatthiasTea.  If I have a significant
> voice in what goes on, it's because it's *me* who actually does a lot
> of the work to make these things happen, from backporting patches,
> fixing bugs and build issues to actually rolling out the releases
> (around 30 I think in the last year).

Thanks for doing this. However you have to learn to work with people who do not
spend full time working on IcedTea, and that people are interested in other
areas which are not your primary focus.

> In contrast, you haven't even
> bothered to submit a single change to IcedTea7 since May.

Do you know why?  In May somebody did confuse that a big share of work in
IcedTea implies setting policies on his own.

> You just
> turn up about every six months, complain and then disappear again
> without actually contributing anything.  This wasn't always the case,
> and I would prefer to go back to a time when you were a welcome
> presence in this project, rather than a troll.

thanks for the flowers, sending them back.  Yes, it's your attitude towards the
project, how to set policies, how to communicate, how to make announcements on
behalf of the project.

> There's not only me working on IcedTea.  Pavel has done some excellent
> work finding backports and getting them into IcedTea6, as well as
> fixing tests.  I've had pretty much nothing to do with IcedTea-Web
> since the initial release; Deepak, Omair, Jiri and various others have
> done an excellent job of maintaining this.  They've also implemented a
> review policy for every patch (unlike IcedTea6+7 HEAD which don't
> require review) and have found it works better for them, leading to
> higher quality code.  If they're not vocal on the list, it's because
> they're actually hard at work actually contributing to this project,
> rather than just complaining, and don't want to get embroiled in
> ridiculous arguments like this.

right, and everybody not mentioned here is just lazy. I am not aware that any
guy mentioned here did try to set policies on his own, and indeed the
IcedTea-Web project seems to work well. Why shouldn't this work for IcedTea6+7
as well?

  Matthias