Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak
Hello Tobias, > "Tobias" == Tobias Frost writes: Tobias> You should be able to just re-upload to mentors. If it does Tobias> not allow that, remove the package manually from mentors, Tobias> then re-upload. In the case a bot auto-close this RFS bug, Tobias> just manually re-open it (do not file a new one) Indeed, I've done it without a problem. Thus, I've re-uploaded all my packages, not only Multispeech. And, since the issues listed are actual for other my packages as well, I tried to address them their as well. Tobias> On further iterations, you keep at -1 until this is Tobias> sponsored. But some things should be fixed on the upstream level. Of course, I can do it with Debian patches, but is it a point when I am an upstream developer myself? How should I act in this situation? Best regards, Igor.
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Nicholas D Steeves writes: > Xiyue Deng writes: > >> Nicholas D Steeves writes: >> >> >>> Have you asked upstream to tag a release? >>> >> >> Not before your review but done by now at [1] > > Thank you. You may have heard that Debian is a distribution that > privileges the stable release model... When the human maintainer of a > Debian package tracks stable releases, why is importing a snapshot > justified? > There are about 3 years of newer commits since 1.1.0, and one of the major changes is that it adds support of scala 3 syntax which is not yet in a tagged release and would be good to have. Also seeing the last commit is from the end of last year, I sense that upstream may becoming a bit dormant for the time being, which is why I prefer to package the latest snapshot instead of waiting for a stable release. > Also, do you use this package? > Not on a regular basis, but I do use it a bit once in a while as I try to learn a bit of new programming languages every few months. * Override clean rules in d/rules to fix building. (Closes: #1052917) >>> >>> I believe you already know that >>> >>> override_dh_auto_clean: >>>/bin/true >>> >>> is an incorrect approach. >>> >> >> Indeed it was not ideal. Upstream depends on Cask to generated the >> scala-mode-pkg.el file that is used in the clean target to get the name >> of the generated tarball, and indeed using this lazy approach is >> incorrect. I've now included the generated pkg file through a patch to >> make this work in [2]. > > Consistency is essential between an explanation (in a comment or > changelog) and the work that was done. > > Statically defining package metadata is fine, but in this case you can't > claim that you're generating the pkg.el file. Oh yes it's generated using Cask following upstream practice. I just include it as a patch as we don't use Cask for Debian packaging. > Either make the changelog and patch description consistent with what > is actually happening, or change the implementation so that something > is actually generated (there are multiple approaches here). I think I > tend to use makefile substvars for this. Personally I prefer not to patch upstream source if not necessary, otherwise we end up carrying the patch for the foreseeable future. Though arguably in this case the scala-mode-pkg.el file needs to be generated/patched which requires I use Cask locally, so it's more or less the same effort. And then I just realized: why not just host the scala-mode-pkg.el file and substitute the version so that we don't need to update it manually on each update? This is now implemented at [1]. > Do you see what will happen when the package is updated to > 1.1.1 or newer? Also, why did you choose to set the version to "0.23" > rather than "1.1.0"? Well I didn't choose it (if I did I'd use 1.1.0 :) This is the version specified in scala-mode.el[2]. > Did you verify that elpa package version is consistent with the > upstream version of the Debian package in bin:elpa-scala-mode that is > consumed by users (the binary package)? > I tried install it from stable.melpa.org and yeah it's being installed as scala-mode-0.23 even if it's registered as version 1.1.0 there[3]. So it's consistent in a sense :P Anyway, I have just made a pull request to update this upstream[4] so hopefully the versioning will be sane. * Modernize d/watch using special substitute strings. >>> >>> Ok, but why? >>> >> >> I believe this provides a more robust way of detecting tags and should >> be an encouraged practices. From my own experience, when I find a >> d/watch file that doesn't work I may search for other packages to learn >> from existing practices, and some may not work well as different >> upstream may follow different conventions. The substitute strings use a >> more robust and tested regexp that works most of the time, and promoting >> its use may save people's time instead of working on an ad-hoc regexp. > > Sounds good! This is the kind of rationale that should be in the > changelog, so please add it there :) From now on, read your changelog > and patche desriptions, and imagine I'm asking you "ok, but why" for > each point. Yes, rarely something is self-evident and/or an > implementation detail, but most of the time you should say a few words > explaining "why"--particularly when you want to find a sponsor quickly. > My expectation is that you get better at this with each review, and that > you will apply everything you learned to all pending sponsorship > requests in addition to future ones. > Ack, and good suggestion! I have slightly extended the entry with the rationale[5]. PTAL. * Add more metadata in d/upstream/metadata. >>> >>> https://github.com/hvesalai/emacs-scala-mode/commits/master >>> >>> is a git history log, not a changelog nor release notes. >>> >> >> I thought the git history log may be considered an alternative form of a >> Changelog. Looks like I was
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Xiyue Deng writes: > Nicholas D Steeves writes: > > >> Have you asked upstream to tag a release? >> > > Not before your review but done by now at [1] Thank you. You may have heard that Debian is a distribution that privileges the stable release model... When the human maintainer of a Debian package tracks stable releases, why is importing a snapshot justified? Also, do you use this package? >>>* Override clean rules in d/rules to fix building. (Closes: >>>#1052917) >> >> I believe you already know that >> >> override_dh_auto_clean: >>/bin/true >> >> is an incorrect approach. >> > > Indeed it was not ideal. Upstream depends on Cask to generated the > scala-mode-pkg.el file that is used in the clean target to get the name > of the generated tarball, and indeed using this lazy approach is > incorrect. I've now included the generated pkg file through a patch to > make this work in [2]. Consistency is essential between an explanation (in a comment or changelog) and the work that was done. Statically defining package metadata is fine, but in this case you can't claim that you're generating the pkg.el file. Either make the changelog and patch description consistent with what is actually happening, or change the implementation so that something is actually generated (there are multiple approaches here). I think I tend to use makefile substvars for this. Do you see what will happen when the package is updated to 1.1.1 or newer? Also, why did you choose to set the version to "0.23" rather than "1.1.0"? Did you verify that elpa package version is consistent with the upstream version of the Debian package in bin:elpa-scala-mode that is consumed by users (the binary package)? >>>* Modernize d/watch using special substitute strings. >> >> Ok, but why? >> > > I believe this provides a more robust way of detecting tags and should > be an encouraged practices. From my own experience, when I find a > d/watch file that doesn't work I may search for other packages to learn > from existing practices, and some may not work well as different > upstream may follow different conventions. The substitute strings use a > more robust and tested regexp that works most of the time, and promoting > its use may save people's time instead of working on an ad-hoc regexp. Sounds good! This is the kind of rationale that should be in the changelog, so please add it there :) From now on, read your changelog and patche desriptions, and imagine I'm asking you "ok, but why" for each point. Yes, rarely something is self-evident and/or an implementation detail, but most of the time you should say a few words explaining "why"--particularly when you want to find a sponsor quickly. My expectation is that you get better at this with each review, and that you will apply everything you learned to all pending sponsorship requests in addition to future ones. >>>* Add more metadata in d/upstream/metadata. >> >> https://github.com/hvesalai/emacs-scala-mode/commits/master >> >> is a git history log, not a changelog nor release notes. >> > > I thought the git history log may be considered an alternative form of a > Changelog. Looks like I was wrong except for projects that requires the > same format across changelog/git history/release notes. I've dropped > that line in [3]. Thank you. Re: "projects that requires the same format across changelog/git history/release notes": Changelogs, NEWS files, and release notes are three (or arguably two) distinct types of documentation that are also distinct from VCS history. This isn't a superficial formatting or style thing, because they have different audiences and purposes. I think that the kind of changelog that you're probably thinking of it when upstream takes git's shortlog history, puts it in a file, and edits it so that it makes sense. >>>* Update year and Upstream-Contact and add myself in d/copyright. >> >> Why did you add yourself? >> https://en.wikipedia.org/wiki/Threshold_of_originality >> >> I'm happy to support your claim, but you'll need to work for it in more >> than a "sweat of the brow"/mechanical sense. >> > > To be honest, the only reason I did this is to suppress the > "update-debian-copyright" lintian warning which is actually > experimental. I believe what I did was in the same nature as Sławomir > did in 2020 though admittedly not to the same extent, so I've reverted > this part in [4]. Cool. Yeah, lintian has these tags: error, warning, info, pedantic, experimental. Which ones do you think are suggestions, and which one[s] require a mandatory fix? Note that suggestions are occasionally highly opinionated and conflict with team policy. As ever, it's not sufficient to simply react to lintian: ie "lintian made me do it!". >>>* Use xz compression in d/gbp.conf. >> >> Why is this useful when it has been the default since gbp 0.9.15? >> > > I'm pretty sure that if I don't add this "git deborig" will create the > tarball
Bug#1053565: RFS: openvpn3-client/20+dfsg-1 [ITP] -- virtual private network daemon (version 3)
>> * Package name : openvpn3-client > BTW, why it is named this way? > Is it client-only now, without the server part? > Previous package is named just "openvpn", it acts > as both client or server (actually the two roles are > symmetric, it can be both). If new openvpn is like > this, I suggest naming it just "openvpn3", without > the -client part, since it is quite confusing. > Or is there also -daemon (or -server) part? Sorry, missed your e-mail. This is not the same as the openvpn packages, this is a different implementation from the same company. At the moment, they have only released the client part. This implementation has functionality for 2-factor authentication that openvpn2 does not have. The package that upstream releases is openvpn3-linux (source) or openvpn3 (package). I have named it openvpn3-client to 1. Make it clear that this is only the client part 2. Prepare for future releases that include a server part There internal software structure is already split into different parts; but they release a collapsed archive for the client only. -- g. Marc GPG: 827C FD74 BA46 8152 A041 F3A0 7A6A 4F17 5995 A65B
