Re: Git Packaging Round 2: When to Salsa
On Sun, 15 Sep 2019, Jonas Meurer wrote: > Sam Hartman: > >> "Bastian" == Bastian Blank writes: > > > > Bastian> Hi Sam > > Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote: > > >> The Salsa CA pipeline is recommended. > > > > Bastian> For this I need to use my veto as Salsa admin. With the CI > > Bastian> people we have to work through too much problems first. > > > > [...] > > I'll remove it from the next version. > > Please don't. It would be a shame if we would *not* recommend to use the > awesome Salsa CI pipeline for automated continuous testing of package > development. I applaud the Salsa-CI's team for their effort, it's a huge > step forwart for Debians QA standards. > > I also honestly appreciate all the hard work that the Salsa admins put > into running Salsa, but it's absolutely not acceptable how they try to > missuse the power of their role by behaving as Salsa dictators. They? Since noone Cced me, I wasn't even aware of this discussion. So please don't they unless it is something offical from the team (such things will not hidden in a long thread). Alex signature.asc Description: PGP signature
Re: Git Packaging Round 2: When to Salsa
On Sat, Sep 14, 2019 at 07:44:44PM +0200, Inaki Malerba wrote: > On 13/9/19 15:20, Bastian Blank wrote: > > For this I need to use my veto as Salsa admin. With the CI people we > > have to work through too much problems first. > If there are _too much problems_ I think you should, at least, > communicate with us. I opened several issues now. Most of them are about reduction of resource usage. In combination with the changes I did to Salsa, those should be at least a step in the right direction. I haven't looked deep enough for a complete overview. > Forbidding something you don't like without further explanation doesn't > seem to be the best way to go (applies to all Salsa matters). If you do stuff ten or hundred times, we don't care. If you do it a thousand or more times, we start to care. We told people a lot of times to think before doing and be light with the available resources. > > On 13/9/19 18:00, Sam Hartman wrote: > > Are there additional resources either the salsa admins or the salsa CI > > team needs to move forward to a place where you'd both feel comfortable > > recommending Salsa CI? > It would be great to find a way to discuss things between Salsa admins > and users. It's been one way only so far. The communication is more no-way. You once just added callouts to an external service of your choice to all jobs you controlled, leaked information about private repositories, without telling users, and managed to ignore errors while asking the API using the leaked data. Regards, Bastian -- Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant." -- Kirk, "The Ultimate Computer", stardate 4731.3
Bug#941983: ITP: hey -- hey is a tiny program that sends some load to a web application.
Package: wnpp Severity: wishlist Owner: Arthur Diniz * Package name: hey Version : 0.1.2 Upstream Author : Jaana B. Dogan * URL : https://github.com/rakyll/hey * License : Apache-2.0 Programming Lang: Go Description : hey is a tiny program that sends some load to a web application. hey was originally called boom and was influenced from Tarek Ziade's tool at tarekziade/boom. Using the same name was a mistake as it resulted in cases where binary name conflicts created confusion. To preserve the name for its original owner, we renamed this project to hey.
Bug#941976: ITP: apiguardian -- Level of stability annotation for frameworks or applications
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: apiguardian Version : 1.1.0 Upstream Author : Marc Philipp, Sam Brannen * URL : https://github.com/apiguardian-team/apiguardian * License : Apache-2.0 Programming Lang: Java Description : Level of stability annotation for frameworks or applications API Guardian provides the @API annotation that is used to annotate public types, methods, constructors, and fields within a framework or application in order to publish their status and level of stability and to indicate how they are intended to be used by consumers of the API. This package this a dependency of JUnit 5. It'll be maintained by the Java Team.
InstallBootstrap (was: Re: Debian and our frenemies of containers and userland repos)
Hi, Quoting Jonas Smedegaard (2019-10-08 10:30:45) > Quoting Paul Wise (2019-10-08 02:35:14) > > On Mon, 2019-10-07 at 11:29 +0100, Simon McVittie wrote: > > > I think "re-bootstrap, don't upgrade" is an equally good principle for > > > autopkgtest and sbuild? Both will be equally susceptible to accumulating > > > cruft during upgrades that wouldn't have been there in a fresh > > > debootstrap, > > > which is undesired if you want the invariant that you are > > > (building|testing) > > > in "today's" minimal environment. > > debootstrap uses a fair bit more time and resources than apt upgrade, > > so I think that both are needed. > This seems a good place to mention mmdebstrap as a speedier alternative to > deboostrap. while I certainly welcome use of my software, let me also use this opportunity for a word of caution. One of the core reasons why I created mmdebstrap was to create a proof-of-concept for the idea that it should at some point be possible to create a chroot of Debian (or a derivative) without all the magic instructions which currently live in debootstrap and cdebootstrap. Instead, all necessary information should live in the packages themselves using the same component-centric way of thinking we apply to other engineering decisions in the distribution. An extended rationale can be found on the following wiki page and in the bugs it links to in the first section: https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap But as of today, the problem is not solved. So that mmdebstrap works today (and has been working in stable, testing and unstable for the past year) is unfortunately more like happenstance than due to some ingenuity on the part of mmdebstrap. Thanks! cheers, josch signature.asc Description: signature
Bug#941970: ITP: junit5 -- JUnit regression test framework for Java
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: junit5 Version : 5.3.2 Upstream Author : Sam Brannen, Marc Philipp and contributors * URL : https://junit.org/junit5/ * License : EPL-2.0 Programming Lang: Java Description : JUnit regression test framework for Java JUnit is a framework to write repeatable tests. Unlike previous versions of JUnit, JUnit 5 is composed of several different modules from three sub-projects: JUnit Platform, JUnit Jupiter and JUnit Vintage. The JUnit Platform serves as a foundation for launching testing frameworks on the JVM. It also defines the TestEngine API for developing a testing framework that runs on the platform. Furthermore, the platform provides a Console Launcher to launch the platform from the command line and a JUnit 4 based Runner for running any TestEngine on the platform in a JUnit 4 based environment. First-class support for the JUnit Platform also exists in popular IDEs and build tools. JUnit Jupiter is the combination of the new programming model and extension model for writing tests and extensions in JUnit 5. The Jupiter sub-project provides a TestEngine for running Jupiter based tests on the platform. JUnit Vintage provides a TestEngine for running JUnit 3 and JUnit 4 based tests on the platform. This package will be maintained by the Java Team.
Bug#941965: ITP: univocity-parsers -- Parsers for CSV, TSV and fixed width files
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: univocity-parsers Version : 2.8.3 Upstream Author : Univocity Software Pty Ltd * URL : https://www.univocity.com/pages/about-parsers * License : Apache-2.0 Programming Lang: Java Description : Parsers for CSV, TSV and fixed width files univocity-parsers is a collection of extremely fast and reliable parsers for Java. It provides a consistent interface for handling different file formats, and a solid framework for the development of new parsers. This package this a dependency of JUnit 5. It'll be maintained by the Java Team.
Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]
On Tue, 08 Oct 2019, Holger Levsen wrote: > On Mon, Oct 07, 2019 at 09:22:46PM -0400, Sam Hartman wrote: > > [...] as a last opportunity for > > others to comment. > > what's the deadline to grok this 20k and respond? It's in the subject: [comments by 11/05/2019] November 5th. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ signature.asc Description: PGP signature
Re: Debian and our frenemies of containers and userland repos
Quoting Paul Wise (2019-10-08 02:35:14) > On Mon, 2019-10-07 at 11:29 +0100, Simon McVittie wrote: > > > I think "re-bootstrap, don't upgrade" is an equally good principle for > > autopkgtest and sbuild? Both will be equally susceptible to accumulating > > cruft during upgrades that wouldn't have been there in a fresh debootstrap, > > which is undesired if you want the invariant that you are (building|testing) > > in "today's" minimal environment. > > debootstrap uses a fair bit more time and resources than apt upgrade, > so I think that both are needed. This seems a good place to mention mmdebstrap as a speedier alternative to deboostrap. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#941963: ITP: opentest4j -- Open Test Alliance for the JVM
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: opentest4j Version : 1.2.0 Upstream Author : Marc Philipp, Sam Brannen * URL : https://github.com/ota4j-team/opentest4j * License : Apache-2.0 Programming Lang: Java Description : Open Test Alliance for the JVM OpenTest4Jj provides a minimal common foundation for testing libraries on the JVM. The primary goal of the project is to enable testing frameworks like JUnit, TestNG, Spock, etc. and third-party assertion libraries like Hamcrest, AssertJ, etc. to use a common set of exceptions that IDEs and build tools can support in a consistent manner across all testing scenarios -- for example, for consistent handling of failed assertions and failed assumptions as well as visualization of test execution in IDEs and reports. This package this a dependency of JUnit 5. It'll be maintained by the Java Team.
"adt-virt-*" abstraction (was Re: Debian and our frenemies of containers and userland repos)
fwiw, src:piuparts also includes a (now) derived implementation of "adt-virt-*"... -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
