On Sat, Jan 6, 2018 at 6:30 PM, Julien Cristau <[email protected]> wrote:
> [moving this off the (now archived) bug] > Thanks for the pointer! > > On Sat, Jan 6, 2018 at 18:00:48 +0100, Michael Stapelberg wrote: > > > On Sat, Dec 2, 2017 at 8:20 PM, Julien Cristau <[email protected]> > wrote: > > > > > On Sat, Jul 29, 2017 at 12:25:03 +0200, Michael Stapelberg wrote: > > > > > > > This is the first binNMU I schedule, mostly to see how this all works > > > before I > > > > file a larger one. > > > > > > > Clearly not very well. > > > > > > > What’s the appropriate discussion channel for raising this issue? In > > particular, I’d like to start a discussion about teams (e.g. pkg-go) > being > > able to independently (i.e. without the delay imposed by the current > > process) schedule binNMUs for their packages. > > > Probably debian-release (who currently own binNMU scheduling) and > debian-wb-team (as a proxy for wbadm, who own wanna-build). > > The permission wouldn't be granted to pkg-go as such, it would be > granted to (an) individual(s). There's precedent in pkg-haskell and > pkg-ocaml who have people handling binNMUs for their packages. There's > Okay. How many individuals can we list, and what’s the process for getting the permission? > also implications on visibility of unreleased security updates, so the > set of people with access needs to stay limited. Just to confirm: is this a side-effect of getting the permission? Being able to schedule binNMUs doesn’t sound related to security updates to me :) -- Best regards, Michael
