Bug#835658: RFS: backbone/1.3.3+ds-1
control: owner -1 ! control: tags -1 moreinfo (ccing people who expressed interest in this update) > I am looking for a sponsor for the package "backbone" here we are, but I have some questions/issues: 1) why did you drop so much build-dependencies? 2) missing copyrights/licenses: * @license RequireJS 2.1.9 Copyright (c) 2010-2012, The Dojo Foundation All Rights Reserved. * Available via the MIT or new BSD license. (c) 2009-2015 Jeremy Ashkenas, DocumentCloud and Investigative Reporters & Editors and maybe more 3) Did you get in touch with the maintainer for this upload? 4) please tag the two bugs as pending, to avoid double work from other people (e.g. zigo who expressed) 5) I'm not sure Jonas will like to move away from cdbs... 6) -Author: Jonas Smedegaard +Author: Julien Puydt I would use both people as authors :) 7) depends/buil-depends. typo 8) Bump standards-version. To which version? 9) "This source package uses CDBS" I would change that :) 10) why is this a ds repack? it seems to be not written in README.source or whatever 11) compat level is still 8 :) we should be mostly complete as a preliminary review. I have to admit, the cdbs rules file was a little bit complicate for a 3 installed js files library :) but I think we might go for experimental, wait some more testing for the two+ people needing it and then go for unstable. Does it sounds good as a plan
Bug#835659: marked as done (RFS: lua-torch-image/0~20160730-g797fcb1-1 [ITP])
Your message dated Sun, 28 Aug 2016 08:14:15 + (UTC) with message-id <1072774600.1379052.1472372055...@mail.yahoo.com> and subject line Re: Bug#835659: RFS: lua-torch-image/0~20160730-g797fcb1-1 [ITP] has caused the Debian Bug report #835659, regarding RFS: lua-torch-image/0~20160730-g797fcb1-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 835659: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835659 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-image/0~20160730-g797fcb1-1/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-image" * Package name: lua-torch-image Version : 0~20160730-g797fcb1-1 Upstream Author : torch developers * URL : github.com/torch/image * License : bsd-3-clause Section : interpreters It builds those binary packages: lua-torch-image - Image Load/Save Library for Torch Framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-image Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-image/lua-torch-image_0~20160730-g797fcb1-1.dsc Changes since the last upload: lua-torch-image (0~20160730-g797fcb1-1) experimental; urgency=low * Initial release. Closes: #827434 -- Best, Lumin --- End Message --- --- Begin Message --- Hi, > I am looking for a sponsor for my package "lua-torch-image" why do you build depend on libjpeg62-turbo-dev? isn't libjpeg-dev a better replacement? I changed that and I'll sponsor in deferred/2. BTW it fails the testsuite on i386 :) G.--- End Message ---
Bug#835660: marked as done (RFS: meta-torch-core-free/1~exp1 [ITP] -- Torch core&free stack basically ready)
Your message dated Sun, 28 Aug 2016 08:31:17 + (UTC) with message-id <1172248923.1383211.1472373077...@mail.yahoo.com> and subject line Re: Bug#835660: RFS: meta-torch-core-free/1~exp1 [ITP] -- Torch core&free stack basically ready has caused the Debian Bug report #835660, regarding RFS: meta-torch-core-free/1~exp1 [ITP] -- Torch core&free stack basically ready to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 835660: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835660 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-scie...@lists.debian.org Note: Please make this upload deferred, since some dependencies are still in the queue. Clarification on the source name: This package is not named "meta-torch-core" because some of torch core components which require CUDA are not yet ready, and cannot be contained in a metapackage in main section. I will make "src:meta-torch-core-contrib" to include those rest contrib components. Debomatic: It will FTBFS untill new:lua-torch-trepl and the lua-torch-image RFS are cleared. Dear mentors, I am looking for a sponsor for my package "meta-torch-core-free" * Package name: meta-torch-core-free Version : 1~exp1 Upstream Author : myself * URL : none * License : bsd-3-clause Section : science It builds those binary packages: torch-core-free - Scientific Computing Framework For Luajit (Core Components) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/meta-torch-core-free Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/meta-torch-core-free/meta-torch-core-free_1~exp1.dsc Changes since the last upload: meta-torch-core-free (1~exp1) experimental; urgency=low * Initial release. (Closes: #794634) -- Best, Lumin --- End Message --- --- Begin Message --- Hi, >Please make this upload deferred, since some dependencies >are still in the queue. directly sponsored, it is fine to have the dependencies all in the new queue together G.--- End Message ---
Bug#835551: marked as done (RFS: btrfs-progs/4.7.1-1~bpo8+1)
Your message dated Sun, 28 Aug 2016 08:47:06 + (UTC) with message-id <476135040.1416976.1472374027...@mail.yahoo.com> and subject line Re: Bug#835551: RFS: btrfs-progs/4.7-1~bpo8+1 has caused the Debian Bug report #835551, regarding RFS: btrfs-progs/4.7.1-1~bpo8+1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 835551: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835551 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my updated backport of "btrfs-progs" Package name: btrfs-progs Version : 4.7-1~bpo8+1 It builds these binary packages: btrfs-progs - Checksumming Copy on Write Filesystem utilities btrfs-progs-dbg - Checksumming Copy on Write Filesystem utilities (debug) btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) (udeb) btrfs-tools - transitional dummy package btrfs-tools-dbg - transitional dummy package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/btrfs-progs Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.7-1~bpo8+1.dsc Changes since the last upload: btrfs-progs (4.7-1~bpo8+1) jessie-backports; urgency=medium * Rebuild for jessie-backports. -- Nicholas D Steeves Fri, 26 Aug 2016 19:19:01 -0400 btrfs-progs (4.7-1) unstable; urgency=medium * New upstream release. -- Dimitri John Ledkov Thu, 11 Aug 2016 12:52:07 +0100 btrfs-progs (4.6.1-1~bpo8+1) jessie-backports; urgency=medium * Rebuild for jessie-backports. -- Nicholas D Steeves Tue, 26 Jul 2016 16:58:05 -0400 Regards, Nicholas signature.asc Description: Digital signature --- End Message --- --- Begin Message --- Hi >I also just uploaded 4.7.1 to Debian mentors. thanks >Will the deferred queue automatically drop the proposed 4.7.1 bpo in case a >major regression prevents the sid package from migrating to testing? From >what I've >read on the upstream list, the currently known regressions are the >fault of linux-4.6.x rather than btrfs-progs. I really hope I can find the >time to learn formal >Debian kernel packaging and package linux-4.4.x on >github...but that's off-topic! no, it won't prevent the drop, this is something I have to remember to check in today+4days (I usually sponsor one day after the testing migration, because of this reason) (I did the upload in deferred/6, I would appreciate you to ping me when the current one migrates, and I'll reschedule it) >On a more closely related note, I've now met with two DDs in Montréal (Antoine >Baupré and Alexandre Viau), and we've signed each other's keys. Do you think >I'm >ready to proceed with an DM application for backports of btrfs-progs? If >so, would you advocate for me? If not, what do I need to work on? this is something difficult unfortunately :( the reason is that I can't give you DM permissions for backports-only, and the maintainer rejected your comaintaining efforts, so it will be a little bit unfair to give you DM, because you might upload stuff on unstable without permission (not by purpose, but errors happens :) ) so, if you want to maintain some other packages/adopt packages/QA upload packages/NMU, I'll be happy to advocate you as soon as I see your skills outside the particular btrfs-progs package (I'm not sure I sponsored something else to you) so, not a technical issue I would say, but more a political one :) (or both) You already maintain mcelog, did you get in touch with your sponsor to apply for DM? usually what I request is: - some work/refactoring on orphaned packages (you should adopt some packages to gain DM for them or - ITP for new packages (looking at RFP is also fine) two/three uploads where I don't have to nitpick/change stuff get DM for that particular package :) but in all the above cases, being the maintainer/uploader is something I request G.--- End Message ---
Bug#835671: RFS: node-inline-source-map/0.6.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "node-inline-source-map" * Package name: node-inline-source-map Version : 0.6.1-1 Upstream Author : Thorsten Lorenz (http://thlorenz.com) * URL : https://github.com/thlorenz/inline-source-map * License : Expat Section : web It builds this binary package: node-inline-source-map - base64 encoded source mappings for a generated file To access further information about this package, please visit the following URL: https://mentors.debian.net/package/node-inline-source-map Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/node-inline-source-map /node-inline-source-map_0.6.1-1.dsc Packaging can be obtained from: https://anonscm.debian.org/cgit/pkg-javascript/node-inline-source-map.git Changes since the last upload: * Initial release (Closes: #795114) Regards, Ross Gammon -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-24-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#835671: marked as done (RFS: node-inline-source-map/0.6.1-1 [ITP])
Your message dated Sun, 28 Aug 2016 10:31:25 + (UTC) with message-id <316613987.1426073.1472380285...@mail.yahoo.com> and subject line Re: Bug#835671: RFS: node-inline-source-map/0.6.1-1 [ITP] has caused the Debian Bug report #835671, regarding RFS: node-inline-source-map/0.6.1-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 835671: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835671 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "node-inline-source-map" * Package name: node-inline-source-map Version : 0.6.1-1 Upstream Author : Thorsten Lorenz (http://thlorenz.com) * URL : https://github.com/thlorenz/inline-source-map * License : Expat Section : web It builds this binary package: node-inline-source-map - base64 encoded source mappings for a generated file To access further information about this package, please visit the following URL: https://mentors.debian.net/package/node-inline-source-map Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/node-inline-source-map /node-inline-source-map_0.6.1-1.dsc Packaging can be obtained from: https://anonscm.debian.org/cgit/pkg-javascript/node-inline-source-map.git Changes since the last upload: * Initial release (Closes: #795114) Regards, Ross Gammon -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-24-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Hi, >I am looking for a sponsor for my package "node-inline-source-map" done, welcome back on the RFS world :) G.--- End Message ---
Bug#835658: RFS: backbone/1.3.3+ds-1
Hi, On 28/08/2016 10:00, Gianfranco Costamagna wrote: control: owner -1 ! control: tags -1 moreinfo (ccing people who expressed interest in this update) I am looking for a sponsor for the package "backbone" here we are, but I have some questions/issues: 1) why did you drop so much build-dependencies? I don't know why there was that much - pbuilder is happy with what I put. 2) missing copyrights/licenses: * @license RequireJS 2.1.9 Copyright (c) 2010-2012, The Dojo Foundation All Rights Reserved. * Available via the MIT or new BSD license. (c) 2009-2015 Jeremy Ashkenas, DocumentCloud and Investigative Reporters & Editors and maybe more I don't have the time to look into that just now. 3) Did you get in touch with the maintainer for this upload? Contrary to what I usually do, no : I saw two "please package new upstream" bugs, both old (may 2014 and september 2015), none closed as a duplicate of the other -- so I considered the "getting in touch" step was done and pushed forward with the "team maintenance" step. 4) please tag the two bugs as pending, to avoid double work from other people (e.g. zigo who expressed) Done. 5) I'm not sure Jonas will like to move away from cdbs... That was the first time I met a cdbs package... isn't it deprecated? 6) -Author: Jonas Smedegaard +Author: Julien Puydt I would use both people as authors :) Ah, that is because I rewrote the patch by hand (didn't apply... perhaps just because they changed the order of the lines), then added mly usual header. Added back. 7) depends/buil-depends. typo Fixed. 8) Bump standards-version. To which version? Added. 9) "This source package uses CDBS" I would change that :) git rm README.source... but I seem to have forgotten a git commit -m somewhere so it doesn't appear in history... drat. 10) why is this a ds repack? it seems to be not written in README.source or whatever Well, that is documented in debian/copyright, as usual: Files-Excluded: *-min.js and it's automatic, with debian/watch having the repacksuffix=+ds options. 11) compat level is still 8 :) Fixed. we should be mostly complete as a preliminary review. I have to admit, the cdbs rules file was a little bit complicate for a 3 installed js files library :) I admit I didn't even try to understand what it did : just saw how big it was, removed the file and started from scratch. but I think we might go for experimental, wait some more testing for the two+ people needing it and then go for unstable. Done. Does it sounds good as a plan Yes. I'll have to find the time to take care of d/copyright. Thanks, Snark on #debian-js
Bug#835658: RFS: backbone/1.3.3+ds-1
Quoting Julien Puydt (2016-08-28 14:35:32) > On 28/08/2016 10:00, Gianfranco Costamagna wrote: >>> I am looking for a sponsor for the package "backbone" Do you intend to help maintain the package collaboratively, or take over maintenance? If the former, then you should coordinate your work with current maintainers (fine that you seek help and guidance from others too, but don't go ahead with only input from external parties). If the latter, then be cautious that you either have consent from current maintainers to do so, or ensure that you are following the procedures in Debian for takeover (search list archives for "hijacking" for more info). >> 3) Did you get in touch with the maintainer for this upload? > > Contrary to what I usually do, no : I saw two "please package new > upstream" bugs, both old (may 2014 and september 2015), none closed as > a duplicate of the other -- so I considered the "getting in touch" > step was done and pushed forward with the "team maintenance" step. Bugs requesting new upstream releases are wishlist bugs, and they are targeted the maintainer of the package. Wishlist bugs being old is not a good reason to bypass the maintainer. Each team collaborate differntly - don't assume it is ok to change a package without coordinating with current maintainers (i.e. those listed as "Uploaders" for team-maintained packages). > > 5) I'm not sure Jonas will like to move away from cdbs... > > That was the first time I met a cdbs package... isn't it deprecated? No. Never was. Some people disliking CDBS wants everyone to believe that's the case. > > 9) > > > > "This source package uses CDBS" > > I would change that :) > > git rm README.source... but I seem to have forgotten a git commit -m > somewhere so it doesn't appear in history... drat. Please consult current maintainers of a package before making large changes, like restructuring to a different core packaging helper tool. > > we should be mostly complete as a preliminary review. I have to > > admit, the cdbs rules file was a little bit complicate for a 3 > > installed js files library :) > > I admit I didn't even try to understand what it did : just saw how big > it was, removed the file and started from scratch. Please consult current maintainers of a package before making large changes, like "starting from scratch". - 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#835658: RFS: backbone/1.3.3+ds-1
Hi, On 28/08/2016 15:43, Jonas Smedegaard wrote: Quoting Julien Puydt (2016-08-28 14:35:32) On 28/08/2016 10:00, Gianfranco Costamagna wrote: I am looking for a sponsor for the package "backbone" Do you intend to help maintain the package collaboratively, or take over maintenance? Collaboratively. If the former, then you should coordinate your work with current maintainers (fine that you seek help and guidance from others too, but don't go ahead with only input from external parties). Ok. If the latter, then be cautious that you either have consent from current maintainers to do so, or ensure that you are following the procedures in Debian for takeover (search list archives for "hijacking" for more info). See above : team maintenance. 3) Did you get in touch with the maintainer for this upload? Contrary to what I usually do, no : I saw two "please package new upstream" bugs, both old (may 2014 and september 2015), none closed as a duplicate of the other -- so I considered the "getting in touch" step was done and pushed forward with the "team maintenance" step. Bugs requesting new upstream releases are wishlist bugs, and they are targeted the maintainer of the package. > Wishlist bugs being old is not a good reason to bypass the maintainer. Each team collaborate differntly - don't assume it is ok to change a package without coordinating with current maintainers (i.e. those listed as "Uploaders" for team-maintained packages). Ok. 5) I'm not sure Jonas will like to move away from cdbs... That was the first time I met a cdbs package... isn't it deprecated? No. Never was. Some people disliking CDBS wants everyone to believe that's the case. I didn't dislike it since I thought it was deprecated. But I have to admit seeing what d/rules looked like for that simple a package doesn't make me want to learn more about it. 9) "This source package uses CDBS" I would change that :) git rm README.source... but I seem to have forgotten a git commit -m somewhere so it doesn't appear in history... drat. Please consult current maintainers of a package before making large changes, like restructuring to a different core packaging helper tool. Ok. we should be mostly complete as a preliminary review. I have to admit, the cdbs rules file was a little bit complicate for a 3 installed js files library :) I admit I didn't even try to understand what it did : just saw how big it was, removed the file and started from scratch. Please consult current maintainers of a package before making large changes, like "starting from scratch". Ok. Jonas, do you want me to revert all my changes on backbone? Do you intend to do something about backbone? I notice that you're also (co-)maintainer for underscore, which is also on my way to jupyter in Debian. For that one there is an important bug which looks pretty trivial and a wishlist bug which is a one-liner to d/control [and it lacks a wishlist for a newer version]. What are your plans for underscore too? Sorry for the inconvenience, Snark on #debian-js
Bug#835658: RFS: backbone/1.3.3+ds-1
Hi Jonas! >Do you intend to help maintain the package collaboratively, or take over >maintenance? I see a team upload, so I guess the former of course >If the former, then you should coordinate your work with current >maintainers (fine that you seek help and guidance from others too, but >don't go ahead with only input from external parties). this is something that a good sponsor has to check, and the reason for me putting *you* in cc :) I hope the workflow was good enough for you, we didn't upload anything and we are here to reach a common view, that might be beneficial from people needing the new release (I personally sponsored ~10 packages for the new ipython, and this one seems needing an update too) >If the latter, then be cautious that you either have consent from >current maintainers to do so, or ensure that you are following the >procedures in Debian for takeover (search list archives for "hijacking" >for more info). never been the case here, but nice to put it clear, hijacking is *never* something good, except for MIA maintainers. Since you put the package under team maintenance, I guess a Team Upload is something we can handle, right? (of course, I wanted you to be eplicitly aware of this RFS, in my cc and the main goal is to agree on something all together) >Bugs requesting new upstream releases are wishlist bugs, and they are >targeted the maintainer of the package. > >Wishlist bugs being old is not a good reason to bypass the maintainer. not this case, of course :) He did the work, but "bypassing" the maintainer needs somebody to upload it :) in case you want to upload by yourself, you might find some work already done, and cherry-pick it ;) >Each team collaborate differntly - don't assume it is ok to change a >package without coordinating with current maintainers (i.e. those listed >as "Uploaders" for team-maintained packages). not sure if you mean the archive or the packaging repo... but yeah, probably I would have done a git push on an external branch/repo and pushed only after the current upload. You are right, every team has a different workflow, and remembering all of them and all of the different maintainers is something difficult... But with git it is trivial to revert/cherry-pick/branch/delete stuff :) >> That was the first time I met a cdbs package... isn't it deprecated? > >No. Never was. > >Some people disliking CDBS wants everyone to believe that's the case. I personally don't like CDBS, but I never had a war against it. I don't like because probably I had a first approach without it, but I have NMUed packages with it, and as I said, I preferred to be explicit about that point. CDBS is used, probably not the first one by popcon, but it has reasons to be there, and a Team Upload should probably respect that. (BTW, it seems true that for a package that needs a bunch of files copied over two directories, a ~100 lines rules file seems a little bit complicated to read, do we really need all of this file? (I'm interested in this part, I might find that CDBS has some nice features and make me switch or partially switch to it) >Please consult current maintainers of a package before making large >changes, like restructuring to a different core packaging helper tool. this is true, but we cal always revert if it isn't ok for you I hope >Please consult current maintainers of a package before making large >changes, like "starting from scratch". true, but at the end, would you consider sponsoring an updated package or not? ok the change back to cdbs, ok the testing, but what are the points you would like to see addressed (if eventually you want somebody else sponsoring this one) thanks for the quick reply, I know you are busy, and this is appreciated (actually I remember me taking over of a package or two, some years ago, they were RC-buggy and you gave them to me so nicely, I hope we will "fix" the current situation in the same way, to help reverse-dependencies move forward) thanks, G.
Bug#835658: RFS: backbone/1.3.3+ds-1
Quoting Julien Puydt (2016-08-28 16:12:33) > On 28/08/2016 15:43, Jonas Smedegaard wrote: >> Quoting Julien Puydt (2016-08-28 14:35:32) >>> On 28/08/2016 10:00, Gianfranco Costamagna wrote: > I am looking for a sponsor for the package "backbone" >> >> Do you intend to help maintain the package collaboratively, or take >> over maintenance? > > Collaboratively. Great! ...but perhaps we have different understandings of that term, then: It seems you prepared a new package release with radical structural changes, and requested sponsorship for uploading it. First I hear of all that is today, after the fact. Did I miss some prior communication somehow? If not, then please elaborate a bit on the kind of collaboration you want. [holding back on answering the rest of the mail until above is more clear] - 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#835658: RFS: backbone/1.3.3+ds-1
Quoting Gianfranco Costamagna (2016-08-28 17:59:41) >>Do you intend to help maintain the package collaboratively, or take >>over maintenance? > I see a team upload, so I guess the former of course Don't take for granted that what you find obvious is equally obvious to others. Especially when raised as an explicit question: Makes you seem like taking me for a fool (which I am sure was not intended). >> If the former, then you should coordinate your work with current >> maintainers (fine that you seek help and guidance from others too, >> but don't go ahead with only input from external parties). > > this is something that a good sponsor has to check, and the reason for > me putting *you* in cc :) Could you please elaborate on what you find an obvious role for a "sponsor" here. Assume I have never¹ hear that term before. ¹ I have, but from the context here I suspect we mean different things by that term. [remaining mail skipped for now, to keep a focus] - 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#835658: RFS: backbone/1.3.3+ds-1
(dropping the cc list from my next email, please follow #835658 if you care about the thread) >Don't take for granted that what you find obvious is equally obvious to >others. Especially when raised as an explicit question: Makes you seem >like taking me for a fool (which I am sure was not intended). yes, you are right, I didn't mean to take you as a fool of course :) (glad you didn't take seriously my bad communication) In my opinion help in maintenance means "hey maintainer/team, is it ok to add me as uploader"? in this case I see more as a: "hey maintainer/team, can I update it to the latest release because foo and bar"? this seems intended as a one-shot upload (of course the goal release is Stretch so we have to see it properly migrate to testing), to fix the reverse-dependencies. each case is different, pkg-javascript is a big team, and probably with not so good defined rules (specially because the packaging for most of the packages is so trivial) >>> If the former, then you should coordinate your work with current >>> maintainers (fine that you seek help and guidance from others too, >>> but don't go ahead with only input from external parties). >> >> this is something that a good sponsor has to check, and the reason for >> me putting *you* in cc :) > >Could you please elaborate on what you find an obvious role for a >"sponsor" here. Assume I have never¹ hear that term before. > > >¹ I have, but from the context here I suspect we mean different things >by that term. (still not a native speaker, so apologizes in advance and again if I made some communication mistakes) "sponsor" is a word that I guess comes from the RFS term, in my opinion a sponsor is a person that tries to facilitate the fix for a particular bug or package, and eventually uploads the package. In this case the correct word would have probably been "mentor", because what I checked was to be sure the Team/Maintainer/Uploaders were agreeing on the changes. (BTW to be fair, I also cc'd the people who requested the new version, to give publicly a thread to say their opinion) so, even if I used the "sponsor" word, I don't intend of course to upload anything, at least until somebody with an authoritative hat asks me to do it :) >[remaining mail skipped for now, to keep a focus] this is nice, thanks (I hope my good faith is not in discussion here!) G.
Bug#835658: RFS: backbone/1.3.3+ds-1
Hi, On 28/08/2016 19:51, Jonas Smedegaard wrote: Quoting Julien Puydt (2016-08-28 16:12:33) On 28/08/2016 15:43, Jonas Smedegaard wrote: Quoting Julien Puydt (2016-08-28 14:35:32) On 28/08/2016 10:00, Gianfranco Costamagna wrote: I am looking for a sponsor for the package "backbone" Do you intend to help maintain the package collaboratively, or take over maintenance? Collaboratively. Great! ...but perhaps we have different understandings of that term, then: It seems you prepared a new package release with radical structural changes, and requested sponsorship for uploading it. First I hear of all that is today, after the fact. Did I miss some prior communication somehow? If not, then please elaborate a bit on the kind of collaboration you want. [holding back on answering the rest of the mail until above is more clear] Answer about the missed prior communication : () 3 may 2014, Julian Taylor files #746787 asking for a new upstream release (eh, that was for ipython and I'm aiming for jupyter, which is ex-ipython!) ; () 1 september 2015, Pirate Praveen files #797698, asking for a new version ; () 5 october 2015, David Prévot notes that #797698 affects owncloud ; () 16 november 2015, Thomas Goirand comments #797698 that he also needs a higher version and asked if he could do the work -- he didn't get a reply (at least in the bug) ; () 1 june 2016, Christophe Troestler complains in #797698 that owncloud in Debian is stuck to a older version (here the situation is cloudy [pun intended], because the same day David Prévot removes the indication that this bug affects owncloud...) Answer about the meaning of collaboration : I mean work together (in fact, that's precisely what the Latin roots of the word mean). And by together, I don't mean always together. Just that several hands cooperate to get things done. If one hand is resting, the other can do whatever is needed alone. I hope that clears things as requested, Snark on #debian-js
Bug#835863: RFS: rhythmbox-plugin-alternative-toolbar/0.17.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rhythmbox-plugin-alternative-toolbar" * Package name: rhythmbox-plugin-alternative-toolbar Version : 0.17.2-1 Upstream Author : David Mohammed fossfree...@ubuntu.com * URL : github.com/fossfreedom/alternative-toolbar * License : GPLv3 Section : misc It builds those binary packages: rhythmbox-plugin-alternative-toolbar - Enhanced play controls and interface for Rhythmbox To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.17.2-1.dsc More information about alternative-toolbar can be obtained from https://github.com/fossfreedom/alternative-toolbar/blob/master/README.md Checks: lintian -i -I on source and deb packages check-all-the-things for the package folder Changes since the last upload: * New upstream release - Fix for RB 3.4 (#97) - New pl translation * Packaging Changes - Updated maintainer email address - updated copyright year for Rosetta translations - added missing Vcs-Git to point to github debian branch - updated with relevant recommendations from cme check dpkg - added upstream metadata Regards, David Mohammed
Bug#835863: marked as done (RFS: rhythmbox-plugin-alternative-toolbar/0.17.2-1)
Your message dated Sun, 28 Aug 2016 21:31:39 + (UTC) with message-id <884064059.1791940.1472419899...@mail.yahoo.com> and subject line Re: Bug#835863: RFS: rhythmbox-plugin-alternative-toolbar/0.17.2-1 has caused the Debian Bug report #835863, regarding RFS: rhythmbox-plugin-alternative-toolbar/0.17.2-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 835863: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835863 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rhythmbox-plugin-alternative-toolbar" * Package name: rhythmbox-plugin-alternative-toolbar Version : 0.17.2-1 Upstream Author : David Mohammed fossfree...@ubuntu.com * URL : github.com/fossfreedom/alternative-toolbar * License : GPLv3 Section : misc It builds those binary packages: rhythmbox-plugin-alternative-toolbar - Enhanced play controls and interface for Rhythmbox To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.17.2-1.dsc More information about alternative-toolbar can be obtained from https://github.com/fossfreedom/alternative-toolbar/blob/master/README.md Checks: lintian -i -I on source and deb packages check-all-the-things for the package folder Changes since the last upload: * New upstream release - Fix for RB 3.4 (#97) - New pl translation * Packaging Changes - Updated maintainer email address - updated copyright year for Rosetta translations - added missing Vcs-Git to point to github debian branch - updated with relevant recommendations from cme check dpkg - added upstream metadata Regards, David Mohammed --- End Message --- --- Begin Message --- Hi, >rhythmbox-plugin-alternative-toolbar done (please avoid if possible html emails :) ) G.--- End Message ---
