Re: <AWT Dev> [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

[phil.race]

awt_Graphics and XShm is more for 2D than AWT, but
I'm not sure how much it matters for this small change.
Attach the patch to a bugzilla report .. someone will
need to generate a sun bug id too. Can you post a zip
of the webvrev somewhere?

And is there an X11 reference you can cite to this apparent
source incompatible change there?

-phil.

Andrew John Hughes wrote:

> With the new version of X11 (specifically libXext >= 1.1), the XShm.h
> header has been refactored.
>
> As a result, the build fails on awt_GraphicsEnv.c.  This simple patch:
>
> http://cr.openjdk.java.net/~andrew/xshm/webrev.01
>
> fixes the issue, without affecting older versions.  It's trivial, but
> very important; this new X11 is already in Gentoo, it'll be in F12
> (where we first discovered this issue), and it's no doubt heading to
> an Ubuntu near you soon.
>
> The patch was contributed by Diego Pettenò <flameeyes@...>, who
> I'm informed has signed the SCA.
>
> Does this look ok? If so, can I have a bug ID to push this to the
> awt-gate (or wherever is appropriate)?
>
> Thanks,

[gnu_andrew]

2009/11/3 Phil Race <Phil.Race@...>:
> awt_Graphics and XShm is more for 2D than AWT, but
> I'm not sure how much it matters for this small change.

It's called awt_Graphics hence the AWT list.  I doubt the distinction
between 2d and awt classes is clear to anyone outside Sun.

> Attach the patch to a bugzilla report .. someone will
> need to generate a sun bug id too. Can you post a zip
> of the webvrev somewhere?

I'm aware we need a Sun bug ID; that's why I asked for one to be
allocated in the e-mail.  I have commit rights so I don't need
mentoring; I just need a review and a bug ID so I can push the fix.  I
don't see why you need all this other superfluous stuff, as it wasn't
needed for any of my other pushes to various repos.

Is the patch ok?  If so, could you please allocate it a bug ID.

>
> And is there an X11 reference you can cite to this apparent
> source incompatible change there?
>

There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
but I avoided posting this in the original mail because it seems to
have changed again between that commit and the final release,
presumably due to compatibility issues (XShm.h is back and it's now
shmproto.h as seen in the patch).  I've built the repo with this patch
here with the old version, and others have built it with the new
version; it does work for both.  The same patch is already in Gentoo's
ebuild and IcedTea, and a similar patch has been used for the Fedora
rawhide RPMs for some time.  It would be good to get it upstream as
well.

> -phil.
>
> Andrew John Hughes wrote:
>>
>> With the new version of X11 (specifically libXext >= 1.1), the XShm.h
>> header has been refactored.
>>
>> As a result, the build fails on awt_GraphicsEnv.c.  This simple patch:
>>
>> http://cr.openjdk.java.net/~andrew/xshm/webrev.01
>>
>> fixes the issue, without affecting older versions.  It's trivial, but
>> very important; this new X11 is already in Gentoo, it'll be in F12
>> (where we first discovered this issue), and it's no doubt heading to
>> an Ubuntu near you soon.
>>
>> The patch was contributed by Diego Pettenò <flameeyes@...>, who
>> I'm informed has signed the SCA.
>>
>> Does this look ok? If so, can I have a bug ID to push this to the
>> awt-gate (or wherever is appropriate)?
>>
>> Thanks,
>

--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[phil.race]

Andrew John Hughes wrote:
> 2009/11/3 Phil Race <Phil.Race@...>:
>> awt_Graphics and XShm is more for 2D than AWT, but
>> I'm not sure how much it matters for this small change.
>
> It's called awt_Graphics hence the AWT list.  I doubt the distinction
> between 2d and awt classes is clear to anyone outside Sun.

But Graphics is I'd hope obviously 2D, and lots of things
have AWT in the name as hangovers from JDk 1.0, 1.1, where
there was no 2D.

>
>> Attach the patch to a bugzilla report .. someone will
>> need to generate a sun bug id too. Can you post a zip
>> of the webvrev somewhere?
>
> I'm aware we need a Sun bug ID; that's why I asked for one to be
> allocated in the e-mail.  I have commit rights so I don't need
> mentoring; I just need a review and a bug ID so I can push the fix.  I
> don't see why you need all this other superfluous stuff, as it wasn't
> needed for any of my other pushes to various repos.

The superfluous stuff is the copy of the webrev?
We archive them. Not all groups do that. Swing, AWT and 2D do.
Occasionally someone may fail to get one from a contribution
but its still the theoretical process to have it.

>
> Is the patch ok?  If so, could you please allocate it a bug ID.

I overlooked that in your email. But I already asked Jennifer to allocate one.

>
>> And is there an X11 reference you can cite to this apparent
>> source incompatible change there?
>>
>
> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
> but I avoided posting this in the original mail because it seems to
> have changed again between that commit and the final release,
> presumably due to compatibility issues (XShm.h is back and it's now
> shmproto.h as seen in the patch).  I've built the repo with this patch
> here with the old version, and others have built it with the new
> version; it does work for both.  The same patch is already in Gentoo's
> ebuild and IcedTea, and a similar patch has been used for the Fedora
> rawhide RPMs for some time.  It would be good to get it upstream as
> well.

OK .. although I was looking for something where they pointed out
this was likely to cause build failures but was justified because ...

-phil.

>
>> -phil.
>>
>> Andrew John Hughes wrote:
>>> With the new version of X11 (specifically libXext >= 1.1), the XShm.h
>>> header has been refactored.
>>>
>>> As a result, the build fails on awt_GraphicsEnv.c.  This simple patch:
>>>
>>> http://cr.openjdk.java.net/~andrew/xshm/webrev.01
>>>
>>> fixes the issue, without affecting older versions.  It's trivial, but
>>> very important; this new X11 is already in Gentoo, it'll be in F12
>>> (where we first discovered this issue), and it's no doubt heading to
>>> an Ubuntu near you soon.
>>>
>>> The patch was contributed by Diego Pettenò <flameeyes@...>, who
>>> I'm informed has signed the SCA.
>>>
>>> Does this look ok? If so, can I have a bug ID to push this to the
>>> awt-gate (or wherever is appropriate)?
>>>
>>> Thanks,
>
>
>

[phil.race]

PS

>>
>> Is the patch ok?  

yes.

-phil.

[gnu_andrew]

2009/11/3 Phil Race <Phil.Race@...>:

>
>
> Andrew John Hughes wrote:
>>
>> 2009/11/3 Phil Race <Phil.Race@...>:
>>>
>>> awt_Graphics and XShm is more for 2D than AWT, but
>>> I'm not sure how much it matters for this small change.
>>
>> It's called awt_Graphics hence the AWT list.  I doubt the distinction
>> between 2d and awt classes is clear to anyone outside Sun.
>
> But Graphics is I'd hope obviously 2D, and lots of things
> have AWT in the name as hangovers from JDk 1.0, 1.1, where
> there was no 2D.
>

Yeah, it's not clear-cut -- so don't be surprised if we post to the
wrong list :)

>>
>>> Attach the patch to a bugzilla report .. someone will
>>> need to generate a sun bug id too. Can you post a zip
>>> of the webvrev somewhere?
>>
>> I'm aware we need a Sun bug ID; that's why I asked for one to be
>> allocated in the e-mail.  I have commit rights so I don't need
>> mentoring; I just need a review and a bug ID so I can push the fix.  I
>> don't see why you need all this other superfluous stuff, as it wasn't
>> needed for any of my other pushes to various repos.
>
> The superfluous stuff is the copy of the webrev?
> We archive them. Not all groups do that. Swing, AWT and 2D do.
> Occasionally someone may fail to get one from a contribution
> but its still the theoretical process to have it.
>

That's very sensible.  I've been wondering why webrev generates a
webrev.zip and now I know.
I've include the webrev.zip at
http://cr.openjdk.java.net/~andrew/xshm/webrev.01/webrev.zip and will
do so in future.  I didn't before, because I didn't realise anyone
made use of this.

My superfluous comment actually referred to the additional request for
an OpenJDK bugzilla entry.  I fail to see the point of this, given a
Sun bug ID is still needed to commit.  Most of the bugs there just
seem to be in danger of bitrotting, and I'd prefer to avoid adding one
that's just going to be closed fairly swiftly anyway.  It would be
nice if we could use OpenJDK bugzilla IDs for commits, and thus didn't
have to hassle Sun employees for Sun bug IDs.  But that still doesn't
seem to have been implemented.

>>
>> Is the patch ok?  If so, could you please allocate it a bug ID.
>
> I overlooked that in your email. But I already asked Jennifer to allocate
> one.
>

Thanks.  I'll push once it's allocated.

>>
>>> And is there an X11 reference you can cite to this apparent
>>> source incompatible change there?
>>>
>>
>> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
>> but I avoided posting this in the original mail because it seems to
>> have changed again between that commit and the final release,
>> presumably due to compatibility issues (XShm.h is back and it's now
>> shmproto.h as seen in the patch).  I've built the repo with this patch
>> here with the old version, and others have built it with the new
>> version; it does work for both.  The same patch is already in Gentoo's
>> ebuild and IcedTea, and a similar patch has been used for the Fedora
>> rawhide RPMs for some time.  It would be good to get it upstream as
>> well.
>
> OK .. although I was looking for something where they pointed out
> this was likely to cause build failures but was justified because ...
>

So would I! They do mention it's an API breakage, but only seem to
have considered internal issues. I couldn't see any discussion of
external breakages in the past few months of mail archives.  The only
justification seems to be 'we want to clear up some cruft'...

> -phil.
>
>>
>>> -phil.
>>>
>>> Andrew John Hughes wrote:
>>>>
>>>> With the new version of X11 (specifically libXext >= 1.1), the XShm.h
>>>> header has been refactored.
>>>>
>>>> As a result, the build fails on awt_GraphicsEnv.c.  This simple patch:
>>>>
>>>> http://cr.openjdk.java.net/~andrew/xshm/webrev.01
>>>>
>>>> fixes the issue, without affecting older versions.  It's trivial, but
>>>> very important; this new X11 is already in Gentoo, it'll be in F12
>>>> (where we first discovered this issue), and it's no doubt heading to
>>>> an Ubuntu near you soon.
>>>>
>>>> The patch was contributed by Diego Pettenò <flameeyes@...>, who
>>>> I'm informed has signed the SCA.
>>>>
>>>> Does this look ok? If so, can I have a bug ID to push this to the
>>>> awt-gate (or wherever is appropriate)?
>>>>
>>>> Thanks,
>>
>>
>>
>

--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[phil.race]

Andrew John Hughes wrote:

> My superfluous comment actually referred to the additional request for
> an OpenJDK bugzilla entry.  I fail to see the point of this, given a
> Sun bug ID is still needed to commit.  Most of the bugs there just
> seem to be in danger of bitrotting, and I'd prefer to avoid adding one
> that's just going to be closed fairly swiftly anyway.  It would be
> nice if we could use OpenJDK bugzilla IDs for commits, and thus didn't
> have to hassle Sun employees for Sun bug IDs.  But that still doesn't
> seem to have been implemented.

Ah .. yes .. well you may be right you don't need that if you
can push it directly. I keep having to look up that part of the
process myself. But IIIRC theory its supposed to be used to submit
patches, not report bugs (sans patch), and you had a patch, which
is why I suggested it.

>
>>> Is the patch ok?  If so, could you please allocate it a bug ID.
>> I overlooked that in your email. But I already asked Jennifer to allocate
>> one.
>>
>
> Thanks.  I'll push once it's allocated.

Jennifer says she's doing it now.

-phil.

[Jim Graham-3]

Andrew John Hughes wrote:

> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
> but I avoided posting this in the original mail because it seems to
> have changed again between that commit and the final release,
> presumably due to compatibility issues (XShm.h is back and it's now
> shmproto.h as seen in the patch).  I've built the repo with this patch
> here with the old version, and others have built it with the new
> version; it does work for both.  The same patch is already in Gentoo's
> ebuild and IcedTea, and a similar patch has been used for the Fedora
> rawhide RPMs for some time.  It would be good to get it upstream as
> well.

At first I was going to ask how the existing #include succeeds when the
link says that Xshm.h is going away, but now I see that you said they
brought it back.  What is it now?  Just an empty include to prevent
#include failures?  (I don't see how that works since the build will
break anyway as soon as a missing constant is referenced...?)

(It seems odd that they bring it back to [not really] avoid build
breakages, but then don't just have it include the new split files to
finish the "backwards compatibility" story...?)

                        ...jim

[Jennifer Godinez]

The sun bug ID is 6897844.

Jennifer

Phil Race wrote:
>
> PS
>
>>>
>>> Is the patch ok?  
>
> yes.
>
> -phil.

[gnu_andrew]

2009/11/3 Phil Race <Phil.Race@...>:

>
>
> Andrew John Hughes wrote:
>
>> My superfluous comment actually referred to the additional request for
>> an OpenJDK bugzilla entry.  I fail to see the point of this, given a
>> Sun bug ID is still needed to commit.  Most of the bugs there just
>> seem to be in danger of bitrotting, and I'd prefer to avoid adding one
>> that's just going to be closed fairly swiftly anyway.  It would be
>> nice if we could use OpenJDK bugzilla IDs for commits, and thus didn't
>> have to hassle Sun employees for Sun bug IDs.  But that still doesn't
>> seem to have been implemented.
>
> Ah .. yes .. well you may be right you don't need that if you
> can push it directly. I keep having to look up that part of the
> process myself. But IIIRC theory its supposed to be used to submit
> patches, not report bugs (sans patch), and you had a patch, which
> is why I suggested it.
>

I guess I'm as confused as you are regarding it, so I've just tended
to go with what I've found to work.

The impression I got from the announcement was that, at the moment,
it's just for posting patches that need a sponsor/mentor to get them
into the repository (i.e. the situations that lead to a 'Contributed
by' tag).
It was supposed to be being developed into something that would
replace the Sun bug ID system altogether for external contributors,
but things seem to have gone no further since the launch
(no doubt in part due to the acquisition and various other things
taking precedence).  As such, it's currently a bit pointless for those
with commit access as a Sun bug ID is still needed, regardless.
Commits were supposed to support using OpenJDK IDs, but this has never happened.

The gory details are at: http://openjdk.java.net/groups/web/bugzilla.html

Stages 2 and 3 have not come to fruition, and even the 'one-line
change' to jcheck hasn't happened.

>>
>>>> Is the patch ok?  If so, could you please allocate it a bug ID.
>>>
>>> I overlooked that in your email. But I already asked Jennifer to allocate
>>> one.
>>>
>>
>> Thanks.  I'll push once it's allocated.
>
> Jennifer says she's doing it now.
>
> -phil.
>

--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[gnu_andrew]

2009/11/3 Jim Graham <Jim.A.Graham@...>:

> Andrew John Hughes wrote:
>>
>> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
>> but I avoided posting this in the original mail because it seems to
>> have changed again between that commit and the final release,
>> presumably due to compatibility issues (XShm.h is back and it's now
>> shmproto.h as seen in the patch).  I've built the repo with this patch
>> here with the old version, and others have built it with the new
>> version; it does work for both.  The same patch is already in Gentoo's
>> ebuild and IcedTea, and a similar patch has been used for the Fedora
>> rawhide RPMs for some time.  It would be good to get it upstream as
>> well.
>
> At first I was going to ask how the existing #include succeeds when the link
> says that Xshm.h is going away, but now I see that you said they brought it
> back.  What is it now?  Just an empty include to prevent #include failures?
>  (I don't see how that works since the build will break anyway as soon as a
> missing constant is referenced...?)
>
> (It seems odd that they bring it back to [not really] avoid build breakages,
> but then don't just have it include the new split files to finish the
> "backwards compatibility" story...?)
>
>                        ...jim
>
>

It's quite convoluted, that's why I was just going to avoid posting
the link, as it makes things even more confusing.  I believe the
reinstated XShm.h does have content that was still needed.

The initial version I linked to did remove XShm.h, so the original fix
for Fedora 12 removed XShm.h, added the two additional headers and
defined some other stuff which I believe was in XShm.h originally.  It
was a pretty nasty patch, hence why it wasn't committed to IcedTea or
OpenJDK.  I gather now that XShm.h is back and has the additional
material in it.  I don't have a copy locally to check, but several
people have said this fix works and Fedora RPMs have been built with
the original fix.  More importantly, I have confirmed myself that it
doesn't break earlier versions, which are still used on the majority
of systems.  It's now several months on from our initial discovery of
the problem and more and more people are asking about this in e-mail
and on IRC, so a general fix is needed and this fits the bill.

Hope that makes some sense!

Thanks,
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[Jim Graham-3]

Yes, indeed, that all makes sense for your fix.  I wasn't intending to
register an objection with the fix, I was just curious about the changes
they made which, as you say, seem quite convoluted...

                        ...jim

Andrew John Hughes wrote:

> 2009/11/3 Jim Graham <Jim.A.Graham@...>:
>> Andrew John Hughes wrote:
>>> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
>>> but I avoided posting this in the original mail because it seems to
>>> have changed again between that commit and the final release,
>>> presumably due to compatibility issues (XShm.h is back and it's now
>>> shmproto.h as seen in the patch).  I've built the repo with this patch
>>> here with the old version, and others have built it with the new
>>> version; it does work for both.  The same patch is already in Gentoo's
>>> ebuild and IcedTea, and a similar patch has been used for the Fedora
>>> rawhide RPMs for some time.  It would be good to get it upstream as
>>> well.
>> At first I was going to ask how the existing #include succeeds when the link
>> says that Xshm.h is going away, but now I see that you said they brought it
>> back.  What is it now?  Just an empty include to prevent #include failures?
>>  (I don't see how that works since the build will break anyway as soon as a
>> missing constant is referenced...?)
>>
>> (It seems odd that they bring it back to [not really] avoid build breakages,
>> but then don't just have it include the new split files to finish the
>> "backwards compatibility" story...?)
>>
>>                        ...jim
>>
>>
>
> It's quite convoluted, that's why I was just going to avoid posting
> the link, as it makes things even more confusing.  I believe the
> reinstated XShm.h does have content that was still needed.
>
> The initial version I linked to did remove XShm.h, so the original fix
> for Fedora 12 removed XShm.h, added the two additional headers and
> defined some other stuff which I believe was in XShm.h originally.  It
> was a pretty nasty patch, hence why it wasn't committed to IcedTea or
> OpenJDK.  I gather now that XShm.h is back and has the additional
> material in it.  I don't have a copy locally to check, but several
> people have said this fix works and Fedora RPMs have been built with
> the original fix.  More importantly, I have confirmed myself that it
> doesn't break earlier versions, which are still used on the majority
> of systems.  It's now several months on from our initial discovery of
> the problem and more and more people are asking about this in e-mail
> and on IRC, so a general fix is needed and this fits the bill.
>
> Hope that makes some sense!
>
> Thanks,

[gnu_andrew]

2009/11/3 Jennifer Godinez <Jennifer.Godinez@...>:

> The sun bug ID is 6897844.
>
> Jennifer
>
> Phil Race wrote:
>>
>> PS
>>
>>>>
>>>> Is the patch ok?
>>
>> yes.
>>
>> -phil.
>

Pushed: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/90bdc961b3cb

Thanks everyone,
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[gnu_andrew]

2009/11/3 Andrew John Hughes <gnu_andrew@...>:

> 2009/11/3 Jennifer Godinez <Jennifer.Godinez@...>:
>> The sun bug ID is 6897844.
>>
>> Jennifer
>>
>> Phil Race wrote:
>>>
>>> PS
>>>
>>>>>
>>>>> Is the patch ok?
>>>
>>> yes.
>>>
>>> -phil.
>>
>
> Pushed: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/90bdc961b3cb
>
> Thanks everyone,
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>

I apologise; I forgot to add the Contributed-by credit for Diego
Pettenò <flameeyes@...>

Can someone add this to the Sun bug report?  I'll make sure it goes on
the version of the fix for OpenJDK6.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[Jennifer Godinez]

Hi Andrew,

I will add it.  Thanks.

Jennifer

Andrew John Hughes wrote:

> 2009/11/3 Andrew John Hughes <gnu_andrew@...>:
>> 2009/11/3 Jennifer Godinez <Jennifer.Godinez@...>:
>>> The sun bug ID is 6897844.
>>>
>>> Jennifer
>>>
>>> Phil Race wrote:
>>>> PS
>>>>
>>>>>> Is the patch ok?
>>>> yes.
>>>>
>>>> -phil.
>> Pushed: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/90bdc961b3cb
>>
>> Thanks everyone,
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>>
>
> I apologise; I forgot to add the Contributed-by credit for Diego
> Pettenò <flameeyes@...>
>
> Can someone add this to the Sun bug report?  I'll make sure it goes on
> the version of the fix for OpenJDK6.

[Anthony Petrov]

On 11/4/2009 12:18 AM Phil Race wrote:
> The superfluous stuff is the copy of the webrev?
> We archive them. Not all groups do that. Swing, AWT and 2D do.
> Occasionally someone may fail to get one from a contribution

My understanding is that a repository contains all the changesets. And
each changeset is just a patch, which is available directly (hg diff),
or via http://hg.ojn/ (which itself is perfectly searchable with
Google). Why would one need another copy of the changes nowdays?

Whilst exploring the history of webrev versions for a particular fix
does indeed help sometimes, this looks quite inapplicable for external
contributions since the internal robot is not available to them. And
submitting all the versions manually through a Sun employee seems sort
of burdensome.


> but its still the theoretical process to have it.

--
best regards,
Anthony