Bug#797021: ITP: midicsv -- translate MIDI file to CSV
On Sat, Aug 29, 2015 at 04:46:05PM -0400, Scott Kitterman wrote: Was there a previous ITP bug? Everything boils down to an ITP bug? I think this clearly shows my intent to package it: https://people.debian.org/~sanvila/wip/ (not touched it in several days) And it is too much coincidence. Compare the timestamps.
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
On Sat, Aug 29, 2015 at 11:24:12PM +0200, Santiago Vila wrote: Everything boils down to an ITP bug? In the case of a dispite, well, yeah, that's clearly why they exist. I think this clearly shows my intent to package it: Sure, *your* intent, but that's not you getting the global mutex. If I want to package something, I'll search for a RFP or ITP, and use that. If I don't see anything, I put it in NEW. https://people.debian.org/~sanvila/wip/ ... I surely don't look at every DD's people.d.o for a .dsc When two threads do work without both checking the mutex, you end up with a race condition when both try to write data back out. Live and learn. This is literally why ITPs exist. Frankly, you're assuming malice. That's out of line, Why not be friendly and create something positive out of this. Paul signature.asc Description: Digital signature
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
On Saturday, August 29, 2015 11:24:12 PM Santiago Vila wrote: On Sat, Aug 29, 2015 at 04:46:05PM -0400, Scott Kitterman wrote: Was there a previous ITP bug? Everything boils down to an ITP bug? Yes. This one of the reasons we have them. I think this clearly shows my intent to package it: https://people.debian.org/~sanvila/wip/ (not touched it in several days) And it is too much coincidence. Compare the timestamps. Having looked at the package as uploaded and compared it to yours on p.d.o, it's clear to me that the packaging is independent. Next time, write an ITP. As I said before, offer to co-maintain it. Scott K
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
Hi Santiago- Santiago Vila wrote: I can't believe this is just a coincidence What kind of strange package hijacking is this? Wow, that is quite a coincidence! (But that's all it is...) On Sat, Aug 29, 2015 at 04:46:05PM -0400, Scott Kitterman wrote: Was there a previous ITP bug? On Sat, Aug 29, 2015 at 11:24:12PM +0200, Santiago Vila wrote: Everything boils down to an ITP bug? On Sat, Aug 29, 2015 at 2:52 PM, Paul Tagliamonte paul...@debian.org wrote: In the case of a dispite, well, yeah, that's clearly why they exist. I think this clearly shows my intent to package it: Sure, *your* intent, but that's not you getting the global mutex. If I want to package something, I'll search for a RFP or ITP, and use that. If I don't see anything, I put it in NEW. Yup, that's exactly what I did (as usual). I discovered midicsv last week -- its just what I needed for a project I'm working on, and seemed like a generally useful tool. Finding no existing Debian package, no ITP, and no google hits for debian midicsv, I filed an ITP, packaged it, and uploaded it to the new queue. Santiago Vila wrote: https://people.debian.org/~sanvila/wip/ Paul Tagliamonte paul...@debian.org wrote: ... I surely don't look at every DD's people.d.o for a .dsc Of course. Neither did I. Because that's what ITP's are for. I'm not sure, Santiago, how you imagine that I or anyone else might have known of your intent to package this. Paul Tagliamonte paul...@debian.org wrote: When two threads do work without both checking the mutex, you end up with a race condition when both try to write data back out. Live and learn. This is literally why ITPs exist. Frankly, you're assuming malice. That's out of line, Why not be friendly and create something positive out of this. Well said, Paul. Santiago, it is disappointing that you'd jump to the (wholly incorrect) conclusion that I had somehow hijacked your package or your work. Its just a coincidence that we both happened to package this on the same day (but I followed proper ITP upload procedures, whereas you didn't). -Kamal
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
On 14048 March 1977, Santiago Vila wrote: Was there a previous ITP bug? Everything boils down to an ITP bug? For new packages? Yes, definitely. I think this clearly shows my intent to package it: https://people.debian.org/~sanvila/wip/ Nope, that is irrelevant, completly. I've put something up at $randomlocation is worth nothing. We have a system to show one is working on packages. If you don't use it, you lost. (Or you make something out of it, use ITPs in the future, and now talk to the other about team maintenance, which is the better thing anyways) -- bye, Joerg You're in good shape for being a Debian, with a SAP background ... anything has to look good from there...
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
On Wed, Aug 26, 2015 at 04:42:02PM -0700, Kamal Mostafa wrote: Package: wnpp Severity: wishlist Owner: Kamal Mostafa ka...@debian.org * Package name: midicsv Version : 1.1 Upstream Author : John Walker @ http://www.fourmilab.ch/ * URL : http://www.fourmilab.ch/webtools/midicsv/ * License : public-domain Programming Lang: C Description : translate MIDI file to CSV Midicsv reads a standard MIDI file and decodes it into a CSV (Comma-Separated Value) file which preserves all the information in the MIDI file. The ASCII CSV file may be loaded into a spreadsheet or database application, or processed by a program to transform the MIDI data (for example, to key transpose a composition or extract a track from a multi-track sequence). A CSV file in the format created by midicsv may be converted back into a standard MIDI file with the csvmidi program. I can't believe this is just a coincidence What kind of strange package hijacking is this? I had this package at people.debian.org and it was going to be the first package of Víctor Cuadrado. Puzzled.
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
On August 29, 2015 4:13:28 PM EDT, Santiago Vila sanv...@unex.es wrote: On Wed, Aug 26, 2015 at 04:42:02PM -0700, Kamal Mostafa wrote: Package: wnpp Severity: wishlist Owner: Kamal Mostafa ka...@debian.org * Package name: midicsv Version : 1.1 Upstream Author : John Walker @ http://www.fourmilab.ch/ * URL : http://www.fourmilab.ch/webtools/midicsv/ * License : public-domain Programming Lang: C Description : translate MIDI file to CSV Midicsv reads a standard MIDI file and decodes it into a CSV (Comma-Separated Value) file which preserves all the information in the MIDI file. The ASCII CSV file may be loaded into a spreadsheet or database application, or processed by a program to transform the MIDI data (for example, to key transpose a composition or extract a track from a multi-track sequence). A CSV file in the format created by midicsv may be converted back into a standard MIDI file with the csvmidi program. I can't believe this is just a coincidence What kind of strange package hijacking is this? I had this package at people.debian.org and it was going to be the first package of Víctor Cuadrado. Puzzled. Was there a previous ITP bug? Scott K
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
On Sat, Aug 29, 2015 at 03:28:44PM -0700, Kamal Mostafa wrote: Santiago, it is disappointing that you'd jump to the (wholly incorrect) conclusion that I had somehow hijacked your package or your work. Its just a coincidence that we both happened to package this on the same day (but I followed proper ITP upload procedures, whereas you didn't). It was not really my package or my work. Before your ITP, my plan was to file a RFP with Víctor as the owner. He asked me in Debconf for something to work, and I suggested this package which I had in a private repo for years. But if the package is not going to be maintained by him because I didn't file an ITP in time, so be it. Thanks.
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
On Sun, Aug 30, 2015 at 01:07:15AM +0200, Santiago Vila wrote: On Sat, Aug 29, 2015 at 03:28:44PM -0700, Kamal Mostafa wrote: Santiago, it is disappointing that you'd jump to the (wholly incorrect) conclusion that I had somehow hijacked your package or your work. Its just a coincidence that we both happened to package this on the same day (but I followed proper ITP upload procedures, whereas you didn't). It was not really my package or my work. Before your ITP, my plan was to file a RFP with Víctor as the owner. He asked me in Debconf for FWIW, an RFP isn't right either. That's a request for packaging. Kamal would have just turned it into an ITP and set himself as the owner. You should have filed an *ITP* with your mentee. I suggest you do a WNPP touch-up and re-read the devref. something to work, and I suggested this package which I had in a private repo for years. But if the package is not going to be maintained by him because I didn't file an ITP in time, so be it. Thanks. There's no reason you can't work together. Why not try to be helpful and work together? Three is better than two or one. Cheers, Paul signature.asc Description: Digital signature
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
[ trimming CC a little bit ] On Sat, Aug 29, 2015 at 07:11:32PM -0400, Paul Tagliamonte wrote: On Sun, Aug 30, 2015 at 01:07:15AM +0200, Santiago Vila wrote: It was not really my package or my work. Before your ITP, my plan was to file a RFP with Víctor as the owner. He asked me in Debconf for FWIW, an RFP isn't right either. That's a request for packaging. Kamal would have just turned it into an ITP and set himself as the owner. I'm confused now. Please note that I said with Víctor as the owner. Do you mean that the owner of a bug report is not a mutex, much like the person filing the ITP? Until now I believed that the following two bugs were equivalent: From: A Subject: RFP: foo Owner: B From: B Subject: ITP: foo but now you say that anybody can change the owner in the first report. If that's the case, what do we have this Owner thing for, then? (Speaking about the BTS in general, not about ITPs in particular). Thanks.
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
On Sun, Aug 30, 2015 at 01:45:32AM +0200, Santiago Vila wrote: I'm confused now. Please note that I said with Víctor as the owner. Do you mean that the owner of a bug report is not a mutex, much like the person filing the ITP? Owning a RFP basically means nothing. It might be weird enough to someone looking at it that they'd ask, but here's a workflow (again, I invite you to re-read the devref) RFPs, when they get an owner are turned into an ITP, since you're no longer requesting someone package it, but rather, intend to actually upload it. If someone sees an RFP, the idea is they retitle to an ITP and set owner. I'd likely do it without reading the RFP, so I'd miss any owner. If you stall on the ITP, it's polite to turn the ITP (back?) into an RFP. Until now I believed that the following two bugs were equivalent: From: A Subject: RFP: foo Owner: B From: B Subject: ITP: foo Yay! So, they're not. So, misconception corrected! If you intend to upload, you should, well, show that with the bug. By making it an intent to upload bug. Since you intend to upload. It's not a request anymore. but now you say that anybody can change the owner in the first report. I likely would without checking, but someone more careful might check, say Hunh, that's weird and email. If that's the case, what do we have this Owner thing for, then? It's a general feature of the BTS. Owner has meaning for ITPs, but RFPs, that's weird. You can't really own the request like someone owns the intent. (Speaking about the BTS in general, not about ITPs in particular). Thanks. Cheers, Paul signature.asc Description: Digital signature
Bug#797021: ITP: midicsv -- translate MIDI file to CSV
Package: wnpp Severity: wishlist Owner: Kamal Mostafa ka...@debian.org * Package name: midicsv Version : 1.1 Upstream Author : John Walker @ http://www.fourmilab.ch/ * URL : http://www.fourmilab.ch/webtools/midicsv/ * License : public-domain Programming Lang: C Description : translate MIDI file to CSV Midicsv reads a standard MIDI file and decodes it into a CSV (Comma-Separated Value) file which preserves all the information in the MIDI file. The ASCII CSV file may be loaded into a spreadsheet or database application, or processed by a program to transform the MIDI data (for example, to key transpose a composition or extract a track from a multi-track sequence). A CSV file in the format created by midicsv may be converted back into a standard MIDI file with the csvmidi program.
