Re: DEP-5 (copyright file format) ... gap with practice
On Wed, Sep 10, 2014 at 12:27:58AM -0400, David Prévot wrote: On the other hand, it defeats the principle of least surprise. Distributing a different upstream tarball in Debian than upstream, just because, seems plain wrong. Even the dev-ref agrees: “You *should* upload packages with a pristine source tarball if possible”. But how do you feel about the slightly different situation of shipping a pristine tarball but not performing an autoreconf (etc etc) prior to ./configure -- thus deviating from the normal process of building that package from source? At least it's very clear how an autoconf-output-stripped tarball is going to be built. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918062638.GB27586@debian
Re: DEP-5 (copyright file format) ... gap with practice
On Mon, Sep 15, 2014 at 04:51:19PM +0200, Andreas Tille wrote: Just for the sake of interest: Is there any reason not to use uscan? (I hope the answer will not be since I need to remove files from upstream source.) This wouldn't help those not using uscan, of which I am one, but what about extending uscan to have a list of autoconf-like files that it automatically excludes by default (override-able of course), saving people from listing the exact same files in Files-Excluded: for every autotools-using package? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918062833.GA29551@debian
Debian Maintainers Keyring changes
The following changes to the debian-maintainers keyring have just been activated: b...@bc-bd.org Full name: Stefan Völkel Added key: 5691873AA9B1C18E3CEE82E60F8CE0BF4E85E61B b...@benfinney.id.au Removed key: 9CFE12B0791A4267887F520CB7AC2E51BD41714B Added key: 517CF14BB2F398B0CB354855B8B24C06AC128405 c...@kvr.at Full name: Christian Kastner ste...@bc-bd.org Removed key: 3C0B6EB0AB2729E8CE2255A7385AE490868EFA66 yauheni.kali...@nokia.com Removed key: B86CB5487CC4B58F0CA3856E7EE852DEE6B78725 yauh...@kaliuta.org Full name: Yauheni Kaliuta Added key: FBF3EEAFA7807802B56B27A970A8FEE074B3ED3A Debian distribution maintenance software, on behalf of the Keyring maintainers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xucmh-00053q...@franck.debian.org
Re: CoC / procedural abuse
On Thu, 18 Sep 2014, Jonathan Dowland wrote: However it does presume some statute of limitation on ban length. Don's message earlier in this thread does not indicate any particular ban length in this particular case. It's not clear to me whether this is an indefinite ban, or one subject to review, and in the latter case, whether the ban period is deliberately non-disclosed (and I can see the reasoning for that too, if that's the case, but I don't know that it is). I personally don't have a problem removing bans once someone indicates that they understand why the ban was put in place, and that they are going to avoid that behavior in the future. I generally don't place specific time limits, because I don't believe in punitive action... and also because I'm lazy, and I don't want to promise that I will remember to remove a ban at a specific time without being prompted. The whole purpose of bans and warnings is to stop unwelcome behavior on Debian infrastructure. -- Don Armstrong http://www.donarmstrong.com The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila -- Mitch Ratcliffe -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918191355.gk8...@teltox.donarmstrong.com
Re: CoC / procedural abuse
On Thu, Sep 18, 2014 at 12:13:55PM -0700, Don Armstrong wrote: I generally don't place specific time limits, because I don't believe in punitive action... M, I'd consider a ban without length limitation is way more punitive than, say, an x-weeks ban, both being more severe than a warning. The escalation (warning, temporary ban, perma-ban) is what I am used to in most forums/irc channels (and it works quite well). Would you consider this sensible approach for Debian MLs? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918193447.ga6...@x60s.casa
Re: CoC / procedural abuse
On Thu, Sep 18, 2014 at 09:34:47PM +0200, Francesco Ariis wrote: On Thu, Sep 18, 2014 at 12:13:55PM -0700, Don Armstrong wrote: I generally don't place specific time limits, because I don't believe in punitive action... M, I'd consider a ban without length limitation is way more punitive than, say, an x-weeks ban, both being more severe than a warning. The escalation (warning, temporary ban, perma-ban) is what I am used to in most forums/irc channels (and it works quite well). Would you consider this sensible approach for Debian MLs? s/sensible/a sensible -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918193923.ga6...@x60s.casa
Re: CoC / procedural abuse
On Thu, 18 Sep 2014, Francesco Ariis wrote: On Thu, Sep 18, 2014 at 12:13:55PM -0700, Don Armstrong wrote: I generally don't place specific time limits, because I don't believe in punitive action... I'd consider a ban without length limitation is way more punitive than, say, an x-weeks ban, both being more severe than a warning. The escalation (warning, temporary ban, perma-ban) is what I am used to in most forums/irc channels (and it works quite well). If I understand correctly, you're interpreting my lack of specific time limits as placing a permanent ban, which isn't what I mean. By not having time limits, there's no lower bound. The upper bound is when someone contacts listmaster@ and convinces a listmaster that they'll do better, and a listmaster agrees and removes the ban. The time to the upper bound is entirely dependent on the individual in question and their desire to be a contribution to Debian. Would you consider this sensible approach for Debian MLs? This is basically already what we do, but we sometimes jump straight to a ban if the behavior is problematic enough without mitigating factors. -- Don Armstrong http://www.donarmstrong.com For those who understand, no explanation is necessary. For those who do not, none is possible. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918203349.gq8...@teltox.donarmstrong.com
Re: DEP-5 (copyright file format) ... gap with practice
Hi, Le 18/09/2014 02:28, Jonathan Dowland a écrit : what about extending uscan to have a list of autoconf-like files that it automatically excludes by default (override-able of course), saving people from listing the exact same files in Files-Excluded: for every autotools-using package? Why do you believe repacking upstream tarball should be the default behavior (especially when, as already pointed before, “You *should* upload packages with a pristine source tarball if possible”)? Having uscan making it easier to repack upstream tarball when it is *actually* sensible shouldn’t be a good excuse to repack every upstream tarball by default just because it’s easy… Regards David signature.asc Description: OpenPGP digital signature
Re: CoC / procedural abuse
On Thu, 18 Sep 2014, Don Armstrong wrote: limits as placing a permanent ban, which isn't what I mean. By not But what it is. It is a permanent ban that *might* be lifted by listmasters' graciousness. So perpetrators have to beg for redemption. Hail to the King, we are back to what I always claimed, oligarchy. I consider moving our maintainers' lists to a different provider if this is the way Debian works nowadays. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918220915.gk8...@auth.logic.tuwien.ac.at
Re: CoC / procedural abuse
Le Fri, Sep 19, 2014 at 07:09:15AM +0900, Norbert Preining a écrit : On Thu, 18 Sep 2014, Don Armstrong wrote: limits as placing a permanent ban, which isn't what I mean. By not But what it is. It is a permanent ban that *might* be lifted by listmasters' graciousness. So perpetrators have to beg for redemption. I guess that the story is simpler than this: time-limited bans do not seem to be supported natively in Debian's mailing list engine (SmartList), so if one wants to see our listmasters use time-limited bans more often, then somebody has to spend time to implement this function. This is the reason I refrained to suggest it before despite I also think that time-limited bans are better: I am totally unlikely to write this piece of code. This said, I think that time-limited bans would be a progress, since they would make it easier to cool down non-constructive discussions where people are heating up and start to send dozens of emails as failed attempts to release their anger by ranting in others ears. Also, the concept of lifting bans only on demand creates a black list as a byproduct, and it is strange to imagine such a list in 10 years containing random people who happened to have misbehaved some time ago, of whom we had no news since, but whose names we remember forever. I think that forgetting would make things easier for everybody after a while. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918235212.ga12...@falafel.plessy.net
Re: DEP-5 (copyright file format) ... gap with practice
On Thu, Sep 18, 2014 at 2:26 PM, Jonathan Dowlandwrote: But how do you feel about the slightly different situation of shipping a pristine tarball but not performing an autoreconf (etc etc) prior to ./configure -- thus deviating from the normal process of building that package from source? At least it's very clear how an autoconf-output-stripped tarball is going to be built. We should be moving towards this: Pristine upstream tarballs. Build tools automatically removing generated files (including autotools files) and unmodified embedded code copies (including autotools related files, m4 macros etc). -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6ebnstktznzzynwtsmrwa2roaqffya2nk9dezcysd8...@mail.gmail.com
