[Bug 532203] Review Reques: jgraph - Java-based Diagram Component and Editor

bugzilla at redhat.com bugzilla at redhat.com
Sun Nov 1 09:57:41 UTC 2009


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


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


D Haley <mycae at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mycae at yahoo.com




--- Comment #1 from D Haley <mycae at yahoo.com>  2009-11-01 04:57:40 EDT ---
Replying to some comments from previous (deadreview) bug (Bug 472793)

Notes
===
$ rpmlint jgraph.spec
jgraph.spec:68: W: non-standard-group Development/Documentation

I believe this can be ignored, as it matches the template spec files in the
java packaging guidelines. 

jgraph.spec:135: W: libdir-macro-in-noarch-package (main package)
%attr(-,root,root) %{_libdir}/gcj/%{name}
Rpmlint is incorrect, rpmlint is failing to detect the %if conditional around
the noarch. So no problems here

So rpmlint output is OK.
===


Items to be addressed:
===

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

>This is pretty much irrelevant to this package review.

I believe it may be relevant, as otherwise your -debuginfo package is broken.
There are workarounds shown in both that bug (bug 472292) and in bug 191014.
Please fix this.

I think this package is almost done. Please post a spec fixing the above and I
will review the package.
===

Random comments:
===
>Umm, no that's definitely not needed for review, feel free to do that yourself
>(technically, one architecture-release combination is needed and there's no
>clear reason why would they fail, nor indication that packager intends to
>create branches for these).

When doing your CVS request, please create a branch for F-11 - its is
definitely not EOL, and is hence *supported*. F-10 is no longer required as it
will very soon be EOL. 

It is not always clear why a given version will fail (sometimes deps are
missing, sometimes compiler crashes, documentation build failure, or whatever
may be the case. 

Providing scratch builds provides assurance that this is not the case. I prefer
not to review packages which may fail to work under any given F- distribution
that is not near EOL.

Note the following SHOULD from the package review checklist:
"SHOULD: The package should compile and build into binary rpms on all supported
architectures."

>I prefer not using dos2unix for endline conversion
>This is a matter of taste and I'd prefer to follow packager's one, thus no
>change here.

Fair enough.

> > Fully standards-compliant (What standard? ISO 9001? Why do I (user) care?)

> Interoperability?

Apologies for the following rant, feel free to skip it as the current
description is good :)

-- BEGIN RANT --
ISO9000 and friends have nothing to do with interoperability
(http://en.wikipedia.org/wiki/ISO_9001). They are workplace quality systems
ISOs, and really have nothing to do with software (or anything really.) They
were popular a few years ago amongst marketing and manager types. It is
entirely possible that upstream is simply being facetious here, as actual
accreditation is a long and complex (and quite boring) procedure, which
individual developers would be unlikely to undertake.
-- END RANT --
===

-- 
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.




More information about the package-review mailing list