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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
