Re: A proposal for improving transparency of the FTP NEW process

[Chris Lamb]

Hi Lars & Steve,

> > Or possibly you have a more generous notion of "fast".  Currently there
> > are five or six dozen packages waiting more than 2 months
[…]
> There may be other reasons why some packages stay in NEW for a long
> time. Getting information from ftp masters about the reasons why

A good proportion of these have outstanding issues that are blocking
on the maintainer, not the FTP team.

This is, of course, not very obvious or initiutive and improved
transparency on this would obviously be a beneficial to all parties,
let alone Debian at large.

> I wish text/plain carried font information so I could use a font to
> indicate when I'm being sarcastic (Times, Helvetica, or Courier).

I solved this by making sarcasm my default mode.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: A proposal for improving transparency of the FTP NEW process

[W. Martin Borgert]

On 2018-03-03 10:22, Chris Lamb wrote:
> This is, of course, not very obvious or initiutive and improved
> transparency on this would obviously be a beneficial to all parties,
> let alone Debian at large.

Indeed. Sometimes I see interesting packages in NEW, but don't
know why they don't pass. A public place with all relevant
information, maybe comments by FTP team members, dialogue with
maintainer etc. would be helpful for the community in general.

> I solved this by making sarcasm my default mode.

I hope, that this was meant sarcastic. Wait...

Re: A proposal for improving transparency of the FTP NEW process

[Ben Finney]

Lars Wirzenius  writes:

> Admittedly, it is quite a small package, but that's kind-of my point.
> Making it easy for others to do the thing you need them to do is what
> you can do to make things easier for you. Asking them to do more work,
> or to change how they do their thing, is less likely to go well.
>
> The Linux kernel maintainers flat-out reject large patches that dump
> big changes without prior discussion. This is because it's easier for
> them to digest changes in smaller chunks, and they put the
> responsibility for presenting the changes that way on the people
> producing the patches.
>
> For Debian, I think we should have the same approach. […]

Your recounted experience suggests another way (compatible with the ways
you discussed) to reduce the work of reviewing a code base with complex
copyright interactions:

A large code base with complex interacting works of copyright can be
broken into smaller packages, that are each individually easier to
review and pass through NEW; either built as separate source packages,
or combined at build time.

Will that work for every large package? Maybe that's too much to hope
for. But in those cases where the maintainers are frustrated that the
NEW queue processing takes a long time to pass their new package: isn't
it worth the effort to try making it easier to review by breaking the
package into smaller more easily-reviewed chunks?

A maintainer (or a team) who tries that might find it's not so hard; and
having done that, it becomes that much easier to understand not only the
copyright status of each smaller package, but for a newcomer to
understand how to maintain it. This is a benefit not only in getting the
package reviewed through the NEW queue, but also for attracting
additional co-maintainers.

Breaking large complex tangles into smaller manageable pieces is thus,
I'd suggest, an investment in reducing the overall work of Debian
package maintenance.

> There may be other reasons why some packages stay in NEW for a long
> time. Getting information from ftp masters about the reasons why, and
> a discussion of how we can make easier for them to make NEW review
> easier would, I feel, take us forward better than another than us
> complaining that things are taking too long.

Thanks for keeping the options open.

-- 
 \ Contentsofsignaturemaysettleduringshipping. |
  `\   |
_o__)  |
Ben Finney

Bug#891965: ITP: libwww-shorten-5gp-perl -- Shorten URLs using L

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libwww-shorten-5gp-perl
  Version : 1.030
  Upstream Author : Michiel Beijen 
* URL : https://metacpan.org/release/WWW-Shorten-5gp
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Shorten URLs using L

WWW::Shorten::5gp provides a Perl interface to the http://5.gp URL-shortening
web site.

Short URLs are useful when one wants to send a link using a media that
imposes size constraints.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#891970: ITP: char-menu-el -- create your own menu for fast insertion of arbitrary symbols

[Lev Lamberov]

Package: wnpp
Owner: Lev Lamberov 
Severity: wishlist

* Package name: char-menu-el
  Version : 0.1.1
  Upstream Author : Mark Karpov 
* URL or Web page : https://github.com/mrkkrp/char-menu
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : create your own menu for fast insertion of arbitrary symbols

This package allows one to insert arbitrary symbols in Emacs in a very
efficient and straightforward way. Whether you ever need to insert only
a couple of proper punctuation symbols or you're a Unicode geek who
likes all sorts of arrows and fancy math symbols, this package may be of
some use.

Re: A proposal for improving transparency of the FTP NEW process

[Steffen Möller]

On 3/3/18 7:54 AM, Lars Wirzenius wrote:

On Fri, 2018-03-02 at 22:05 -0600, Steve Robbins wrote:

I assume that the reason my packages have been processed is due to one

of two reasons: a) I get quoted on LWN several times a year, so I'm a
celebrity and get special treatment

I expect that's it.

For the avoidance of doubt, especially for onlookers: I was, of
course, being sarcastic with that LWN command, and I think Steve is
continuing by being deadpan sarcastic in response.

I wish text/plain carried font information so I could use a font to
indicate when I'm being sarcastic (Times, Helvetica, or Courier).


But you are a celebrity. Just not the kind of celebrity that gets
free coffee at Starbucks, though. Except for when you fix their Wifi,
I mean. But if I was an ftpadmin and saw a package of yours uploaded,
you'd find me priorising this up ... and if there is not something
more interesting like a new version of bsdgames that one needs to
quality-control ... being a tech-celebrity must be good for something.

And nobody diss sarcasm, please. It is a tremendous helper,
not only to stay mentally afloat but also for brain storming to help
stimulating lateral thinking. It is mainly problematic in broadcast
communication like mailing lists when you do not know with whom
you are working with.


Or possibly you have a more generous notion of "fast".  Currently there are
five or six dozen packages waiting more than 2 months.  That's not fast in my
books.

By "fast" I mean "less than 24 hours". I uploaded vmdb2 (new source
package) about a month ago. The timestamp of the mail saying it's
going into the NEW queue is 16:27. The ACCEPTED mail has a timestamp
of 18:00. That was on February 10.

I had this, too. Just yesterday. Thrice. My fourth package had a problem,
which I kind of knew when it was not going through as quickly.

Admittedly, it is quite a small package, but that's kind-of my point.
Making it easy for others to do the thing you need them to do is what
you can do to make things easier for you. Asking them to do more work,
or to change how they do their thing, is less likely to go well.

The Linux kernel maintainers flat-out reject large patches that dump
big changes without prior discussion. This is because it's easier for
them to digest changes in smaller chunks, and they put the
responsibility for presenting the changes that way on the people
producing the patches.

For Debian, I think we should have the same approach. Not literally
the same approach, of course, since that would mean having the Debian
package maintainer refactor the upstream code into smaller programs,
and that would just be silly.


I disagree here. We think in units. What is released together should not
be split into multiple source packages with Debian. I am still living
through that with my mgltools packages that made everyone unhappy,
also making my communication with upstream more difficult. And the
overall workto review it all is the same.


But the same approach of making it the
uploader's responsibility to present a new package in a way that makes
it easy to review it. This includes making copyright information easy,
and working with upstream to make it clear, possibly by using SPDX
markup for copyrights and licensing. For all of Debian it meants
finding or developing tools for automating extraction of copyright
information into debian/copyright in whatever manner is needed.
We have licencecheck, and if that isn't good enough, we can improve
it.


Ha! And here I agree again. We should somehow improve our infrastructure
to allow for

 * an increase automation, e.g. by something like debian/licencecheck
   to  help customizing the otherwise unknown licenses* replies to the 
ITP with


 * issues to address prior to a reload? issues on salsa?Just a nything that
   renders the ftpadmins' reviewing reentrant.

 * maybe ftpmasters can delegate some work to an individual they trust
   for some particular checks when the source tree is on salsa? We would
   effectively then have temporary volunteer ftpadmin assistants.


There may be other reasons why some packages stay in NEW for a long
time. Getting information from ftp masters about the reasons why, and
a discussion of how we can make easier for them to make NEW review
easier would, I feel, take us forward better than another than us
complaining that things are taking too long.


Yes. I am very happy not to be an ftpadmin and cannot thank our
ftpadminning peers enough for their efforts. Our current infrastructure
is not really set out to be communicative in that process.

Steffen

Bug#891971: ITP: bali-phy -- Bayesian Inference of Alignment and Phylogeny

[Benjamin Redelings]

Package: wnpp
Severity: wishlist
Owner: Benjamin Redelings 

* Package name: bali-phy
  Version : 3.0
  Upstream Author : Benjamin Redelings 
* URL : http://www.bali-phy.org/
* License : (GPL)
  Programming Lang: (C++)
  Description : Bayesian Inference of Alignment and Phylogeny

 BAli-Phy estimates multiple sequence alignments and evolutionary trees
 from unaligned DNA, amino acid, or codon sequences.  BAli-Phy uses MCMC
 to estimate evolutionary trees, positive selection, and branch lengths
 while averaging over alternative alignments. BAli-Phy can display
 alignment ambiguity graphically in an alignment uncertainty (AU) plot.
 .
 BAli-Phy can also estimate phylogenies from a fixed alignment (like MrBayes
 and BEAST) using substitution models like GTR+gamma.  BAli-Phy automatically
 estimates relative rates for each gene.

- Why is this package relevant?

This package performs Bayesian inference of alignment, as well as inference of 
phylogeny like mrbayes, beast-mcmc, beast2-mcmc, etc.  This package produces 
higher quality alignments than programs like fsa, mafft, muscle, at the cost of 
taking much longer to run.

- How do you plan to maintain it?

I hope to maintain it myself.  I am looking for a mentor.

Bug#891984: ITP: pip-requirements-el -- major mode for editing pip requirements files

[Lev Lamberov]

Package: wnpp
Owner: Lev Lamberov 
Severity: wishlist

* Package name: pip-requirements-el
  Version : 0.5
  Upstream Author : Wilfred Hughes 
* URL or Web page : https://github.com/Wilfred/pip-requirements.el
* License : GPL-3+
  Description : major mode for editing pip requirements files

This package provides an Emacs major mode for editing pip
requirements files, with the following features:

 * Syntax highlighting
 * Togglable comments
 * Auto completion of package names from PyPI

FTP Policy Development

[Steve Robbins]

On Friday, March 2, 2018 11:07:39 PM CST Scott Kitterman wrote:
> On Friday, March 02, 2018 09:44:04 PM Steve Robbins wrote:
> > On Thursday, March 1, 2018 6:15:08 AM CST Ian Jackson wrote:
> > > But when a submitter disagrees with a REJECT, and asks for a review,
> > > IMO submitter is entitled to a longer explanation, and there should
> > > explicitly be an opportunity for other ftpmasters to agree or dissent.
> > 
> > That would be nice.  I'm still waiting for clarity about the Boost
> > rejection.
> 
> This is my fault.  I had planned (and still do) on working on getting some
> clarification around the copyright notification issue.  Unfortunately, I've
> gotten distracted by a few other things, but I still plan on working on it.

Well, I don't think it is your fault.  I myself have several times sat down to 
write a follow-up -- with an actual proposal, not just complaining :-) -- but 
also got distracted.  We're all busy.  But I am heartened to hear that you are 
working on it.  And I welcome the recent proposals by Ian and by Gert.

To me, one of the puzzling aspects is why the FTP policy work has been so 
secretive.  The release team has a mailing list, tech committee has a mailing 
list.  There is Debian Policy list.  It doesn't seem in congruence that the 
ftp team is making their policy behind closed doors.  Should it not flow from 
Debian Policy and be debated on open lists?

Or maybe it is all open and I simply haven't found it.  If so, I would 
gratefully accept pointers.  Concretely: where would one find the 
deliberations behind https://ftp-master.debian.org/REJECT-FAQ.html ?

-Steve
P.S.  If I didn't strike the right tone in this email, then I do apologise.  
It is honestly not intended to be antagonistic, though I admit it does sound a 
bit whiny.


signature.asc
Description: This is a digitally signed message part.

Re: A proposal for improving transparency of the FTP NEW process

[Paul Gevers]

Hi,

On 03-03-18 11:57, Ben Finney wrote:
> A large code base with complex interacting works of copyright can be
> broken into smaller packages, that are each individually easier to
> review and pass through NEW; either built as separate source packages,
> or combined at build time.

Except if there is one upstream tar ball. Do you really suggest we
should repack one upstream tar ball into multiple smaller tar balls just
for the review process? In the examples I have in mind (fpc and lazarus)
I wouldn't even know what binary packages to build from the smaller
pieces until they are combined again.

I don't believe this is a great recommendation.

Paul



signature.asc
Description: OpenPGP digital signature

Re: A proposal for improving transparency of the FTP NEW process

[Chris Lamb]

Steffen Möller wrote:

> But you are a celebrity. Just not the kind of celebrity that gets
> free coffee at Starbucks, though. Except for when you fix their Wifi,
> I mean. But if I was an ftpadmin and saw a package of yours uploaded,
> you'd find me priorising this up ...

(Just for clarity, as the ftp-team member who — I think? — accepted
the packages in question, it was nothing to do with "celebrity.")


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: A proposal for improving transparency of the FTP NEW process

[Pierre-Elliott Bécue]

Le samedi 03 mars 2018 à 21:57:42+1100, Ben Finney a écrit :
> Lars Wirzenius  writes:
> 
> > Admittedly, it is quite a small package, but that's kind-of my point.
> > Making it easy for others to do the thing you need them to do is what
> > you can do to make things easier for you. Asking them to do more work,
> > or to change how they do their thing, is less likely to go well.
> >
> > The Linux kernel maintainers flat-out reject large patches that dump
> > big changes without prior discussion. This is because it's easier for
> > them to digest changes in smaller chunks, and they put the
> > responsibility for presenting the changes that way on the people
> > producing the patches.
> >
> > For Debian, I think we should have the same approach. […]
> 
> Your recounted experience suggests another way (compatible with the ways
> you discussed) to reduce the work of reviewing a code base with complex
> copyright interactions:
> 
> A large code base with complex interacting works of copyright can be
> broken into smaller packages, that are each individually easier to
> review and pass through NEW; either built as separate source packages,
> or combined at build time.
> 
> Will that work for every large package? Maybe that's too much to hope
> for. But in those cases where the maintainers are frustrated that the
> NEW queue processing takes a long time to pass their new package: isn't
> it worth the effort to try making it easier to review by breaking the
> package into smaller more easily-reviewed chunks?
> 
> A maintainer (or a team) who tries that might find it's not so hard; and
> having done that, it becomes that much easier to understand not only the
> copyright status of each smaller package, but for a newcomer to
> understand how to maintain it. This is a benefit not only in getting the
> package reviewed through the NEW queue, but also for attracting
> additional co-maintainers.
> 
> Breaking large complex tangles into smaller manageable pieces is thus,
> I'd suggest, an investment in reducing the overall work of Debian
> package maintenance.

God.

I can't imagine what kind of hell it'd actually be to split up some thing as
vtk into smaller packages without massive redesign upstream.

I'm actually pretty sure I'd not like being part of it.

Cheers,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.

Re: A proposal for improving transparency of the FTP NEW process

[Ben Finney]

Paul Gevers  writes:

> Hi,
>
> On 03-03-18 11:57, Ben Finney wrote:
> > A large code base with complex interacting works of copyright can be
> > broken into smaller packages, that are each individually easier to
> > review and pass through NEW; either built as separate source
> > packages, or combined at build time.
>
> Except if there is one upstream tar ball. Do you really suggest we
> should repack one upstream tar ball into multiple smaller tar balls
> just for the review process?

To say “should” is rather too strong. I'm presenting it as one option to
try, for those who are frustrated at the slow review process for a large,
complex source package with complex copyright interactions: Break it
into more easily-reviewed pieces.

The review process is an acknowledged bottleneck for NEW queue
processing, and we've seen stated that large, complex source packages
are especially difficult to get through.

I'm proposing that the same code base as a set of smaller source
packages will get through that bottleneck easier; I don't say that as a
recommendation nor a “should”, but as an option to try, for those of us
who not FTPmaster and are looking for ways to work better with the
process.

-- 
 \   “Whenever you read a good book, it's like the author is right |
  `\   there, in the room talking to you, which is why I don't like to |
_o__)   read good books.” —Jack Handey |
Ben Finney

Re: PGP Clean Room GSoC Co-Mentoring

[Jacob Adams]

On 02/28/2018 06:18 PM, Ulrike Uhlig wrote:
> Hi!
> 
> Jacob Adams:
> 
>> I am looking to create an application for the PGP Clean Room Live CD
>> that walks a user through setting up a set of USB flash drives or sd
>> cards as a raid disk, generating new GPG keys, storing them there, and
>> then exporting subkeys either on a separate USB stick or a PGP smartcard
>> like a Yubikey. I'd also like to add the ability to do things like
>> revoke keys or extend expiration dates for them through the application.
>> You can see more of the ideas behind the project here:
>> https://wiki.debian.org/SummerOfCode2018/Projects/CleanRoomForPGPKeyManagement
> 
> Sounds cool. But why would this application run only on this particular
> Live CD and not any Debian-based OS?

There's no reason why it couldn't run on any other Debian-based OS or
Live CD. Much of the usefulness, however, does come from the live cd
environment and the control that gives us over the end-users system.

> You mentioned Tails as being too
> heavy to implement this there and ask people to download and run Tails -
> understood. However, if your application were available as a Debian
> package, Tails / Debian_unlive / Ubuntu users could also benefit from
> it. And people would not have to download an entire Live System but
> could simply do that in Tails :)

On TAILS this could be quite useful. I will look into packaging the
program after GSoC if everything works out. Have to actually write it
first of course :)
> 
> Anyhow, this is a comment which does not help you search for a mentor,
> sorry about that & good luck!
> 
> Cheers,
> Ulrike
> 





signature.asc
Description: OpenPGP digital signature

Bug#892007: ITP: libxpp -- A C++11 RAII wrapper for XCB

[Jason Pleau]

Package: wnpp
Severity: wishlist
Owner: Jason Pleau 

* Package name: libxpp
  Version : 1.4.0
  Upstream Author : Jochen Keil 
* URL : https://github.com/jaagr/xpp
* License : MIT
  Programming Lang: C++, Python
  Description : A C++11 RAII wrapper for XCB

XPP is a header only C++11 RAII wrapper around X protocol C-language Binding
(XCB).

Since there is another package named "xpp" in Debian, I am going to use
"libxpp" as the source package name.

Note that I am packaging a fork of xpp. The original repository hasn't been
updated in 4 years, the features that polybar requires were added in the fork.

This package is a dependency of polybar (ITP #856179)

Bug#892008: ITP: i3ipcpp -- C++ interface to i3-ipc

[Jason Pleau]

Package: wnpp
Severity: wishlist
Owner: Jason Pleau 

* Package name: i3ipcpp
  Version : 0.7.1
  Upstream Author : Sergey Naumov 
* URL : https://github.com/jaagr/i3ipcpp
* License : MIT
  Programming Lang: C++
  Description : C++ interface to i3-ipc

Window manager i3-wm ships with an IPC interface (interprocess communication),
accessible through a CLI utility named "i3-ipc".

i3ipcpp provides a way to use this IPC interface through C++ code.

This package is a dependency of polybar (ITP #856179)

Bug#892011: ITP: golang-github-git-lfs-wildmatch -- Wildmatch is a pattern matching language for filepaths compatible with Git.

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-git-lfs-wildmatch
  Version : 0.0~git20180219.8a05186-1
  Upstream Author : GitHub
* URL : https://github.com/git-lfs/wildmatch
* License : Expat
  Programming Lang: Go
  Description : Wildmatch is a pattern matching language for filepaths 
compatible with Git.

 wildmatch package wildmatch is a reimplementation of Git's
 wildmatch.c-style filepath pattern matching.
 .
 For more information, see the godoc
 (https://godoc.org/github.com/git-lfs/wildmatch).

This is a dependency for git-lfs and will be maintained in the go packaging
team.

Bug#892017: ITP: r-cran-webutils -- GNU R utility functions for developing web applications

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-webutils
  Version : 0.6
  Upstream Author : Jeroen Ooms 
* URL : https://cran.r-project.org/package=webutils
* License : MIT
  Programming Lang: GNU R
  Description : GNU R utility functions for developing web applications
 High performance in-memory http request parser for application/json,
 multipart/form-data, and application/x-www-form-urlencoded. Includes live demo
 of hosting and parsing multipart forms with either 'httpuv' or 'Rhttpd'.


Remark: This package is needed to run the full test suite of r-cran-curl as
 reported in bug #891943.  It will be maintained by the Debian R team at
https://salsa.debian.org/r-pkg-team/r-cran-webutils.git