[Bug 426883] Review Request: brazil - Extremely small footprint Java HTTP stack

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: brazil - Extremely small footprint Java HTTP stack


https://bugzilla.redhat.com/show_bug.cgi?id=426883


fedora at matbooth.co.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |ASSIGNED
               Flag|needinfo?(tcallawa at redhat.co|
                   |m)                          |




------- Additional Comments From fedora at matbooth.co.uk  2008-04-17 15:53 EST -------
(In reply to comment #6)
> Nice job, Mat!  A very clean package.  Here's my review.  Everything's good to
> go pending spot's legal approval of the fetching (see the last question below,
> spot).  Assuming that is given the go-ahead, this package is APPROVED.
> 

Thanks. :-)

> MUST items that either have comments or need looking into:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> * verify source and patches (md5sum matches upstream, know what the patches do)
>   - the tarball I created using your script didn't have the same md5sum as
>     yours, but a recursive diff of the exploded tarball resulted in no
>     differences so I'll assume it's a timestamp thing

I didn't try md5sum, but you're right. The sum changes every time I run the
download script. It strips out all the pre-built binaries and source that isn't
used in the build or is licenced differently before tarballing. This can be done
at build time instead if it's a problem.

> ? specfile is legible
>   - two grammar nit-picks (feel free to ignore my pedantry if you wish ;) :
>     "URL based" -> "URL-based"
>     "java" -> "Java"
> 

No problem, I'll change them.

> Questions:
> 
> - does upstream not provide any build mechanism?

Yes, but their ant script is incomplete (missing Javadoc build, mostly). I think
it'll be easier to maintain a separate script than to massively patch upstream's
in this case.

> - have you considered offering upstream your build.xml?

I have now. I may shoot an email at their mailing list about it...

> - your signal-handling patch doesn't affect runtime, right?

That's the real question. I have only ever used brazil as part of the EPIC Perl
Eclipse plugin and since that is the only package that uses it, I've only tested
it as part of that. The is no, as far as I can tell. Eclipse is able to stop and
start the brazil server and CGI process without problem for my CGI Perl projects.

The reason for patch was to get it building on GCJ, however it does build
without the patch on the OpenJDK. What would be the right thing do here, drop
support for GCJ in favour of less modifications to the upstream code?

> - is the script for fetching the source acceptable to Fedora "legal" (CCing
>   spot)?  To download myself I had to click through to accept the SPL.

I wanted to make it an easy and automated process, since I'm lazy like that. The
SPL licence is included in the main package and the source files are each headed
with licence information, though alternative download instructions could be
included if I fail a Spot check. :-)

Thanks for your time.

PS, did you mean to assign the bug to me?

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.