Re: RFS: ruby-rubyforge and ruby-hoe (+ ruby-echoe)
On 20/05/11 at 09:32 -0700, Clint Byrum wrote:
> 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?
I'm not sure of what you mean: ruby-minitest is available in Debian.
> > 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.
This is because:
1) the description is not the correct place to link to documentation
2) that documentation is non-free until the contrary is proven
> > 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
Well, still not good enough, I think. I would write something such as:
Description: automation of some Rubyforge operations
This Ruby script and library implements a command line interface to
a subset of operations that one can perform on Rubyforge (a forge
dedicated to projects related to the Ruby programming language).
The library can be used to implement Rubyforge-related actions in
Rakefiles.
> > 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.
Basically, the rule is:
- if the package is not ready for review/upload, use UNRELEASED
- once you think the package is ready, set to unstable
That way, if everything is fine the sponsor just uploads and tags.
> > 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
>
> Done.
That package otherwise looks fine, but needs ruby-rubyforge, so not uploading yet.
- Lucas
Reply to: