Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
I'd lke to see the ITP be MUST but the ITP template be SHOULD. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120415221713.GA24051@debian
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
People embarking on packaging a bit of software are also supposed to contact the upstream author. When one contacts the upstream author and they respond quickly and say they'd love to have the software packaged and they don't know of anyone else doing so, an ITP can seem (depending on the particulars of the situation) a bit superfluous. If people are going to do only one of (a) heads-up to upstream author, and (b) file an ITP, I personally would rather see them do (a). Of course, doing both would typically be best. --Barak. -- Barak A. Pearlmutter Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/E1SIy6b-7u-Cf@port-kdr.hamilton.local
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
On Sat, Apr 14, 2012 at 4:13 PM, Barak A. Pearlmutter wrote: People embarking on packaging a bit of software are also supposed to contact the upstream author. When one contacts the upstream author and they respond quickly and say they'd love to have the software packaged and they don't know of anyone else doing so, an ITP can seem (depending on the particulars of the situation) a bit superfluous. If people are going to do only one of (a) heads-up to upstream author, and (b) file an ITP, I personally would rather see them do (a). Of course, doing both would typically be best. Might be best to both at once (using X-Debbugs-CC)? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6g41h_ra16ps-kd0e1fah9myqd_cyx+pj-bmfltww1...@mail.gmail.com
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
On Sat, 2012-04-14 at 17:21 +0800, Paul Wise wrote: Might be best to both at once (using X-Debbugs-CC)? That's fine if the upstream author is sufficiently aware of Debian processes, but if not then the ITP template is rather an impersonal way to make contact. Despite licences, it's polite to start by asking the author if they're happy about this version of the software being packaged at this time. Often there are also a few specific questions to politely raise (e.g. if they would mind using a configurable prefix rather than hard-coding /opt/arbitraryname/ on every second line, or if the files in the warez/ subdirectory are really under the overall GPL licence). It's more friendly to ask these directly to the upstream maintainer (this can be CCd to the ITP), rather than in a CC of a message somewhere else. (I'm slightly torn between our usual openness and the benefits of CCing all such questions to the ITP, versus the potential unfairness of incriminating upstream by picky licensing questions -- in those cases it may be better to only CC the ITP once a positive solution is found.) -- Moray -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1334398351.16637.16.ca...@claudin.sermisy.org
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Le Wednesday 28 March 2012 07:31:19, Jean-Christophe Dubacq a écrit : The best way to become hyper-efficient is to avoid this kind of overhead, automate everything, and be prepared to fail quickly and iterate. What about a dev. script that would be run in debian/ and would parse debian/control and send the ITP? I can write that! YOu can start from the script used by debian-perl team: http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=blob;f=examples/gen-itp;hb=HEAD This script is somewhat hardwired for pkg-perl team. I hope you can make it more general purpose. Hope this helps Dominique signature.asc Description: This is a digitally signed message part.
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
On Sat, Mar 31, 2012 at 4:10 AM, Goswin von Brederlow wrote: But are they always usefull? Does a package that is ready for upload already need an ITP? That is the question. The point of an ITP is that it should be sent before starting the packaging. If the package is already done then ... well ... yeah ... you must have forgotten about what the I in ITP means and may as well just upload. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6e9zglkaoqzmnfhgwwjnmjgaqpyje+zc3nvw4qy8u-...@mail.gmail.com
Re: mosh ITP not done, just package name taken over
Andrei POPESCU andreimpope...@gmail.com writes: On Ma, 27 mar 12, 08:36:58, David Banks wrote: In the specific case of mosh, I have posted three RFS messages to debian-mentors since filing the ITP, in addition to the creation of the RFS bug after the sponsorship-requests procedure was announced, so the package was certainly being worked on. However I did not CC the RFS messages to the ITP bug, so they weren't recorded there. Would this be a recommended practice? How should it interact with the new sponsorship-requests process? Block the ITP bug by the RFS bug? Kind regards, Andrei +1. Since RFS are also bugs that seems to be the natural way to connect the two. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwcq9t3o.fsf@frosties.localnet
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Ansgar Burchardt ans...@debian.org writes: Jean-Christophe Dubacq jcduba...@free.fr writes: What about a dev. script that would be run in debian/ and would parse debian/control and send the ITP? I can write that! Yes please. The Perl group already has a script that does this: examples/get-itp in git.debian.org:/git/pkg-perl/scripts.git. I don't use it myself and it might not work that well with non-pkg-perl packages. Regards, Ansgar Please integrate this with reportbug. It should be possible to report an ITP with reportbug and have it look up most of the information automatically in debian/control and debian/copyright. Even better would be if it supports RFS as well. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bone9swi.fsf@frosties.localnet
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
+++ Neil Williams [2012-03-26 09:17 +0100]: Therefore packaging takes no time at all, it is always fully complete before the code itself is even worth evaluating as useful to Debian. The packaging is part of my test harness. You are only looking at this from the upstream's point of view. Most packaging is someone else's software. And getting it into a decently-package state can take a _long_ time. I've got one here I've been working on from time to time for over a year: (first waiting for upstream to provide a licence, then finding out how to package ocaml stuff, then waiting for some promised docs - which I eventually wrote myself after nothing happened for months, and now it's stalled because something changed in ocaml worlkd and it doesn't build). That's been about 18 months so far. It _will_ be uploaded very soon. (misery). I have about 6 other packages here which get attention from time to time and should eventually reach an uploadable state. Yes. I should file more ITP bugs and keep them updated, and mostly I don't bother and may find I wasted my or someone else's time as a result, but I'm just pointing out why your argument is wrong, due to taking a narrow, and unrepresentative, viewpoint. The appropriate thing to do when confronted with a months-old ITP for a package with the same content or name as your package is almost certianly to ignore old intent and get on with it. Absolutely disagree. Hijacking the ITP and/or package name without saying a single word about that to the ITP bug thread is just plain rude. If an ITP remains open without comment for more than a month, the chances that there will ever be an upload to close it are close to zero. That may be true in an 'averages' sense, but there are old open ITPs with a lot of work behind them and uploads will eventually arise, if only because someone takes over that work to finish it off. ITP bugs must not be allowed to block actual work. It's equivalent to domain-squatting and just as distasteful. Yes, sometimes the claim of ownership they imply is too strong, but it's not domain-squatting, and nor is it distateful. That's a silly thing to say. I've found ITPs very useful to find other people who have worked on stuff, and then used or updated their work (OWFS is a good example, where I made updated packages and arm packages available for a year or two before it finally hit the archive). Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120330133917.gc15...@dream.aleph1.co.uk
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
On Fri, Mar 30, 2012 at 02:39:17PM +0100, Wookey wrote: If an ITP remains open without comment for more than a month, the chances that there will ever be an upload to close it are close to zero. That may be true in an 'averages' sense, but there are old open ITPs with a lot of work behind them and uploads will eventually arise, if only because someone takes over that work to finish it off. I'm actually considering trying to write some UDD queries to answer some questions about ITPs, such as success rates, average gestation time, etc.; if anyone has any other particular questions that it might be worth answering, please let me know. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120330144714.GA30827@debian
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Wookey woo...@wookware.org writes: +++ Neil Williams [2012-03-26 09:17 +0100]: Therefore packaging takes no time at all, it is always fully complete before the code itself is even worth evaluating as useful to Debian. The packaging is part of my test harness. You are only looking at this from the upstream's point of view. Most packaging is someone else's software. And getting it into a By now it should be clear that packaging takes a variable amount of time ranging from 0 to month. Nobody said ITPs are never usefull, far from it. But are they always usefull? Does a package that is ready for upload already need an ITP? That is the question. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bond26k3.fsf@frosties.localnet
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Jean-Christophe Dubacq jcduba...@free.fr writes: What about a dev. script that would be run in debian/ and would parse debian/control and send the ITP? I can write that! The Perl group already has a script that does this: examples/get-itp in git.debian.org:/git/pkg-perl/scripts.git. I don't use it myself and it might not work that well with non-pkg-perl packages. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vilnqf4@deep-thought.43-1.org
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Le Tue, Mar 27, 2012 at 06:46:21PM -0400, Joey Hess a écrit : But, writing an ITP requires looking up most of the control file data, and requires researching the copyright too. Hi all, I have sent ITPs containing a copy of the control and copyright files instead of the proposed layout, and nobody complained about it. Perhaps the template could contain a line explaining that following it is not mandatory ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120328235000.gb20...@falafel.plessy.net
Re: mosh ITP not done, just package name taken over
Hi list, On 25/03/12 21:00, Joey Hess wrote: The appropriate thing to do when confronted with a months-old ITP for a package with the same content or name as your package is almost certianly to ignore old intent and get on with it. In the specific case of mosh, I have posted three RFS messages to debian-mentors since filing the ITP, in addition to the creation of the RFS bug after the sponsorship-requests procedure was announced, so the package was certainly being worked on. However I did not CC the RFS messages to the ITP bug, so they weren't recorded there. Would this be a recommended practice? How should it interact with the new sponsorship-requests process? My first RFS to debian-mentors was posted two days after filing the initial ITP. As a post-script, although I am sad to see this furore, I am selfishly happy to see my package finally get some attention after languishing in -mentors for months and months. ;) Cheers, David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkrqmu$p45$1...@dough.gmane.org
Re: mosh ITP not done, just package name taken over
On Mon, Mar 26, 2012 at 05:11:54AM +0200, Goswin von Brederlow wrote: Chris Knadle chris.kna...@coredump.us writes: There's a flip-side to this story, which is what happens when an ITP is filed and left-for-dead. This then turns into a situation where a prospective new packager then needs to figure out how to re-assign the ITP to someone else, (because hijacking an ITP is just rude) Then you send a mail to the ITP CCing the submitter and if he doesn't respond in a reasonable timeframe you take over. There seem to be some pretty good (if perhaps not fully automated/consistent) QA processes for stale ITPs. I've just taken over one that had been auto-reset to a RFP due to inactivity of the original packager. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120327084151.GA25378@debian
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
On Mon, Mar 26, 2012 at 05:06:55PM +0200, Goswin von Brederlow wrote: Eugene V. Lyubimkin jac...@debian.org writes: e) useful to prevent a duplicate work. Pointless if the package is uploaded the moment the BTS responds with the bug number for the ITP, which was the hypotetical. That was Joey's hypothetical, iirc, and I don't really agree with his supposition that initial packaging is such quick work that the ITP delay is significant. Not all developers are as hyper-efficient as Joey Hess, for some of us preparing a package is not a 5 minute job. Filing an ITP *before* embarking on the initial packaging work at least minimizes the risk of two developers doing independent work at the same time. If one developer spots the ITP, they can either cede to the person who got the ITP in first, or offer to help. In the simple case: 1) file ITP with the infos you put in debian/control 2) dh_make 3) write debian/control (cutpaste the description, homepage, ... from the ITP) 4) write debian/copyright 5) remove some example files 6) build, test, upload If you have a BTS turnaround time of 2h then there certainly is enough time to finish. For rock stars such as yourself and Joey ☺ I rarely have a straight run of two hours to spare, even if it were to take that long and not longer. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120327084702.GB25378@debian
Re: mosh ITP not done, just package name taken over
On Tue, Mar 27, 2012 at 08:36:58AM +0100, David Banks wrote: As a post-script, although I am sad to see this furore, I am selfishly happy to see my package finally get some attention after languishing in -mentors for months and months. ;) I think Christine sponsoring your package would be karmic re-balancing for hijacking your package name. What do you think, Christine? ☺ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120327084803.GC25378@debian
Re: mosh ITP not done, just package name taken over
On Ma, 27 mar 12, 08:36:58, David Banks wrote: In the specific case of mosh, I have posted three RFS messages to debian-mentors since filing the ITP, in addition to the creation of the RFS bug after the sponsorship-requests procedure was announced, so the package was certainly being worked on. However I did not CC the RFS messages to the ITP bug, so they weren't recorded there. Would this be a recommended practice? How should it interact with the new sponsorship-requests process? Block the ITP bug by the RFS bug? Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Jon Dowland wrote: That was Joey's hypothetical, iirc, and I don't really agree with his supposition that initial packaging is such quick work that the ITP delay is significant. The typical package is fairly trivial to create. Often the rules file doesn't need modifications anymore, so unless a man page has to be written (which can be put off anyway), the control and copyright file are probably what takes the longest. But, writing an ITP requires looking up most of the control file data, and requires researching the copyright too. For that matter, I'll bet that many developers do some basic compiling and running of the program before sending off the ITP -- why ITP something that you've never used? So the package can easily be half way complete before the ITP is sent. Running reportbug WNPP, filtering the existing reports to find a duplicate, and filling in basic data with cut-n-paste takes two or three minutes. Add the several minutes it takes to get a number back, add the interrupt needed to go check mail and get the bug, avoid getting dragged into some thread on debian-devel while doing it, and you've spent 10 minutes on the ITP if you're lucky, and I would guess, more likely half an hour. The best way to become hyper-efficient is to avoid this kind of overhead, automate everything, and be prepared to fail quickly and iterate. -- see shy jo signature.asc Description: Digital signature
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
On 28/03/2012 00:46, Joey Hess wrote: Jon Dowland wrote: That was Joey's hypothetical, iirc, and I don't really agree with his supposition that initial packaging is such quick work that the ITP delay is significant. The typical package is fairly trivial to create. Often the rules file doesn't need modifications anymore, so unless a man page has to be written (which can be put off anyway), the control and copyright file are probably what takes the longest. But, writing an ITP requires looking up most of the control file data, and requires researching the copyright too. For that matter, I'll bet that many developers do some basic compiling and running of the program before sending off the ITP -- why ITP something that you've never used? So the package can easily be half way complete before the ITP is sent. Running reportbug WNPP, filtering the existing reports to find a duplicate, and filling in basic data with cut-n-paste takes two or three minutes. Add the several minutes it takes to get a number back, add the interrupt needed to go check mail and get the bug, avoid getting dragged into some thread on debian-devel while doing it, and you've spent 10 minutes on the ITP if you're lucky, and I would guess, more likely half an hour. The best way to become hyper-efficient is to avoid this kind of overhead, automate everything, and be prepared to fail quickly and iterate. What about a dev. script that would be run in debian/ and would parse debian/control and send the ITP? I can write that! -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
I disagree almost completely. On 2012-03-25 16:00, Joey Hess wrote: But still nothing. ITP is more often than not a pointless bureaucracy. No, it's not nothing, and it's not a pointless bureaucracy. Filing an ITP shows your intent to a hundreds of developers, which is: a) useful for the ITP owner since it advertises the package for the prospective users; b) useful for the Debian project since experienced people may immediately point that there are/there were some problems which prevented the package to be added before or made the package disappear from Debian archives in the past; c) useful for the Debian project since experienced people may ask the ITP owner why to package the thing at all if they know/suspect there are superior things in the archive already; d) useful for the Debian project because people sometimes choose too confusing/short names for packages, and answering to an ITP is usually the only chance for the public to suggest some better name before the package entered the archive, after which the renaming is more time-consuming and bureaucratic; e) useful to prevent a duplicate work. The turnaround time for packaging the average package is less than the turnaround time in getting back a ITP bug number. I very doubt that. I even have a doubt that there is a single proper Debian package for which the time between 'Oh, I will package this' and uploading a package to archives takes less than 15 minutes (which a BTS turnaround time for me) as there are too many things to write/check which require the human attention. But maybe that's me being too slow. Chances are very high that ITP filing has wasted more time than it's ever saved in duplicated work. Disagree. Filing an ITP bug takes, well, a minute of the developer's time. One ITP may prevent hours of the duplicate work, and in this case it paid for hundreds of boring ITPs, even if we don't count reasons a)-d) above. It's also caused much stalling of legitimate work. It can cause a bit of stalling in some cases, but is it really much? Especially comparing to license or spare developer time delays? The appropriate thing to do when confronted with a months-old ITP for a package with the same content or name as your package is almost certianly to ignore old intent and get on with it. Absolutely disagree. Hijacking the ITP and/or package name without saying a single word about that to the ITP bug thread is just plain rude. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120326065535.GA10629@r500-debian
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
On Mon, 26 Mar 2012 09:55:35 +0300 Eugene V. Lyubimkin jac...@debian.org wrote: On 2012-03-25 16:00, Joey Hess wrote: But still nothing. ITP is more often than not a pointless bureaucracy. No, it's not nothing, and it's not a pointless bureaucracy. Filing an ITP shows your intent to a hundreds of developers, which is: a) useful for the ITP owner since it advertises the package for the prospective users; That's true mostly after the ITP is closed but it's also true if the package, once uploaded, has a sensible package description. Both get indexed by every search engine worth using. The ITP itself has no real impact on this. The ITP shouldn't need to be open that long. b) useful for the Debian project since experienced people may immediately point that there are/there were some problems which prevented the package to be added before or made the package disappear from Debian archives in the past; c) useful for the Debian project since experienced people may ask the ITP owner why to package the thing at all if they know/suspect there are superior things in the archive already; d) useful for the Debian project because people sometimes choose too confusing/short names for packages, and answering to an ITP is usually the only chance for the public to suggest some better name before the package entered the archive, after which the renaming is more time-consuming and bureaucratic; All of which can be good for those new to packaging but those who would do the commenting are generally reasonably proficient at anticipating such issues and choosing sensible names etc. from the beginning. The turnaround time for packaging the average package is less than the turnaround time in getting back a ITP bug number. I very doubt that. I even have a doubt that there is a single proper Debian package for which the time between 'Oh, I will package this' and uploading a package to archives takes less than 15 minutes (which a BTS turnaround time for me) as there are too many things to write/check which require the human attention. But maybe that's me being too slow. No, it's quite often true. I can see exactly what Joey is getting at here because I suspect that my development flow may be similar at times. I get an idea for a tool or utility - I do a test in shell or something quick, decide which language it's going to be in when done properly and before I've even written a line of the final code, I'll create a debian/ directory, populate debian/control and get the whole thing rolling because often the easiest way to test the code is as a local package. If it doesn't work, no harm done. If it does work, the packaging is already in place, so the ITP is just a delay. I have still used ITPs for recent packages but the packages were all uploaded within minutes of filing the ITP and closed within hours. As Joey describes, I was waiting for the bug number in order to make the changelog entry, create a tag in the VCS and upload. It does make the whole ITP process seem a waste of time and I might not bother in future as there is not going to be any real opportunity for anyone to comment on the ITP in that time. I do the same with code written at work - the first thing I create is the debian/ directory, even before I've written main.cpp. A Debian package is my natural development platform. I can't remember when I last did any development - including upstream development - which did not start and be completely contained within a Debian package. I often release code without a debian/ directory as an upstream developer but that code has been developed and tested with the same debian/ directory as will be found in the Debian package uploaded a few moments after the upstream release. Therefore packaging takes no time at all, it is always fully complete before the code itself is even worth evaluating as useful to Debian. The packaging is part of my test harness. The appropriate thing to do when confronted with a months-old ITP for a package with the same content or name as your package is almost certianly to ignore old intent and get on with it. Absolutely disagree. Hijacking the ITP and/or package name without saying a single word about that to the ITP bug thread is just plain rude. I think ITP's should have a strict and absolute time limit - there is already some work to monitor aged ITP's/ITA's and rename to RFP: or O: but actually packaging something does not take long and if there are reasons to delay a particular package, it can be mentioned in a comment to the ITP or elsewhere. If an ITP remains open without comment for more than a month, the chances that there will ever be an upload to close it are close to zero. If the upload is simply waiting for a sponsor then *say so* in the ITP and put a link to mentors.debian.net. ITP bugs must not be allowed to block actual work. It's equivalent to domain-squatting and just as distasteful. If there are legal
Re: mosh ITP not done, just package name taken over
On Mon, 26 Mar 2012 01:20:10 +0200 Goswin von Brederlow goswin-...@web.de wrote: There might be a good reason why the ITP is staled, like your own example with copyright issues. What would you say if someone else just ignored your ITP and uploaded the package without clearing up the copyright issues or even uploading a different package hijacking your package name? When you have to resolve legal issues with upstream a delay of a month or two is nothing. MfG As long as there are comments in the ITP to this effect, fine. An ITP which just sits there for months on end without any comment or upload is unhelpful to everyone. If there are problems, then the ITP is one place where those problems can be shared and others may be able to help. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpGqc2oUoizr.pgp Description: PGP signature
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
[ sorry for duplicate, Neil, pressed the wrong button ] On 2012-03-26 09:17, Neil Williams wrote: On Mon, 26 Mar 2012 09:55:35 +0300 Eugene V. Lyubimkin jac...@debian.org wrote: [...] No, it's not nothing, and it's not a pointless bureaucracy. Filing an ITP shows your intent to a hundreds of developers, which is: a) useful for the ITP owner since it advertises the package for the prospective users; That's true mostly after the ITP is closed but it's also true if the package, once uploaded, has a sensible package description. Both get indexed by every search engine worth using. The ITP itself has no real impact on this. [...] No, it has. At least for me. I certainly know about or even installed some software solely because I saw an ITP for them, for example, 'lightspark'. I doubt that many people use a search engine once a while to see if there is new flash player available. And my own example to that is #524605. I know it caused some discussion before that ITP was closed, and I am fairly sure very few people would find it through a search engine. b) useful for the Debian project since experienced people may immediately point that there are/there were some problems which prevented the package to be added before or made the package disappear from Debian archives in the past; c) useful for the Debian project since experienced people may ask the ITP owner why to package the thing at all if they know/suspect there are superior things in the archive already; d) useful for the Debian project because people sometimes choose too confusing/short names for packages, and answering to an ITP is usually the only chance for the public to suggest some better name before the package entered the archive, after which the renaming is more time-consuming and bureaucratic; All of which can be good for those new to packaging but those who would do the commenting are generally reasonably proficient at anticipating such issues and choosing sensible names etc. from the beginning. Generally, yes. But not always. The turnaround time for packaging the average package is less than the turnaround time in getting back a ITP bug number. I very doubt that. I even have a doubt that there is a single proper Debian package for which the time between 'Oh, I will package this' and uploading a package to archives takes less than 15 minutes (which a BTS turnaround time for me) as there are too many things to write/check which require the human attention. But maybe that's me being too slow. No, it's quite often true. can see exactly what Joey is getting at here because I suspect that my development flow may be similar at times. I get an idea for a tool or utility - I do a test in shell or something quick, decide which language it's going to be in when done properly and before I've even written a line of the final code, I'll create a debian/ directory, populate debian/control and get the whole thing rolling because often the easiest way to test the code is as a local package. If it doesn't work, no harm done. If it does work, the packaging is already in place, so the ITP is just a delay. [...] Therefore packaging takes no time at all, it is always fully complete before the code itself is even worth evaluating as useful to Debian. The packaging is part of my test harness. This is true only for the software you are upstream for, which is, I believe, the minority of Debian packages. I'm now convinced that there are proper quickly-packaged things in Debian, but I'm still not convinced the average package could be packaged so. I think ITP's should have a strict and absolute time limit - there is already some work to monitor aged ITP's/ITA's and rename to RFP: or O: but actually packaging something does not take long and if there are reasons to delay a particular package, it can be mentioned in a comment to the ITP or elsewhere. May be useful, but not sure if a single absolute time limit would fit all the cases. If an ITP remains open without comment for more than a month, the chances that there will ever be an upload to close it are close to zero. Cannot agree. People who are trying to get their packages to Debian on debian-mentors@l.d.o often wait for more than the month. Of course we can establish a new policy to comment in ITP threads more, but that's not how things are now. Ah, by the way, another example out of my head. #611400 was about 4.5 months without a comment. Would you close it on 2012-03-01? If the upload is simply waiting for a sponsor then *say so* in the ITP and put a link to mentors.debian.net. So ITP owners should write more mails to ITP. Sounds fine, but this suggestion to write more manual mails somehow contradicts to the point (of Joey, and, as I understand, of you) that writing a one semi-automatic e-mail (ITP) is a big burden. ITP bugs must not be allowed to block actual work. It's equivalent
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Hi. On Mon, Mar 26, 2012 at 09:17:53AM +0100, Neil Williams wrote: b) useful for the Debian project since experienced people may immediately point that there are/there were some problems which prevented the package to be added before or made the package disappear from Debian archives in the past; c) useful for the Debian project since experienced people may ask the ITP owner why to package the thing at all if they know/suspect there are superior things in the archive already; d) useful for the Debian project because people sometimes choose too confusing/short names for packages, and answering to an ITP is usually the only chance for the public to suggest some better name before the package entered the archive, after which the renaming is more time-consuming and bureaucratic; All of which can be good for those new to packaging but those who would do the commenting are generally reasonably proficient at anticipating such issues and choosing sensible names etc. from the beginning. Well, much like code review, a sanity check might be useful sometimes. Just a minor suggestion to improve something could crop up. I always prefer to have my ideas checked by someone else, but then, that's my preference. I have still used ITPs for recent packages but the packages were all uploaded within minutes of filing the ITP and closed within hours. As Joey describes, I was waiting for the bug number in order to make the changelog entry, create a tag in the VCS and upload. It does make the whole ITP process seem a waste of time and I might not bother in future as there is not going to be any real opportunity for anyone to comment on the ITP in that time. I am guessing that the ITP was closed in hours because of NEW processing. So, to be clear, how does waiting minutes for the bug number when it will be processed in hours make it a waste of time? The appropriate thing to do when confronted with a months-old ITP for a package with the same content or name as your package is almost certianly to ignore old intent and get on with it. Absolutely disagree. Hijacking the ITP and/or package name without saying a single word about that to the ITP bug thread is just plain rude. I think ITP's should have a strict and absolute time limit - there is already some work to monitor aged ITP's/ITA's and rename to RFP: or O: but actually packaging something does not take long and if there are reasons to delay a particular package, it can be mentioned in a comment to the ITP or elsewhere. If an ITP remains open without comment for more than a month, the chances that there will ever be an upload to close it are close to zero. If the upload is simply waiting for a sponsor then *say so* in the ITP and put a link to mentors.debian.net. ITP bugs must not be allowed to block actual work. It's equivalent to domain-squatting and just as distasteful. This is taking it to an extreme. Even in the case of domain-squatting, the first attempt to fix the problem would be to contact the domain owner and make a gentle request to vacate. In this case, I frankly don't see the need to hijack an ITP without doing so. Otherwise, if you are not going to upload within a month of filing the ITP, then *close the ITP*. There should be no complaints if someone else assumes that the ITP is stale if there have been no comments on it for the last month. This may be your opinion, but I would still opine that it would be decent to ask the ITP owner as to why he or she has not got back to uploading it yet. However, my timelines differ greatly, and having the package in the archive very quick may suit your requirements better. Thanks. Kumar -- Make it idiot-proof, and someone will breed a better idiot. -- Oliver Elphick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120326122609.ga7...@bluemoon.alumni.iitm.ac.in
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Eugene V. Lyubimkin jac...@debian.org writes: I disagree almost completely. On 2012-03-25 16:00, Joey Hess wrote: But still nothing. ITP is more often than not a pointless bureaucracy. No, it's not nothing, and it's not a pointless bureaucracy. Filing an ITP shows your intent to a hundreds of developers, which is: a) useful for the ITP owner since it advertises the package for the prospective users; Since you are supposed to file the ITP before starting on the package that is pretty useless. It only advertises the existance of the upstream and that isn't really debians job. One should rather have an IHP (I Have Packaged) for this or a PPN (Package Passed New queue). That's when it gets interesting for users. b) useful for the Debian project since experienced people may immediately point that there are/there were some problems which prevented the package to be added before or made the package disappear from Debian archives in the past; c) useful for the Debian project since experienced people may ask the ITP owner why to package the thing at all if they know/suspect there are superior things in the archive already; d) useful for the Debian project because people sometimes choose too confusing/short names for packages, and answering to an ITP is usually the only chance for the public to suggest some better name before the package entered the archive, after which the renaming is more time-consuming and bureaucratic; e) useful to prevent a duplicate work. Pointless if the package is uploaded the moment the BTS responds with the bug number for the ITP, which was the hypotetical. The turnaround time for packaging the average package is less than the turnaround time in getting back a ITP bug number. I very doubt that. I even have a doubt that there is a single proper Debian package for which the time between 'Oh, I will package this' and uploading a package to archives takes less than 15 minutes (which a BTS turnaround time for me) as there are too many things to write/check which require the human attention. But maybe that's me being too slow. In the simple case: 1) file ITP with the infos you put in debian/control 2) dh_make 3) write debian/control (cutpaste the description, homepage, ... from the ITP) 4) write debian/copyright 5) remove some example files 6) build, test, upload If you have a BTS turnaround time of 2h then there certainly is enough time to finish. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bonjxuy8.fsf@frosties.localnet
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Eugene V. Lyubimkin jac...@debian.org writes: [ sorry for duplicate, Neil, pressed the wrong button ] On 2012-03-26 09:17, Neil Williams wrote: On Mon, 26 Mar 2012 09:55:35 +0300 Eugene V. Lyubimkin jac...@debian.org wrote: [...] No, it's not nothing, and it's not a pointless bureaucracy. Filing an ITP shows your intent to a hundreds of developers, which is: a) useful for the ITP owner since it advertises the package for the prospective users; That's true mostly after the ITP is closed but it's also true if the package, once uploaded, has a sensible package description. Both get indexed by every search engine worth using. The ITP itself has no real impact on this. [...] No, it has. At least for me. I certainly know about or even installed some software solely because I saw an ITP for them, for example, 'lightspark'. I doubt that many people use a search engine once a while to see if there is new flash player available. I do read the Debian News which usualy has a section on new and noteworthy packages. I would find it much better if maintainers would write a small blurb for the News when the package is uploaded instead of an ITP. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gy7xuk7.fsf@frosties.localnet
Re: mosh ITP not done, just package name taken over
hi Christopher, On Sun, Mar 25, 2012 at 08:22:22PM +0200, Christoph Egger wrote: Hi! The `mosh` you quote reads mosh - Mobile shell that supports roaming and intelligent local echo This is something totaly different from mosh - fast R6RS Scheme interpreter I propose that the ITP is renamed to mosh-scheme, or something else that the project finds appropriate. This is an easier solution than renaming mosh (the mobile shell) now that it's been uploaded. And, it's unclear that mosh (the scheme interpreter) would ever actually be uploaded anyway since, despite the ITP, months have passed without the package appearing or any new reports on its status. Additionally I find it highly inappropriate for someone to take a package name with an open and active ITP bug [0] for some totaly unrelated package bypassing the wnpp step and uploading to the archive. Please. I find it highly amusing that anyone would prioritize a dubiously active bug report over actual action. There is no policy that says one MUST file an ITP bug in order to make a package upload. I do apologize that I didn't check before making the upload and attempt to engage in a conversation with David and anyone who may have been following the ITP. cheers, Christine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120325190839.GA13689@localhost.localdomain
Re: mosh ITP not done, just package name taken over
Hi! Christine Spang christ...@spang.cc writes: hi Christopher, Christoph, please On Sun, Mar 25, 2012 at 08:22:22PM +0200, Christoph Egger wrote: Hi! The `mosh` you quote reads mosh - Mobile shell that supports roaming and intelligent local echo This is something totaly different from mosh - fast R6RS Scheme interpreter I propose that the ITP is renamed to mosh-scheme, or something else that the project finds appropriate. This is an easier solution than renaming mosh (the mobile shell) now that it's been uploaded. And, it's unclear that mosh (the scheme interpreter) would ever actually be uploaded anyway since, despite the ITP, months have passed without the package appearing or any new reports on its status. There's a RFS from February Additionally I find it highly inappropriate for someone to take a package name with an open and active ITP bug [0] for some totaly unrelated package bypassing the wnpp step and uploading to the archive. Please. I find it highly amusing that anyone would prioritize a dubiously active bug report over actual action. There is no policy that says one MUST file an ITP bug in order to make a package upload. I do apologize that I didn't check before making the upload and attempt to engage in a conversation with David and anyone who may have been following the ITP. Read Policy 5.1 again Assuming no one else is already working on your prospective package, you must then submit a bug report (Section 7.1, “Bug reporting”) against the pseudo-package wnpp describing your plan to create a new package, including, but not limiting yourself to, a description of the package, the license of the prospective package, and the current URL where it can be downloaded from. Yes there's a *must*. Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iphsh4rh@hepworth.siccegge.de
Re: mosh ITP not done, just package name taken over
Christoph Egger christ...@christoph-egger.org writes: Read Policy 5.1 again Well right, that's devref, clicked on the wrong link but still Assuming no one else is already working on your prospective package, you must then submit a bug report (Section 7.1, “Bug reporting”) against the pseudo-package wnpp describing your plan to create a new package, including, but not limiting yourself to, a description of the package, the license of the prospective package, and the current URL where it can be downloaded from. Yes there's a *must*. -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehsgh4po@hepworth.siccegge.de
Re: mosh ITP not done, just package name taken over
On Sun, Mar 25, 2012 at 09:14:42PM +0200, Christoph Egger wrote: Christoph, please My bad---please excuse my brain's autocompletion; Christopher is a much more common name in the US. There's a RFS from February I did miss that. I do suspect that the fact that no one has sponsored that package after a month means that the mosh that I uploaded will end up having a wider audience, though. I'll talk to David and sponsor his upload if we can agree on an alternate name. Christine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120325193054.GA14024@localhost.localdomain
Re: mosh ITP not done, just package name taken over
Christoph Egger wrote: Read Policy 5.1 again Assuming no one else is already working on your prospective package, you must then submit a bug report (Section 7.1, “Bug reporting”) against the pseudo-package wnpp describing your plan to create a new package, including, but not limiting yourself to, a description of the package, the license of the prospective package, and the current URL where it can be downloaded from. Yes there's a *must*. That would a) be absurd on its face, since must is a RC bug, and the BTS does not allow package: Joe Developer and b) is a quote of section 5 of the Develper's Reference. Policy has nothing to say about WNPP. joey@gnu:~doc/debian-policyzgrep -i wnpp * zsh: exit 1 zgrep -i wnpp * -- see shy jo signature.asc Description: Digital signature
Re: mosh ITP not done, just package name taken over
On Sun, Mar 25, 2012 at 09:15:47PM +0200, Christoph Egger wrote: Christoph Egger christ...@christoph-egger.org writes: Read Policy 5.1 again Well right, that's devref, clicked on the wrong link but still Right, the developer's reference isn't policy. Forcing the creation of a WNPP bug for a package that's already ready to go is just making extra work for the sake of process. Christine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120325193620.GB14024@localhost.localdomain
Re: mosh ITP not done, just package name taken over
Christoph Egger wrote: Christoph Egger christ...@christoph-egger.org writes: Read Policy 5.1 again Well right, that's devref, clicked on the wrong link but still But still nothing. ITP is more often than not a pointless bureaucracy. The turnaround time for packaging the average package is less than the turnaround time in getting back a ITP bug number. Chances are very high that ITP filing has wasted more time than it's ever saved in duplicated work. It's also caused much stalling of legitimate work. I don't completly boycott filing ITP bugs. I've filed at least three this decade; two for packages I could not immediatly upload due to a copyright issue, and one for a package that had an independent debianization not in the archive. Applying a little common sense to filing ITP bugs will get you a long way toward realizing any possible benefits. The appropriate thing to do when confronted with a months-old ITP for a package with the same content or name as your package is almost certianly to ignore old intent and get on with it. -- see shy jo signature.asc Description: Digital signature
Re: mosh ITP not done, just package name taken over
Joey Hess jo...@debian.org writes: Christoph Egger wrote: Christoph Egger christ...@christoph-egger.org writes: Read Policy 5.1 again Well right, that's devref, clicked on the wrong link but still But still nothing. ITP is more often than not a pointless bureaucracy. The turnaround time for packaging the average package is less than the turnaround time in getting back a ITP bug number. Chances are very high that ITP filing has wasted more time than it's ever saved in duplicated work. It's also caused much stalling of legitimate work. I agree with you that filing an ITP for a package that you can just upload is just pointless busy work. But aparently you should still do it to publicize that your package now exists. I don't completly boycott filing ITP bugs. I've filed at least three this decade; two for packages I could not immediatly upload due to a copyright issue, and one for a package that had an independent debianization not in the archive. Applying a little common sense to filing ITP bugs will get you a long way toward realizing any possible benefits. The appropriate thing to do when confronted with a months-old ITP for a package with the same content or name as your package is almost certianly to ignore old intent and get on with it. -- see shy jo But this goes to far. ITP specifically exists to state that you are working on the package so that others can contact you before they work on the same thing. And they make the most sense when the packaging is going to take a while. Simply ignoring the ITP or hijacking the ITP is just rude. There might be a good reason why the ITP is staled, like your own example with copyright issues. What would you say if someone else just ignored your ITP and uploaded the package without clearing up the copyright issues or even uploading a different package hijacking your package name? When you have to resolve legal issues with upstream a delay of a month or two is nothing. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty1cuv2t.fsf@frosties.localnet
Re: mosh ITP not done, just package name taken over
Goswin von Brederlow wrote: There might be a good reason why the ITP is staled, like your own example with copyright issues. What would you say if someone else just ignored your ITP and uploaded the package without clearing up the copyright issues or even uploading a different package hijacking your package name? I would say: Oh, that was pretty dumb of me to file an ITP without any details about why it was stalled. -- see shy jo signature.asc Description: Digital signature
Re: mosh ITP not done, just package name taken over
On Sunday, March 25, 2012 19:20:10, Goswin von Brederlow wrote: Joey Hess jo...@debian.org writes: ... I don't completly boycott filing ITP bugs. I've filed at least three this decade; two for packages I could not immediatly upload due to a copyright issue, and one for a package that had an independent debianization not in the archive. Applying a little common sense to filing ITP bugs will get you a long way toward realizing any possible benefits. The appropriate thing to do when confronted with a months-old ITP for a package with the same content or name as your package is almost certianly to ignore old intent and get on with it. But this goes to far. ITP specifically exists to state that you are working on the package so that others can contact you before they work on the same thing. And they make the most sense when the packaging is going to take a while. Simply ignoring the ITP or hijacking the ITP is just rude. There's a flip-side to this story, which is what happens when an ITP is filed and left-for-dead. This then turns into a situation where a prospective new packager then needs to figure out how to re-assign the ITP to someone else, (because hijacking an ITP is just rude) before working through debian-mentors to get a sponsored upload. This isn't simply theoretical, as a package I've been slowly working on is in this very situation. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203252031.36640.chris.kna...@coredump.us
Re: mosh ITP not done, just package name taken over
Chris Knadle chris.kna...@coredump.us writes: On Sunday, March 25, 2012 19:20:10, Goswin von Brederlow wrote: Joey Hess jo...@debian.org writes: ... I don't completly boycott filing ITP bugs. I've filed at least three this decade; two for packages I could not immediatly upload due to a copyright issue, and one for a package that had an independent debianization not in the archive. Applying a little common sense to filing ITP bugs will get you a long way toward realizing any possible benefits. The appropriate thing to do when confronted with a months-old ITP for a package with the same content or name as your package is almost certianly to ignore old intent and get on with it. But this goes to far. ITP specifically exists to state that you are working on the package so that others can contact you before they work on the same thing. And they make the most sense when the packaging is going to take a while. Simply ignoring the ITP or hijacking the ITP is just rude. There's a flip-side to this story, which is what happens when an ITP is filed and left-for-dead. This then turns into a situation where a prospective new packager then needs to figure out how to re-assign the ITP to someone else, (because hijacking an ITP is just rude) before working through debian-mentors to get a sponsored upload. This isn't simply theoretical, as a package I've been slowly working on is in this very situation. -- Chris Then you send a mail to the ITP CCing the submitter and if he doesn't respond in a reasonable timeframe you take over. I never said you couldn't highjack an ITP that is left-for-dead. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878viojbt1.fsf@frosties.localnet
