[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: ruby-rubyforge and ruby-hoe

Excerpts from Lucas Nussbaum's message of Thu May 19 23:04:57 -0700 2011:
> On 19/05/11 at 14:56 -0700, Clint Byrum wrote:
> > Hello everyone.
> > 
> > At Lucas's suggestion, I've pushed a fixed ruby-hoe with the offending PDF file removed, so
> > it should be uploaded for NEW processing.
> > 
> > I've also pushed a new package into the git repository, ruby-rubyforge. I tagged it as released
> > already, sorry for that. If someone can upload that as well, I'd be eternally grateful.
> Hi,

Hi Lucas, thanks for the thorough review. I'm a bit embarrassed how many
things you found to fix. See below.

> Usually, I do not bother with filing ITPs

I won't anymore.. since I can look in the git repository to see if there
is already work being done.

I've made some fixes but alioth is down right now so can't push them up.
So all of the things marked "Done" will be pushed when alioth returns.

> ruby-hoe
> ========
> There are commented out lines in debian/control

I left this there because minitest will be added here as soon as it is
bootstrapped by having ruby-hoe available. Should we move these to
README.source, to be removed when the tests are re-enabled?

> The description should probably not link to the PDF, not point to the
> doc.

Is that because we don't like the pdf, or because this is considered
bad form to put urls in the description? Its a very useful document,
even if we can't rebuild it ourselves, and it meets the spirit of the
guideline that the long description should help users decide whether or
not to install the package.

> In README.source, mention the removal of the pdf


> There's a debian/patches/debian-changes-2.9.4-1 that should be turned
> into a proper patch or removed.


> ruby-rubyforge
> ==============
> (Looks like you are using an old gem2deb version, according to the
> BUild-Depends line)

Oops, done.

> The description needs to be edited to fit the Debian description
> guidelines. You can't just reuse the gem description.

Reformatted per http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html

> (Build-)Depend on ruby-json.
> follow the Depends guidelines in RubyInWheezy (ie ruby |
> ruby-interpreter, in this case)
> FIXME in ruby-rubyforge.docs

All done.

> ruby-echoe
> ==========
> UNRELEASED -> unstable

This is something I'd think we might want to consider for
the git repository... dch --release and debcommit --release
go hand in hand quite nicely and it helps to defer tagging
until the actual upload. 

That said, done.

> Depends => ruby | ruby-interpreter
> I'm not sure the description is enough. What does it do? Allow the user
> to factor out common tasks? How is it different from hoe, then?

Added a comparison to Hoe.

> If you patched the require rubygems, why do you still need an override?

Good Question. I originally set out to patch it out, but now I see thats
a bit silly. Removed the patch.

> FIXME in ruby-hoe.docs


Reply to: