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

Re: adjustment for `ruby-mdl`



Hello Daniel,

thank your for your note I like to reply to.

* To name "the thing".  Thankfully, there is `gem2deb` to collect and organize
  the relevant data from rubygems and `ruby-mdl` is the name suggested by this
  implementation.  I don't mind the result by `gem2deb` requires additional
  edit (some of the points addressed by the documentation), perhaps including
  a new name *of the package* in Debian.  (E.g., in its documentation, the
  validator `pytest` for Python is called by `pytest`.  With the advent of
  Python 3, Debian & Ubuntu family currently name it `python3-pytest` as
  package, and the call from the CLI is `pytest-3` regardless if there (still)
  is some remain of Python 2 in the hosting installation, or not.)

  Open to an adjustment, I like `ruby-mdl` as package name because it states
  the language of implementation, hence a pattern which allows others an
  implementation in their language of choice (e.g., `python3-markdownlint`).
  It equally is a short name and `mdl` already shows the call sign from the
  CLI. On the other hand, `markdownlinter` would introduce a name different to
  the project's name .and. part of the address on GitHub.
* Split into a binary part and a library part.  Because `ruby-mdl` is the first
  time I package a .deb, this exceeds my expertise.  Do you recommend a
  particular resource to get familiar with this procedure?  Likely related to
  this suggest is the information (i.e., low severity)
  `application-in-library-section` broadcast by `lintian`, prior signing the
  changes file and to engaging `dput mentors`.
* Joining the Debian Ruby team.  OK, it is convincing this could facilitate
  much; possibly including an adjustment of the name space (if it is an issue).
  I file a separate petition of admission to the group (*beyond* the
  subscription to the mailing list).
* The copyright issue.  For one I assume each contribution to `markdownlint`
  recognizes the choice for MIT because the pick for a license known to GitHub
  simultaneously adds the tag to the web site .and. a `LICENSE.txt` to the
  project for you.

  For two, the project discerns between contributors and maintainers (to
  `markdownlint`; three considered active [Mark Harrison no longer is one of
  them]) without an explicit note I spot (so far) "for any contribution to us,
  you transfer your copyright to us" as with publishers.  Because copyright may
  differ by locale, I assumed it were better to err and to list all, than
  omitting one.  (Because the relevant git archaeology was/is relayed to two
  scripts to put elsewhere, the extraction doesn't take much time, either.)

Regards, Norwid


Reply to: