Re: RFS: ruby-rubyforge and ruby-hoe (+ ruby-echoe)
Hi Clint,
Any news on that?
- Lucas
On 25/05/11 at 08:59 +0200, Lucas Nussbaum wrote:
> 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: