This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 398261 - Review Request: redet-doc - Documentation for the Redet tool
Review Request: redet-doc - Documentation for the Redet tool
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Patrice Dumas
Fedora Extras Quality Assurance
:
Depends On: 397211
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-25 05:12 EST by Debarshi Ray
Modified: 2007-12-11 02:39 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-11 02:39:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
pertusus: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Debarshi Ray 2007-11-25 05:12:48 EST
Spec URL: http://rishi.fedorapeople.org/redet-doc.spec
SRPM URL: http://rishi.fedorapeople.org/redet-doc-8.23-1.fc8.src.rpm


Description:

Documentation for the Redet tool provided in HTML format.
Comment 1 Debarshi Ray 2007-11-25 05:31:06 EST
Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=257507

I inherited this package and since there has been a new upstream release since
it was last updated, I would like to pass this through a review.
Comment 2 Patrice Dumas 2007-11-25 06:25:39 EST
There is no explicit license for the manual (as far as I can
tell), so I guess that GPLv2 like for redet is the best choice
for the license?

I would suggest dropping the %{?dist} since this is not dist
specific.

I would also suggest dropping the dependency on redet. One
may want to browse the documentation without having redet 
installed. You could add a conflict for older redet versions,
but I don't think it is worth it.
Comment 3 Debarshi Ray 2007-11-25 08:04:29 EST
(In reply to comment #2)

> There is no explicit license for the manual (as far as I can
> tell), so I guess that GPLv2 like for redet is the best choice
> for the license?

Upstream re-released the 8.23 tarball. Redet is now GPLv3, and upstream thinks
that the manual should be GPLv3 as well.

> I would also suggest dropping the dependency on redet. One
> may want to browse the documentation without having redet 
> installed.

Most -doc packages (python-docs, bouml-doc) have the parent packages as a
dependency.
Comment 4 Patrice Dumas 2007-11-25 08:21:46 EST
(In reply to comment #3)
> (In reply to comment #2)
> 
> > There is no explicit license for the manual (as far as I can
> > tell), so I guess that GPLv2 like for redet is the best choice
> > for the license?
> 
> Upstream re-released the 8.23 tarball. Redet is now GPLv3, and upstream thinks
> that the manual should be GPLv3 as well.

Indeed I have seen that in the redet review. It is a bit 
confusing since in the doc, unless I am wrong it is referred to 
the GPLv2, but it is indeed better to mark it as GPLv3 like redet.

> > I would also suggest dropping the dependency on redet. One
> > may want to browse the documentation without having redet 
> > installed.
> 
> Most -doc packages (python-docs, bouml-doc) have the parent packages as a
> dependency.

But is it really right? Wouldn't it be better to be able to 
browse the documentation without actually installing the program?
Having other packages do one thing doesn't mean it is the best
choice.

I personally avoid having doc packages depend on the main package
in my packages (for example libdap-doc) and I advise against this 
in reviews. Now if you prefer to depend on the main package, I'm
fine with it, it was just a suggestion.

In any case I verified that it matches upstream, so it is 

APPROVED

Still, please consider dropping %{?dist}, it seems to me that it
is especially unndeeded or even harmful in that case -- but I won't
make that a blocker either.
Comment 5 Debarshi Ray 2007-11-25 09:23:10 EST
(In reply to comment #4)
 
> But is it really right? Wouldn't it be better to be able to 
> browse the documentation without actually installing the program?
> Having other packages do one thing doesn't mean it is the best
> choice.

Alright, I will remove the dependency.

> Still, please consider dropping %{?dist}, it seems to me that it
> is especially unndeeded or even harmful in that case -- but I won't
> make that a blocker either.

Alright. I am just curious as to why it might be harmful.
Comment 6 Debarshi Ray 2007-11-25 09:27:19 EST
New Package CVS Request
=======================
Package Name: redet-doc
Short Description: Documentation for the Redet tool
Owners: rishi
Branches: F-7 F-8
InitialCC: 
Cvsextras Commits: no
Comment 7 Patrice Dumas 2007-11-25 10:09:47 EST
(In reply to comment #5)
> (In reply to comment #4)
> > Still, please consider dropping %{?dist}, it seems to me that it
> > is especially unndeeded or even harmful in that case -- but I won't
> > make that a blocker either.
> 
> Alright. I am just curious as to why it might be harmful.

It leads to different package names for different dist and
may trigger unneeded update between releases. Also depending
on how the buildsystem is set up it may avoid redundancy.
Comment 8 Debarshi Ray 2007-11-26 11:07:41 EST
Spec: http://rishi.fedorapeople.org/redet-doc.spec
SRPM: http://rishi.fedorapeople.org/redet-doc-8.23-2.src.rpm

- Removed dist tag.
- Removed dependency on redet.
Comment 9 Kevin Fenzi 2007-11-26 12:45:06 EST
cvs appears up to date. You are the owner in those branches. 
Please feel free to reset the flag if you need anything further. 

Also, as with redet, would you consider maintaining the EPEL branches as well?

Note You need to log in before you can comment on or make changes to this bug.