Bug#929258: ITP: ruby-zeitwerk -- Efficient and thread-safe constant autoloader
Package: wnpp Severity: wishlist Owner: Jongmin Kim * Package name: ruby-zeitwerk Version : 2.1.6 Upstream Author : Xavier Noria * URL : https://github.com/fxn/zeitwerk * License : Expat Programming Lang: Ruby Description : Efficient and thread-safe constant autoloader Zeitwerk implements constant autoloading with Ruby semantics. Each gem and application may have their own independent autoloader, with its own configuration, inflector, and logger. Supports autoloading, preloading, reloading, and eager loading. This package is a dependency of Rails 6.0.0.
Re: NMUs: Do we want to Require or Recommend DH
On Wed, May 15, 2019 at 11:31:46AM +0200, Enrico Zini wrote: >... > - if a package has had an inactive and unresponsive maintainer for a >long time, it would indeed be a case for salvaging. > >I could however imagine someone having enough energy to dust off old >packages in the archive, while not having enough energy to pick up >maintenance of lots of old dusty packages. Does the person have the energy to properly test that the changes don't cause any regressions? Uploading invasive changes in packages you don't use is usually a bad idea, and if it ain't broken don't fix it. >I would consider the idea of salvaging+orphaning, like following the >salvaging procedure but setting the maintainer to qa instead. >... Such salvaging+orphaning instead of following the proper MIA process would be abusive behaviour. Even more if it is just for a packaging change that would be expected to result in the same binary packages. In the worst case you get a pissed off maintainer leaving the project, and an orphaned package with some RC regression caused by the change. Without any actual benefits of the whole change. > With a consensus of having dh as the default build system, and the > understanding that some packages have good reasons not to use dh, I'd > like a way to tell when a package is not using dh for a reason, from > when a package is not using dh because the maintainer has not gotten > around to it yet. > > I'd propose to recommend dh as the default build system, and document in > README.source if there are reasons to use something else. > > At that point, one could look at README.source to see if changing build > system would be an possible strategy for fixing bugs in an NMU. >... There's a much easier (and faster!) solution that has already been used in the past: For migrating away from dpatch someone made the changes to the packages, and then sent the debdiffs to the BTS. If the maintainer liked the change, it was applied. If the maintainer was MIA, the patch was applied whenever the package was orphaned later. For a standard conversion to 3-line dh not much is lost if some of the patches end up being rejected. For non-trivial conversions it also sets the right incentive that the person doing the change contacts the maintainer first, NMU plus revert of the NMU would be a solution inferior to asking the maintainer before doing plenty of work. > Enrico cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: NMUs: Do we want to Require or Recommend DH
On Wed, May 15, 2019 at 03:22:16PM +0200, Andreas Tille wrote: On Wed, May 15, 2019 at 02:09:14PM +0200, Benjamin Drung wrote: Am Mittwoch, den 15.05.2019, 11:31 +0200 schrieb Enrico Zini: Or introduce a lintian check for not using dh. Then the maintainer could override lintian and document the reason for it in the override. ... but I think the documented lintian override is better since it is more connected to code than free text. I agree; also, the new lintian check/warning showing up in places like Tracker may help adoption of the documentation (as an override) to happen across the distribution more quickly. -- Jonathan Dowland
Re: Official non-official Debian backporting versioning scheme
On Sunday, May 19, 2019 3:41:59 PM EDT Lisandro Damián Nicanor Pérez Meyer wrote: > I would like to ask/get a consensus on a sensible "official > non-official" Debian backporting version scheme for 3rd party > packages. > > The goal is to be able to provide non-official packages that do > integrate within current Debian ones *but* do not interfere with > normal Debian stable/backports. > > I think an example will help here. My main goal is to be able to > provide [1] Qt backports. Due to Qt's private API usage of third party > packages (kwin, for example) we Qt/KDE maintainers can't provide an > official Debian backport package, as it would require binNMUs of > stable packages living in backports :-/ > > [1] source at first maybe, amd64 later if I can get the necessary > build power and bandwith. > > Yes, being"official non official" packages things might break, but > think of it as a PPA that blends and plays as nice as possible within > Debian. > > Normally one should propose an idea of how this versioning should be, > but I'm currently not sure of a nice way and I'm also pretty sure I'm > not the first one who thinks about this, so... ideas? > > Regards, Lisandro. I don't know that we need an official project consensus on this, but I'll offer a suggestion. In Debian we use version-revision (where revision is sometimes complex for backports and stable updates). If you use version-~revision where revision is some thing similar to, but different than that used for security updates, stable updates, or backports, you could be reasonably assured that your non- official version would also sort to a lower revision than the same upstream version from any official repository. Scott K
