On Thu, 15 Aug 2013 16:30:49 +0200, intrigeri wrote: > The BoF did happen, and here are the minutes. Don't hesitate grep'ing > your name in there to fill your personal TODO list with anything you > committed to ;) And some time later we might want to take a look at what has happened and what we might want to tackle next ... > Lancaster Consensus > =================== > http://www.dagolden.com/index.php/2098/the-annotated-lancaster-consensus/ > General remark - need point of contact with the participants of the > Lancaster consensus (toolchain mailing list?) Is anyone on this mailing list? Or on other fora? Or is having mst on IRC enough? :) > Environment variables for testing contexts > ------------------------------------------ > We probably should always set AUTOMATED_TESTING and NONINTERACTIVE_TESTING. > (in debhelper/cdbs ?! unless they are set already --> check --> debhelper doesn't) I had thought that there was some activity here but either I can't find it or I confused it with dam's initiative to make builds verbose (#714546). So this seems like a still pending TODO item. Anyone interested in this topic? > Post-installation testing > ------------------------- > The way I read the Lancaster Consensus, Perl modules would just run > their existing build-time tests again, so the results should be > similar (modulo bloated systems) as for archive-wide rebuilds (but > relevant test runs could be triggered by uploads) > > Supporting DEP-8 (instead or in addition to CPAN post-inst testing) > should be easy to implement via mass-commit for basically all our > packages. > > Enables users to run tests themselves. > > Could run these tests (again) on rev-deps? It "should be easy" but AFAICS it hasn't been implemented yet :) Anyone interested in this topic? (Also: see below re "jenkins".) > Two years git > ============= > Experiences, needs for clarifying, streamlining, improving workflows? > * git packaging following upstream?? > git-import-orig --upstream-vcs-tag= makes it easy. > See debconf-discuss recent discussion, it has more details about > how this works. [abe can add that to the docs] I'll start a separate subthread about this question. > * At least one of us doesn't like not having the patches applied in the master branch. > David Bremner will look at the workflows that do it otherwise > => know what it would involve to go this way Well, ... anything new? :) > Low-hanging fruits meetings > =========================== First one initiated by intrigeri, merci ! > pkg-perl-tools package > ====================== This one exists! More contributions are always welcome. > Status report of the Perl 5.18 migration > ======================================== Done :) Except for the remaining bugs :( Since then a couple of packages have been removed from testing; my proposal would be the remove them from the archive completely (criteria: RC-buggy/FTBFS with 5.18, no rdeps, no activity in the CPAN RT tickets). What do others think? And speaking about transitions: What's the status of the Perl 5.20 migration? :) Just curious: Niko, Dom: Do you already have any schedules? From my naïve POV, 5.20 should be released in May, and the freeze will happen on the 5th of November, so we might be able to get a current Perl version into a stable release ... Does this make sense? > Ideas for Jenkins jobs? > ======================= > h01ger wanted to run group-specific jenkins jobs. the more the better. > possible to rebuild after every push > action: XTaran helps integration Anything new? > lintian profile > =============== > TBD > lintian supports additional checks that could be useful for > introducing group-wide policy checks The profile with a few tests exists in the pkg-perl-tools package \o/ More tests are always welcome. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `-
Attachment:
signature.asc
Description: Digital signature