class library bug fixes for 4.1.x

[Mark Wielaard]

Hi,

On Tue, 2005-12-13 at 11:38 -0700, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
> 
> Mark> Do you have a list?
> 
> Actually I think I just had one patch on the list and it was the one
> that prompted this thread.

And now the bug reports start to come in since several people/distros
seem to try out the 4.1 branch now so I guess the list will write
itself :)

> Mark> I would actually like to do another import before end of December (and
> Mark> release GNU Classpath 0.20 at the same time). But I can understand the
> Mark> fear that this will be too disruptive for the 4.1 branch. I don't know
> Mark> when 4.1 is expected to be finalized. I see that there are more than 100
> Mark> serious regressions (and more than 200 regressions in total), so I guess
> Mark> we probably won't see a 4.1 release soon.
> 
> Yeah, I'm wary of doing another import.  But I suppose this time
> around we're mostly looking at bug fixes and not, say, another huge
> new set of packages.  So maybe it would be ok after all.  IOW, I'm stuck.

After seeing some of the reported bugs I am less convinced I like to do
another big import. It kind of depends on the timeframe, if it will be 3
more months before we see a 4.1 then it would be OK, but if 4.1 will be
out in 2 months or less then we really need to concentrate on bug-fixing
only.

> Mark> If we don't do another import before 4.1 is release what would you
> Mark> suggest the "backport criteria" to be? Should we just say that if
> Mark> someone reports a bug against a real world application (as distributed
> Mark> with one of the major distros) that is fixed on the trunk or in
> Mark> classpath upstream it is a valid target for backporting to the branch?
> 
> Pre-4.1 we can be fairly open about fixes, as in, we can put in
> anything that fixes something we care about.  And, as usual, the newer
> packages have greater leeway than the more established ones, i.e., I'm
> less worried about swing fixes than java.lang fixes.

That might be a nice compromise. Allow one more big import of swing and
awt on the branch, but do everything else on a case by case basis. Then
we could do a big import when 0.20 is released on the trunk, and only
backport the "safe" parts/packages of that to the branch.

> Post-4.1 I think we have to add the binary compatibility rule, as
> contra our plans we didn't fully finish BC and flip the default in
> time for 4.1.

Which basically means only patches that don't add/remove any methods
right?

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20051217/7ac645d0/attachment.sig>