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@xxxxxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Flag|needinfo?(tcallawa@xxxxxxxxx| |m) | ------- Additional Comments From fedora@xxxxxxxxxxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review