Re: pre-MIA quest for Patrick Winnertz (winnie-at-d.o)
On Thu, May 31, 2012 at 09:19:37PM +0200, Mike Gabriel wrote: > Dear all, > > I have been trying to contact Patrick Winnertz (winnie-at-d.o). I > would like to see iTalc in Debian upgraded to 2.0 Relevant bug report from 3 September 2011: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640200 > but Patrick is > neither replying to contact attempts via mail (Debian Edu mailing > list, directly), nor to contact attempts via IRC. My first attempt > to reach him is about 3-4 weeks ago. That is a good reason to have a look at the MIA database. Recent upload: http://lists.debian.org/debian-devel-changes/2012/04/msg01990.html Recent message on list: http://lists.debian.org/debian-wnpp/2012/05/msg00180.html So Patrick Winnertz is not MIA. > > Earlier this year Patrick handed over the maintenance of slbackup / > slbackup-php to me. This last contact was via IRC. > > Has anyone heard from him, recently? If so, can you give him note to > get in contact with me (or the Debian Edu team)? > > If I do not hear from anyone on debian-devel@l.d.o within a week, I > will contact the MIA team and request orphanage of italc. I'm not sure but I don't think that the MIA team would orphan italc, because Patrick Winnertz is not MIA. It would be nice to get some feedback from Patrick Winnertz about this. First priority is to fix the FTBFS bug 671489. If you intend to update italc to the newest upstream release, then please retitle bug 672636 to an intention to NMU. Regards, Bart Martens -- 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/20120601042938.ga20...@master.debian.org
Work-needing packages report for Jun 1, 2012
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 454 (new: 22) Total number of packages offered up for adoption: 156 (new: 7) Total number of packages requested help for: 59 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: analog (#674866), orphaned 3 days ago Description: web server log analyzer Installations reported by Popcon: 18472 autogen (#674867), orphaned 3 days ago Description: automated text file generator Installations reported by Popcon: 33777 delta (#674869), orphaned 3 days ago Description: Heuristic minimizer of interesting files Installations reported by Popcon: 41 devil (#674868), orphaned 3 days ago Description: Cross-platform image loading and manipulation toolkit Installations reported by Popcon: 1629 freeglut (#674870), orphaned 3 days ago Description: OpenGL Utility Toolkit Installations reported by Popcon: 41006 galib (#674871), orphaned 3 days ago Description: C++ Library of Genetic Algorithm Components Installations reported by Popcon: 269 glui (#674872), orphaned 3 days ago Description: GLUI, a C++ GLUT based GUI library - Runtime support Installations reported by Popcon: 220 gnurobots (#674873), orphaned 3 days ago Description: Program a robot to explore a world Installations reported by Popcon: 138 gtkglextmm (#674875), orphaned 3 days ago Description: C++ bindings for GtkGLExt (Shared libraries) Installations reported by Popcon: 643 libbinio (#674874), orphaned 3 days ago Description: Binary I/O stream class library Installations reported by Popcon: 5776 libggi (#674876), orphaned 3 days ago Description: General Graphics Interface runtime libraries Installations reported by Popcon: 16859 libggigcp (#674877), orphaned 3 days ago Description: GGI Color and Palette Manager extension Installations reported by Popcon: 22 libggimisc (#674878), orphaned 3 days ago Description: General Graphics Interface Misc runtime libraries Installations reported by Popcon: 618 libggiwmh (#674879), orphaned 3 days ago Description: GGI Window Manager Hints extension Installations reported by Popcon: 14415 libgii (#674880), orphaned 3 days ago Description: General Input Interface runtime libraries Installations reported by Popcon: 16914 libgiigic (#674881), orphaned 3 days ago Description: development package for libgiigic Installations reported by Popcon: 2 libircclient (#674882), orphaned 3 days ago Description: C library to create IRC clients Installations reported by Popcon: 449 libquantum (#674883), orphaned 3 days ago Description: library for the simulation of a quantum computer Installations reported by Popcon: 8 libview (#674884), orphaned 3 days ago Description: VMware's Incredibly Exciting Widgets Installations reported by Popcon: 145 mssh (#674885), orphaned 3 days ago Description: tool to administrate multiple servers at once Installations reported by Popcon: 108 plib (#674886), orphaned 3 days ago Description: Portability Libraries: Run-time package Installations reported by Popcon: 3010 vbetool (#674887), orphaned 3 days ago Description: run real-mode video BIOS code to alter hardware state Installations reported by Popcon: 62712 432 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: at (#675322), offered today Description: Delayed job execution and batch processing Installations reported by Popcon: 107389 cdargs (#674833), offered 3 days ago Description: bookmarks and browsing for the cd command Installations reported by Popcon: 106 cil (#674829), offered 3 days ago Description: command line issue tracker Installations reported by Popcon: 33 fuzzyocr (#674835), offered 3 days ago Description: spamassassin plugin to check image attachments Installations reported by Popcon: 151 mumble (#674719), offered 5 days ago Installations reported by Popcon: 884 proxychains (#674776), offered 4 days ago Description: proxy chains - redirect connections through proxy servers Installations reported by Popcon: 311 s3cmd (#674916), offered 3 days ago Description: command-line Amazon S3 client Installations reported by Popcon: 450 149 older packages have been omitted from this listing, see http://www.debian.org/devel/wnp
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Le Fri, Jun 01, 2012 at 01:47:07AM +0200, Salvo Tomaselli a écrit : > > Jonas, I think we all agree that the Maintainer should Maintain > > whatever he signed up to. Non-Debian people have the right to maintain > > packages through a sponsor, and they are encouraged to. And they are > > encouraged to look for a different sponsor if their current one stops > > being responsive, and all that. > > > > However, we cannot expect them to remain active and interested > > forever. > But you can safely assume that a DD will remain interested in debian forever? > Aren't DD common human beings after all? (seems somebody would disagree) Hi all, Raphaël has interesting propositions somewhat related to matter in DEP-2. http://dep.debian.net/deps/dep2/ In particular, I think that we would benefit of a way to better describe the maintainer's involvement and expectations, as it would help to chose the best action to take when he does not give signs of activity in Debian for a long time and becomes unreachable without having managed to drop a message about this (which I think is an important thing to do when possible). http://dep.debian.net/deps/dep2/ There was some discussion about this DEP in january on debian-qa@l.d.o. I do not remember if it was discussed there, but I think that having expiration dates to the statements (like “I packaged it because I use it daily”) would help keeping the information accurate. http://lists.debian.org/debian-qa/2012/01/threads.html#00070 Have a nice day, -- Charles Plessy 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/2012060116.ga6...@falafel.plessy.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
> Jonas, I think we all agree that the Maintainer should Maintain > whatever he signed up to. Non-Debian people have the right to maintain > packages through a sponsor, and they are encouraged to. And they are > encouraged to look for a different sponsor if their current one stops > being responsive, and all that. > > However, we cannot expect them to remain active and interested > forever. But you can safely assume that a DD will remain interested in debian forever? Aren't DD common human beings after all? (seems somebody would disagree) -- Salvo Tomaselli -- 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/201206010147.07638.tipos...@tiscali.it
On "hijacking" (was: Orphaning php-codesniffer, then take it over by the PHP PEAR team)
On Wed, 30 May 2012 18:03:05 -0700, Steve Langasek wrote: > There is no excuse for hijacking a package, ever. [...] Hi Steve, while I really appreciate both your technical work and expertise as well as your personal care for Debian, this mail didn't go down well with me, for two reasons: - It sounds unnecessarily aggressive to me with threats and recourse to positions (TC), statements ex cathedra (e.g. "by definition"), and killer phrases (e.g. "empty words"); - regarding the contents, IMO you're painting the issue a bit too black-or-white; I think there's neither a common understanding what "hijacking" actually means nor a one-answer-fits-all-situations answer on this issue. I'd like to kindly ask you to join a common endeavour to come closer to a better handling of the recurring tensions between strong maintainership on the one hand and improving our distribution on the other hand. Cheers, gregor, just wanting to give a feedback -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: The Beatles: Sun King signature.asc Description: Digital signature
Re: Packaging a new release of released SW, not considered by the DM?
Svante Signell dijo [Thu, May 31, 2012 at 11:45:13PM +0200]: > > It's *usually* not what you want to do. There are several cases where > > different versions of the same program are available in Debian, and I > > am unfamiliar with the case at hand, but it's usually where a specific > > older version of a package is depended upon by large amounts of > > software, and changes in new versions are not compatible. They often > > bring in maintenance hell issues. > > > > In this case, you should discuss with the DM about the "whatever > > reason" you mention, maybe bring it up here (so it gets wider exposure > > and more informed people get to have a say). You can ultimately ask > > the Technical Committee, but that's a venue of action very seldom > > taken (and I think that even "very seldom" might be an overstatement). > > Thank you for your time, > > Fortunately, I'm not a hurd porter any longer an whatever you choose to > do it is not longer my business. Thank you for your attention Huh‽ Well, the original question I replied to was posted by you... I fail to understand your answer. There was no mention of any specific program, architecture, kernel or whatever. -- 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/20120531224002.gf21...@gwolf.org
Re: Packaging a new release of released SW, not considered by the DM?
On Thu, 2012-05-31 at 16:20 -0500, Gunnar Wolf wrote: > Svante Signell dijo [Thu, May 31, 2012 at 10:22:21PM +0200]: > > Hi, > > > > A Short question. Is it possible to ITP a new release of some software > > not being even considered by the DM, for whatever reason. Wishlist bugs > > are submitted, etc. According to if there is no reply of bug reports, > > there seems to be no interest at all from the DM to package that piece > > of SW, not even for experimental. If not possible, why? What does the > > Debian Policy state? > > It's *usually* not what you want to do. There are several cases where > different versions of the same program are available in Debian, and I > am unfamiliar with the case at hand, but it's usually where a specific > older version of a package is depended upon by large amounts of > software, and changes in new versions are not compatible. They often > bring in maintenance hell issues. > > In this case, you should discuss with the DM about the "whatever > reason" you mention, maybe bring it up here (so it gets wider exposure > and more informed people get to have a say). You can ultimately ask > the Technical Committee, but that's a venue of action very seldom > taken (and I think that even "very seldom" might be an overstatement). Thank you for your time, Fortunately, I'm not a hurd porter any longer an whatever you choose to do it is not longer my business. Thank you for your attention -- 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/1338500713.5450.122.ca...@hp.my.own.domain
Re: Packaging a new release of released SW, not considered by the DM?
Svante Signell dijo [Thu, May 31, 2012 at 10:22:21PM +0200]: > Hi, > > A Short question. Is it possible to ITP a new release of some software > not being even considered by the DM, for whatever reason. Wishlist bugs > are submitted, etc. According to if there is no reply of bug reports, > there seems to be no interest at all from the DM to package that piece > of SW, not even for experimental. If not possible, why? What does the > Debian Policy state? It's *usually* not what you want to do. There are several cases where different versions of the same program are available in Debian, and I am unfamiliar with the case at hand, but it's usually where a specific older version of a package is depended upon by large amounts of software, and changes in new versions are not compatible. They often bring in maintenance hell issues. In this case, you should discuss with the DM about the "whatever reason" you mention, maybe bring it up here (so it gets wider exposure and more informed people get to have a say). You can ultimately ask the Technical Committee, but that's a venue of action very seldom taken (and I think that even "very seldom" might be an overstatement). -- 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/20120531212027.ge21...@gwolf.org
Re: May be ITP: mime-support-extra to close #658139 (Was: Breaking programs because a not yet implemented solution exists in theory)
On 31.05.2012 21:35, Andreas Tille wrote: > In any case the idea is to collect issues of broken mime support where > maintainers are unable / not willing to respect Debian policy 9.7. > Adding more entries is simple: Just add the according mime file as > .mime and add to "Enhances" in debian/control. I don't think adding such a package is a good idea. It's just an ugly work-around. In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779 there is already a patch by brian m. carlson. Any effort regarding this issue should be spent getting this patch ready and applied to mime-support. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Packaging a new release of released SW, not considered by the DM?
Svante Signell, le Thu 31 May 2012 22:22:21 +0200, a écrit : > A Short question. Is it possible to ITP a new release of some software > not being even considered by the DM, for whatever reason. It's normally not a good thing to do. "ITP" is also not what you mean here, BTW. > Wishlist bugs are submitted, etc. And they are just wishes. The maintainer may prefer to avoid using the newer upstream, for whatever reason. > According to if there is no reply of bug reports, > there seems to be no interest at all from the DM to package that piece > of SW, not even for experimental. No, that does not necessarily mean that. It may also mean that he does not have the time to work on it. Packaging a newer version is not always trivial. > If not possible, why? What does the Debian Policy state? Actually it's not in the debian policy (which is about packages themselves, not maintainer relationships), but in the developer's reference, chapter "5.11. Non-Maintainer Uploads (NMUs)". Please read it carefully, and rather use debian-mentors for such kind of questions. Samuel -- 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/20120531202635.ga4...@type.famille.thibault.fr
Packaging a new release of released SW, not considered by the DM?
Hi, A Short question. Is it possible to ITP a new release of some software not being even considered by the DM, for whatever reason. Wishlist bugs are submitted, etc. According to if there is no reply of bug reports, there seems to be no interest at all from the DM to package that piece of SW, not even for experimental. If not possible, why? What does the Debian Policy state? -- 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/1338495741.5450.114.ca...@hp.my.own.domain
Bug#675395: ITP: libappindicator -- allow applications to export a menu into the panel
Package: wnpp Severity: wishlist Owner: The Ayatana Packagers * Package name: libappindicator Version : 0.4.92 Upstream Author : Ted Gould * URL : https://launchpad.net/libappindicator * License : GPL-3, LGPL-2.1 Programming Lang: C Description : allow applications to export a menu into the panel A library to allow applications to export a menu into the panel. Based on KSNI it also works in KDE and will fallback to generic Systray support if none of those are available. -- 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/20120531200302.9861.60140.reportbug@nana
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi Thomas, On Thu, May 31, 2012 at 02:01:51PM +0800, Thomas Goirand wrote: > On 05/31/2012 09:03 AM, Steve Langasek wrote: > > A hijack is, by definition, a declaration by the hijacker that they > > believe they are not answerable to the project's processes for how > > package maintenance is decided. It is antisocial vigilanteism and it is > > not acceptable. > Why are people talking about urgency and hijack? None applies to this > package. > Please refer to the title of this thread, where I wrote: > Orphaning *THEN* take over > Is there anything wrong with that? Your original mail also said: > So, if nobody objects within the next following 2 or 3 days, and if Jack > doesn't show up and oppose to this procedure, we'll do that. "2 or 3 days" *does* imply urgency, and this is the part of your original proposal that I object to. The rest of my objections are directed not at you, but at those who are attempting to legitimize "hijacking" in this thread. > In fact, it's the total opposite way, I asked others if they found it ok to > ask for the package to be orphaned after only a week, because I thought that > 4 years without a refresh of the package, multiple NMUs of other packages > from the same maintainer, was enough to shorten the "ping period". I also > wrote about my intention to get the original maintainer in the team if he > wishes so. Then considering Jonas opinion, I agreed to leave one week more, > even if I know that the orphaning process may take some time as well. > Is this hijack? Is this rushing? I don't think it's a hijack. I do think it's rushing. I recognize that there's a cost to having to set a mental alarm for tracking issues like this, but if we haven't already made a determination that the maintainer is MIA, then it takes some time to do this appropriately. We shouldn't simply assume that NMUs and unanswered low-priority bugs mean the package is up for grabs - particularly as we *want* NMUs, we don't want maintainers to feel they need to do no-changes reuploads just to confirm NMUs, and we don't want maintainers to have their packages taken away from them as a result of them doing the right thing wrt NMUs. On Fri, Jun 01, 2012 at 02:29:29AM +0800, Thomas Goirand wrote: > On 05/31/2012 10:52 PM, Mehdi Dogguy wrote: > > Please note that "badly maintained" is something quite different from > > "not maintained". AFAICS, the package we are talking about is not > > affected by severe or critical bugs. > That's a mater of views. #470294 should be made RC IMO. > Or is writing to /usr not a good candidate for an RC bug? > I thought this was a "serious violation of the policy". Am I wrong? I think marking this 'serious' is appropriate, but given that it *wasn't* marked 'serious' until today, this also does not justify an expedited orphaning. It's not reasonable to claim the maintainer was failing to act on a RC bug when no one had bothered to inform the maintainer (who is not a DD, and therefore may not have understood) that it was an RC bug. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
May be ITP: mime-support-extra to close #658139 (Was: Breaking programs because a not yet implemented solution exists in theory)
Hi, On Wed, May 02, 2012 at 03:16:08PM +0100, Ben Hutchings wrote: > I'm also not seeing GNOME applications as file type handlers in > Akregator (KDE application). So I'm not sure this is even 'just' a > problem for text-mode applications. I have no idea whether the solution proposed below could help here: I just injected svn://svn.debian.org/collab-maint/deb-maint/mime-support-extra which would bring back mime support for evince for all applications I'm using. (I was too bored to always update a local evince package which works.) It is *very* simple and does not implement all those nifty suggestions given here but not yet implemented. I see two options to go from here: 1. I just keep this package as a private solution. 2. I upload the package to unstable by a) issuing a new ITP b) turning #658139 into ITP: mime-support-extra I have no idea what makes the best sense and whether ftpmaster would accept such a package (I'm not even sure whether I in the position of ftpmaster would accept this). I'd regard it as a too simple but helpful workaround for a problem which should be solved differently. In any case the idea is to collect issues of broken mime support where maintainers are unable / not willing to respect Debian policy 9.7. Adding more entries is simple: Just add the according mime file as .mime and add to "Enhances" in debian/control. What do you think? Kind regards Andreas. -- http://fam-tille.de -- 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/20120531193505.gr27...@an3as.eu
pre-MIA quest for Patrick Winnertz (winnie-at-d.o)
Dear all, I have been trying to contact Patrick Winnertz (winnie-at-d.o). I would like to see iTalc in Debian upgraded to 2.0 but Patrick is neither replying to contact attempts via mail (Debian Edu mailing list, directly), nor to contact attempts via IRC. My first attempt to reach him is about 3-4 weeks ago. Earlier this year Patrick handed over the maintenance of slbackup / slbackup-php to me. This last contact was via IRC. Has anyone heard from him, recently? If so, can you give him note to get in contact with me (or the Debian Edu team)? If I do not hear from anyone on debian-devel@l.d.o within a week, I will contact the MIA team and request orphanage of italc. Thanks for your help, Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp45CbVowqEe.pgp Description: Digitale PGP-Unterschrift
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
severity 470294 serious thanks Hi, On Donnerstag, 31. Mai 2012, Thomas Goirand wrote: > That's a mater of views. #470294 should be made RC IMO. "somebody should do something" ;-) > Or is writing to /usr not a good candidate for an RC bug? > I thought this was a "serious violation of the policy". Am I wrong? No, that's a serious issue indeed. cheers, Holger, who is a happy+frequent BTS _user_ :-D -- 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/201205312038.03029.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 10:52 PM, Mehdi Dogguy wrote: > Please note that "badly maintained" is something quite different from > "not maintained". AFAICS, the package we are talking about is not > affected by severe or critical bugs. That's a mater of views. #470294 should be made RC IMO. Or is writing to /usr not a good candidate for an RC bug? I thought this was a "serious violation of the policy". Am I wrong? Cheers, Thomas -- 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/4fc7b889.3000...@debian.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 04:52 PM, Mehdi Dogguy wrote: > On 31/05/12 16:40, Thomas Goirand wrote: >> On 05/31/2012 08:43 PM, Jonas Smedegaard wrote: >>> I have no intention of spreading or amplifying wrong information. >>> >>> Do I understand it correctly that your intention in your original >>> post was to have the package orphaned and then have a team take >>> over maintainance? >>> >> >> I was also pointing out that the package was anyway badly maintained, >> and that in such case, we have to do something about it. >> > > Please note that "badly maintained" is something quite different from > "not maintained". AFAICS, the package we are talking about is not > affected by severe or critical bugs. The number of bugs says nothing about a package being maintained or not. Maybe just nobody uses it anymore because it is too old? 'Please package the current upstream version'-bugs are wishlist only, unfortunately. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc7a889.1090...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 06:25 PM, Mehdi Dogguy wrote: > On 31/05/12 18:15, Bernd Zeimetz wrote: >> >> Part of the common and established procedure is to mail d-devel if >> you intend to hijack a package > > True, but it is _not_ common (nor acceptable) to let only 2-3 days for > the maintainer to reply. They waited 5 days and want to wait 2-3 more days. That makes 8 days, a short time but waiting a bt longer would be easy, I guess. > The rest of the thread raised other questions such as the responsibility > of a sponsor, but it seems OT wrt. the original request. > > Regards, > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc7a23f.7000...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Jonas Smedegaard dijo [Thu, May 31, 2012 at 05:52:47PM +0200]: > > > You avoided my question, it seems: What does "Maintainer:" mean, then? > > > > What does "Uploaders:" field mean? > > You still avoid my question: What does "Maintainer:" mean? This is getting silly. Please stop the word-definitions game. Jonas, I think we all agree that the Maintainer should Maintain whatever he signed up to. Non-Debian people have the right to maintain packages through a sponsor, and they are encouraged to. And they are encouraged to look for a different sponsor if their current one stops being responsive, and all that. However, we cannot expect them to remain active and interested forever. I can expect you (as a person I've known for many years already) to remain active and look after your packages. But we cannot expect the same from a person not involved in Debian any further than in having maintained a couple of packages for a couple of months. Taking over a package from you should be quite a different thing than taking it over from a person not involved in the project. -- 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/20120531163116.ga21...@gwolf.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 31/05/12 18:15, Bernd Zeimetz wrote: Part of the common and established procedure is to mail d-devel if you intend to hijack a package True, but it is _not_ common (nor acceptable) to let only 2-3 days for the maintainer to reply. The rest of the thread raised other questions such as the responsibility of a sponsor, but it seems OT wrt. the original request. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fc79b62.2000...@dogguy.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 04:57 PM, Mehdi Dogguy wrote: > On 31/05/12 15:11, Bernd Zeimetz wrote: >> On 05/31/2012 03:03 AM, Steve Langasek wrote: >>> [...] >> >>> A hijack is, by definition, a declaration by the hijacker that >>> they believe they are not answerable to the project's processes for >>> how package maintenance is decided. It is antisocial vigilanteism >>> and it is not acceptable. >> >> So asking people who want to work actively on a package to wait for >> months or years because it is not compltely clear if the original >> maintainer is MIA or not, or just nobody had the time to look at the >> MIA status, is social? It does not help Debian at all. >> >>> As a sitting member of the Technical Committee, I encourage anyone >>> who sees a package being hijacked to immediately bring it to the >>> attention of the TC. I will without hesitation vote to have the >>> hijacker barred from being made the maintainer of the package. >> >>> From a member of the TC I would expect some useful input on how to >>> fix >> an obviously broken (since years!) process instead of trying to >> forcibly trying to choke down people who actively want to improve >> Debian. Welcome to the dictatorship of the TC. >> > > I think what Steve wanted to say is that we have procedures for theses > situations and we should follow those procedures because they exist and > we have concensus. The procedures in question might not be perfect or > completely disfunctional but that is another topic. > > You may very well try to change these procedures and discuss new rules > or the needed changes to apply on -devel, but you should not ignore them > and force your own (which was, aiui, what the original submitter of this > thread wanted to do) just because $foo. Part of the common and established procedure is to mail d-devel if you intend to hijack a package. Please have a look into the archives of this mailinglist, searching for intend to hijack debian-devel@lists.debian.org site:lists.debian.org gives a lot of results, including some dating back to 2006. If I remember right this includes at least one or two messages from me, which did not receive negative replies at all. So I completely fail why the original submitter's mail is *that* bad (your $foo in this case being the maintainer MIA for 3 years), and I also fail to understand why it needs a major flamewar. It is common practise for years to discuss hijacks in such cases (original maintainer MIA for years, or even worse, maintainer lacking the necessarz skill to maintain important packages) on this list and hijack them if there is consensus about doing so. Especially do I fail to understand why a member of the TC, who took part in such discussions before (https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an example), and encouraged people to do so (that is how I understand the mentioned mail), is now on a killing spree. All he is doing is to encourage people to give up their idea to improve Debian. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc79933.7080...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi Thomas, On Donnerstag, 31. Mai 2012, Thomas Goirand wrote: > I was asking if it was alright to ask the MIA team to orphan the > package, yes, because no reply from Jack. Never I wanted to do > it myself, or take over the package without going through the > standard procedures. yes, please do that. Ask the MIA team to orphan it and then adopt it. That would be awesome. cheer, Holger -- 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/201205311810.47816.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Donnerstag, 31. Mai 2012, Jonas Smedegaard wrote: > You still avoid my question: What does "Maintainer:" mean? why do you ask rhetoric questions? It's defined in policy and you know it. So whats the point? -- 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/201205311808.55306.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 04:43pm, George Danchev wrote: > On Thursday 31 May 2012 16:15:31 Jonas Smedegaard wrote: > > [dropping PHP Pear team as cc] > > > > On 12-05-31 at 03:16pm, George Danchev wrote: > > > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > > > > You and a lot of others fail to realize that the *SPONSOR* is > > > > > responsible for the package. > > > > > > > > Huh?!? > > > > > > > > What does "Maintainer:" mean if not the entity being responsible > > > > for, well, maintaining?!? > > > > > > Who is responsible for the package maintenance in the case where a > > > non-DD is listed in "Maintainer:", and the package is obviosuly signed > > > and uploaded (effectively sponsored) by a DD? I guess it is perfectly > > > reasonable to expect that DD, being in the role of sponsor, is > > > responsible for the package quality and further maintenance. Sponsors > > > are full-fledged DDs, and trying to claim that they are not > > > responsible, or are somehow less responsible than any other > > > non-sponsoring DDs, for the uploads they have done, is obviously plain > > > wrong. > > > > You avoided my question, it seems: What does "Maintainer:" mean, then? > > What does "Uploaders:" field mean? You still avoid my question: What does "Maintainer:" mean? - 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: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 31/05/12 15:11, Bernd Zeimetz wrote: On 05/31/2012 03:03 AM, Steve Langasek wrote: [...] A hijack is, by definition, a declaration by the hijacker that they believe they are not answerable to the project's processes for how package maintenance is decided. It is antisocial vigilanteism and it is not acceptable. So asking people who want to work actively on a package to wait for months or years because it is not compltely clear if the original maintainer is MIA or not, or just nobody had the time to look at the MIA status, is social? It does not help Debian at all. As a sitting member of the Technical Committee, I encourage anyone who sees a package being hijacked to immediately bring it to the attention of the TC. I will without hesitation vote to have the hijacker barred from being made the maintainer of the package. From a member of the TC I would expect some useful input on how to fix an obviously broken (since years!) process instead of trying to forcibly trying to choke down people who actively want to improve Debian. Welcome to the dictatorship of the TC. I think what Steve wanted to say is that we have procedures for theses situations and we should follow those procedures because they exist and we have concensus. The procedures in question might not be perfect or completely disfunctional but that is another topic. You may very well try to change these procedures and discuss new rules or the needed changes to apply on -devel, but you should not ignore them and force your own (which was, aiui, what the original submitter of this thread wanted to do) just because $foo. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fc786e9.6020...@dogguy.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday, May 31, 2012 03:16:06 PM George Danchev wrote: > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > Hi, > > > > You and a lot of others fail to realize that the *SPONSOR* is > > > responsible for the package. > > > > Huh?!? > > > > What does "Maintainer:" mean if not the entity being responsible for, > > well, maintaining?!? > > Who is responsible for the package maintenance in the case where a non-DD is > listed in "Maintainer:", and the package is obviosuly signed and uploaded > (effectively sponsored) by a DD? I guess it is perfectly reasonable to > expect that DD, being in the role of sponsor, is responsible for the > package quality and further maintenance. Sponsors are full-fledged DDs, and > trying to claim that they are not responsible, or are somehow less > responsible than any other non-sponsoring DDs, for the uploads they have > done, is obviously plain wrong. > > > If the maintainer fails to keep the package in a useful shape it is > > > the sponsor's responsibility to do so. And last but not least it > > > should be the sponsor's decision to orphan a package if the maintainer > > > is MIA or not doing his job properly. It is also the sponsors > > > responsibility to try to figure out if a maintainer is willing to do > > > his job longer than one upload before sponsoring a package at all. > > > > I have heard before the argument of the sponsor having responsibility, > > but in reality I have *never* heard of sponsors actually being held > > responsible for anything but the concrete upload of a specific packaging > > release. > > > > ...which leads to my concern for high risk of drive-by contributions! > > ...hence the Sponsors (who are also a full-fledged DDs) are responsible. It > is that simple. If it's really that simple, one should never sponsor a package one doesn't care to maintain. If this is the case, we should just do away with sponsorship and require the uploader to be either Maintainer or in Uploaders unless it's an NMU (note: I don't think this is what we want). Scott K -- 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/1888095.EXhfyjLExP@scott-latitude-e6320
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 31/05/12 16:40, Thomas Goirand wrote: On 05/31/2012 08:43 PM, Jonas Smedegaard wrote: I have no intention of spreading or amplifying wrong information. Do I understand it correctly that your intention in your original post was to have the package orphaned and then have a team take over maintainance? I was also pointing out that the package was anyway badly maintained, and that in such case, we have to do something about it. Please note that "badly maintained" is something quite different from "not maintained". AFAICS, the package we are talking about is not affected by severe or critical bugs. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fc785ae.40...@dogguy.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday 31 May 2012 16:15:31 Jonas Smedegaard wrote: > [dropping PHP Pear team as cc] > > On 12-05-31 at 03:16pm, George Danchev wrote: > > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > > > You and a lot of others fail to realize that the *SPONSOR* is > > > > responsible for the package. > > > > > > Huh?!? > > > > > > What does "Maintainer:" mean if not the entity being responsible > > > for, well, maintaining?!? > > > > Who is responsible for the package maintenance in the case where a > > non-DD is listed in "Maintainer:", and the package is obviosuly signed > > and uploaded (effectively sponsored) by a DD? I guess it is perfectly > > reasonable to expect that DD, being in the role of sponsor, is > > responsible for the package quality and further maintenance. Sponsors > > are full-fledged DDs, and trying to claim that they are not > > responsible, or are somehow less responsible than any other > > non-sponsoring DDs, for the uploads they have done, is obviously plain > > wrong. > > You avoided my question, it seems: What does "Maintainer:" mean, then? What does "Uploaders:" field mean? > Seems to me that for sponsored packages the Maintainer field is a joke! The gpg signature applied to the upload is not a joke, at all. > Seems to me that for sponsored packages we need access to ftp logfiles > to resolve who is responsible for maintaining the package. Then, please, allow me to introduce you to the 'who-uploads' utility. > I find both of those plain wrong. Possibly obviously and maybe even > hilariously simple, but wrong nonetheless. Nothing is wrong with the control fields and the gpg signatures applied to the uploads actually. -- pub 4096R/0E4BD0AB -- 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/201205311643.08151.danc...@spnet.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 08:43 PM, Jonas Smedegaard wrote: > I have no intention of spreading or amplifying wrong information. > > Do I understand it correctly that your intention in your original > post was to have the package orphaned and then have a team take over > maintainance? > I was also pointing out that the package was anyway badly maintained, and that in such case, we have to do something about it. There are things that I omitted, because I thought that it wasn't necessary. For example the fact that Jack Bates didn't reply to #599617 (bug opened on the 9, Oct, 2010), #634825 (bug opened on the 20, Jul 2011), and #470294 (opened on the 11, Mar 2008) shows how little care... My goal was to ask if it was ok to start the MIA procedure after a week only, and not wait a full month, because it seemed obvious that the original maintainer was MIA. The more the time passes, the more I think I was right, because Jack Bates continues to be MIA. I still hope I'm proven wrong though, and that our Jack friend will wake up, but there's not much chance anymore that this happens... I don't call this a will to hijack a package, but asking for advices on how to the situation of this unmaintained package. > Do I understand correctly that your intention in your original post was > (after having tried to reach the maintainer for 5 days and having > noticed that others have tried for several years) to have the orphaning > occur without the consent of the maintainer? > I was asking if it was alright to ask the MIA team to orphan the package, yes, because no reply from Jack. Never I wanted to do it myself, or take over the package without going through the standard procedures. I also think that even if the original maintainer replies now, he's not fit for the job (not enough reactivity, not enough maintenance of his package), and that if he feels like willing to continue contributing to Debian with this package, then the best option is to join the PKG PHP PEAR team, and collectively maintain the package. Note that there's really enough work on the PEAR packaging so that other member can join. Have a look here: http://qa.debian.org/developer.php?login=pkg-php-p...@lists.alioth.debian.org There's 45 packages. Out of them, I was the one who uploaded them all lately, apart from 4 of them: php-crypt-blowfish, php-net-dnsbl, php-text-wiki, php-xml-rpc and php-net-seive. That's 40 packages that I've been working on before the freeze (some of, phpunit related, with the help of Luis)! Yes, they are easy to maintain, but somebody has to do the job still. We've also added phpunit to the archive and I've added unit tests at build time for 9 of these packages to make sure that no mistake is introduced, and that they are functionally working. That's by the way one of the addition I would have liked to add to this package: running the 210 unit tests that it has... I believe I have made a good job maintaining all of these PEAR packages (but I am of course open to critics and improvements). I also believe that I deserves the right to be critic of other PEAR packaging when I see issues, after all this time I invested keeping all of these up-to-date and in good shape. php-codesniffer is a tool to make sure that PEAR packages are using the coding standards. It's one tool that will help increasing the overall quality of all of these PEAR packages as well, just like PHPUnit does. It makes me sad to see it the way it is in Debian, and I wanted to fix this. Now, you are calling this a "hijack" ... It really doesn't feel right on my side to read such wording. :( Gosh, do I really need to write all this to explain myself? This is a horrible waste of time Jonas... Thomas -- 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/4fc782eb.2090...@debian.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday 31 May 2012 14:43:00 Jonas Smedegaard wrote: > On 12-05-31 at 08:02pm, Thomas Goirand wrote: > > On 05/31/2012 04:36 PM, Jonas Smedegaard wrote: > > > Hijacking, in my vocabulary, is when a non-maintainer takes matters > > > in his/her/their own hands and takes over maintainership without the > > > consent of the former maintainer and outside formal Debian > > > procedures. > > > > Nobody did that, or had the intention to do this here. > > > > I already asked you privately: please stop spreading wrong information > > about my intentions. This begins to be really annoying. > > I have no intention of spreading or amplifying wrong information. > > Do I understand it correctly that your intention in your original > post was to have the package orphaned and then have a team take over > maintainance? > > Do I understand correctly that your intention in your original post was > (after having tried to reach the maintainer for 5 days and having > noticed that others have tried for several years) to have the orphaning > occur without the consent of the maintainer? Or you should better understand that "maintainer is always there to provide consent" is also a blatant assumption, and that some sort of fault-tolerance is actually needed in the real life, at least in my parallel reality. Sometimes it is impossible to reach the maintainer for a very long period of time, due to several even prosaic reasons, hence something or someone should be able to unblock the hard blockage in a reasonable amount of time. Maintaining the package in between for a very long amount of time (like years), by very long series of minimal, non-invasive NMUs, which would also imply no new upstream versions or newly created packaging tools, seems quite suboptimal to me. Thus orphan + adopt is perfectly in order. -- pub 4096R/0E4BD0AB -- 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/201205311635.33008.danc...@spnet.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
[dropping PHP Pear team as cc] On 12-05-31 at 03:16pm, George Danchev wrote: > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > > You and a lot of others fail to realize that the *SPONSOR* is > > > responsible for the package. > > > > Huh?!? > > > > What does "Maintainer:" mean if not the entity being responsible > > for, well, maintaining?!? > > Who is responsible for the package maintenance in the case where a > non-DD is listed in "Maintainer:", and the package is obviosuly signed > and uploaded (effectively sponsored) by a DD? I guess it is perfectly > reasonable to expect that DD, being in the role of sponsor, is > responsible for the package quality and further maintenance. Sponsors > are full-fledged DDs, and trying to claim that they are not > responsible, or are somehow less responsible than any other > non-sponsoring DDs, for the uploads they have done, is obviously plain > wrong. You avoided my question, it seems: What does "Maintainer:" mean, then? Seems to me that for sponsored packages the Maintainer field is a joke! Seems to me that for sponsored packages we need access to ftp logfiles to resolve who is responsible for maintaining the package. I find both of those plain wrong. Possibly obviously and maybe even hilariously simple, but wrong nonetheless. - Jonas Who appreciate non-DM contributions, just not common hinting of them -- * 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: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: Hi, > > You and a lot of others fail to realize that the *SPONSOR* is > > responsible for the package. > > Huh?!? > > What does "Maintainer:" mean if not the entity being responsible for, > well, maintaining?!? Who is responsible for the package maintenance in the case where a non-DD is listed in "Maintainer:", and the package is obviosuly signed and uploaded (effectively sponsored) by a DD? I guess it is perfectly reasonable to expect that DD, being in the role of sponsor, is responsible for the package quality and further maintenance. Sponsors are full-fledged DDs, and trying to claim that they are not responsible, or are somehow less responsible than any other non-sponsoring DDs, for the uploads they have done, is obviously plain wrong. > > If the maintainer fails to keep the package in a useful shape it is > > the sponsor's responsibility to do so. And last but not least it > > should be the sponsor's decision to orphan a package if the maintainer > > is MIA or not doing his job properly. It is also the sponsors > > responsibility to try to figure out if a maintainer is willing to do > > his job longer than one upload before sponsoring a package at all. > > I have heard before the argument of the sponsor having responsibility, > but in reality I have *never* heard of sponsors actually being held > responsible for anything but the concrete upload of a specific packaging > release. > > ...which leads to my concern for high risk of drive-by contributions! ...hence the Sponsors (who are also a full-fledged DDs) are responsible. It is that simple. -- pub 4096R/0E4BD0AB -- 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/201205311516.06495.danc...@spnet.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 03:03 AM, Steve Langasek wrote: >[...] > A hijack is, by definition, a declaration by the hijacker that they believe > they are not answerable to the project's processes for how package > maintenance is decided. It is antisocial vigilanteism and it is not > acceptable. So asking people who want to work actively on a package to wait for months or years because it is not compltely clear if the original maintainer is MIA or not, or just nobody had the time to look at the MIA status, is social? It does not help Debian at all. > As a sitting member of the Technical Committee, I encourage anyone who sees > a package being hijacked to immediately bring it to the attention of the TC. > I will without hesitation vote to have the hijacker barred from being made > the maintainer of the package. >From a member of the TC I would expect some useful input on how to fix an obviously broken (since years!) process instead of trying to forcibly trying to choke down people who actively want to improve Debian. Welcome to the dictatorship of the TC. > [...] -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc76df2.7010...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 08:02pm, Thomas Goirand wrote: > On 05/31/2012 04:36 PM, Jonas Smedegaard wrote: > > Hijacking, in my vocabulary, is when a non-maintainer takes matters > > in his/her/their own hands and takes over maintainership without the > > consent of the former maintainer and outside formal Debian > > procedures. > > > Nobody did that, or had the intention to do this here. > > I already asked you privately: please stop spreading wrong information > about my intentions. This begins to be really annoying. I have no intention of spreading or amplifying wrong information. Do I understand it correctly that your intention in your original post was to have the package orphaned and then have a team take over maintainance? Do I understand correctly that your intention in your original post was (after having tried to reach the maintainer for 5 days and having noticed that others have tried for several years) to have the orphaning occur without the consent of the maintainer? - 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: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Steve Langasek writes ("Re: Orphaning php-codesniffer, then take it over by the
PHP PEAR team"):
> A hijack is, by definition, a declaration by the hijacker that they believe
> they are not answerable to the project's processes for how package
> maintenance is decided. It is antisocial vigilanteism and it is not
> acceptable.
Our processes for how package maintenance is decided are utterly
dysfunctional.
If the TC had _ever_ voted to remove a maintainer who wanted to keep
hold of a package, it might be at least reasonably possible to argue
that the TC was the right forum for these disputes.
> As a sitting member of the Technical Committee, I encourage anyone who sees
> a package being hijacked to immediately bring it to the attention of the TC.
> I will without hesitation vote to have the hijacker barred from being made
> the maintainer of the package.
Instead of this kind of aggressive approach to those who are IMO quite
reasonably working around our dysfunctional formal processes, how
about working towards fixing those dysfunctional processes ?
I await with interest your suggestions for revising the way the TC
deals with problematic maintainers. I have been arguing for years
that we need a much more robust approach.
Ian.
--
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/20423.24363.396379.966...@chiark.greenend.org.uk
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 04:36 PM, Jonas Smedegaard wrote: > Hijacking, in my vocabulary, is when a non-maintainer takes matters in > his/her/their own hands and takes over maintainership without the > consent of the former maintainer and outside formal Debian procedures. > Nobody did that, or had the intention to do this here. I already asked you privately: please stop spreading wrong information about my intentions. This begins to be really annoying. Thomas -- 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/4fc75dcf.8060...@debian.org
Re: Moving /tmp to tmpfs makes it useful
On Thu, May 31, 2012 at 12:46:49AM +0300, Uoti Urpala wrote: Also, nowadays normal filesystems are journaled; using a journal for writes to /tmp damages the SSD for zero benefit. Writing to /tmp will damage a SSD? Are you serious? And writing to /var or /home will not? If SSDs are so easy damageable, that you should never use them for e.g. development because it creates to much write cycles, then they have a serious problem. (Thinking about the firmware bugs with data loss I will stay away from them anyway.) I think no one is saying that tmpfs is always bad and never should be used. But for a default installation /tmp belongs to a disk which will be far bigger than the memory. If a user thinks tmpfs will get him an advantage in his setup, then he can switch. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Donnerstag, 31. Mai 2012, Cyril Brulebois wrote: > [ Holger, that's fingerpointing. Pointing to how you quickly dealt with > those packages, thanks again. :-) ] /me happily fingerpoints back at the release team and esp. KiBi, who greatly deal with trying to get 1 packages and 1000 people in sync. Thanks a huge lot for all your work! :-) -- 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/201205311213.46790.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi Enrico, On 12-05-31 at 09:19am, Enrico Zini wrote: > On Thu, May 31, 2012 at 02:01:51PM +0800, Thomas Goirand wrote: > > > Did you see me writing "I'd like to hijack php-codesniffer in order > > to rush and get it into wheezy in time before the freeze"? *NO* ! I > > didn't write that. > > Agreed. I'd have expected people, if anything, to answer suggesting > the correct procedure to get things done in this case. I was surprised > to see replies harshly escalating matters this way. > > My understanding is that we have a package that looks unmaintained for > 4 years. Yelling at those who volunteer to do some work on it, instead > of guiding them to do it in the best way, seems silly and rather > un-debianish to me. Rephrasing orphaning without maintainer consent + takeover as hijacking is yelling? Suggesting to do an NMU instead of hijacking is un-debianish? - Jonas Who agrees the package is in bad shape, but dislikes hijacking. -- * 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: Digital signature
Bug#675327: marked as done (general: Adobe acrobat reader problem)
Your message dated Thu, 31 May 2012 11:56:44 +0200 with message-id <201205311156.45092.hol...@layer-acht.org> and subject line Re: Bug#675327: general: Adobe acrobat reader problem has caused the Debian Bug report #675327, regarding general: Adobe acrobat reader problem 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.) -- 675327: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675327 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: normal Every time I do updates or install a package via synaptics, adobe acrobat reader is no longer on the menu, it should be listed always in the office menu. -- System Information: Debian Release: 6.0.5 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- Hi, On Donnerstag, 31. Mai 2012, Otto Wedel Scriba wrote: > Every time I do updates or install a package via synaptics, adobe acrobat > reader is no longer on the menu, it should be listed always in the office > menu. I'm sorry to hear this, but acroread is not part of Debian, thus closing. cheers, Holger --- End Message ---
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Jonas Smedegaard (31/05/2012): > I have heard before the argument of the sponsor having responsibility, > but in reality I have *never* heard of sponsors actually being held > responsible for anything but the concrete upload of a specific > packaging release. Suggested reading: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=37;bug=672117 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=59;bug=672117 The sponsor did almost all the needed work to reduce entropy (see the thread to see how many packages got delayed/entangled/prevented from migrating because of the initial upload). [ Holger, that's fingerpointing. Pointing to how you quickly dealt with those packages, thanks again. :-) ] Mraw, KiBi. signature.asc Description: Digital signature
Bug#675327: general: Adobe acrobat reader problem
Package: general Severity: normal Every time I do updates or install a package via synaptics, adobe acrobat reader is no longer on the menu, it should be listed always in the office menu. -- System Information: Debian Release: 6.0.5 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120531090124.8613.63207.report...@debian.cpe.cabletica.com
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 09:22am, Bernd Zeimetz wrote: > On 05/30/2012 11:11 AM, Jonas Smedegaard wrote: > It is better to have a well maintained package than to ait for > somebody who collected a number of NMUs and doesn't react to bug > reports for years. I perfectly agree. But it is better to have responsibly maintained packages having newest upstream code packaged at any cost. ...and I find both of our comparisons above too simplistic! On 12-05-31 at 09:22am, Bernd Zeimetz wrote: > On 05/30/2012 11:11 AM, Jonas Smedegaard wrote: > > I am not at all surprised that this is yet another sponsored package > > bit-rotting. Personally I never liked how we allow maintainer to be > > someone not in Debian: There is too great a risk of drive-by > > contributions :-( > > You and a lot of others fail to realize that the *SPONSOR* is > responsible for the package. Huh?!? What does "Maintainer:" mean if not the entity being responsible for, well, maintaining?!? > If the maintainer fails to keep the package in a useful shape it is > the sponsor's responsibility to do so. And last but not least it > should be the sponsor's decision to orphan a package if the maintainer > is MIA or not doing his job properly. It is also the sponsors > responsibility to try to figure out if a maintainer is willing to do > his job longer than one upload before sponsoring a package at all. I have heard before the argument of the sponsor having responsibility, but in reality I have *never* heard of sponsors actually being held responsible for anything but the concrete upload of a specific packaging release. ...which leads to my concern for high risk of drive-by contributions! > > ...but we should not improve quality of packages by relaxing the > > respect of the maintainer. We should hold maintainers responsible to > > their actions - and that is only really possible to do with "social > > pride" which is lacking when maintainer is outside of Debian. > > Yet another job for the sponsor. How can sponsor help create social pride (or social pressure if doing a lousy job)? - 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: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 10:06am, Andreas Tille wrote: > On Wed, May 30, 2012 at 06:03:05PM -0700, Steve Langasek wrote: > > There is no excuse for hijacking a package, ever. > > ... > > Hmm, this arguing sounds quite German to me. Rules are rules are > rules and you should not disregard them. So a German will wait in > front of a red traffic light even if there is no visible sign of any > car and no sound that might give some signal for any traffic. When I > was abroad I enjoyed the habit of other nations just to know when > breaking a rule makes perfectly sense. I also think that some common > sense could be applied in very obvious cases and this discussion shows > that several respected people do agree that there are cases like this > where there actually is an excuse for hijacking a package. I am danish, not german, and I wait at traffic lights, also at night. ...or sometimes I do. Pretty often I cross at red light, but am then prefectly aware that I break the rules, and I take eventual punishment for that [with a smile]. You can have _reasons_ for hijacking, but no reason is an excuse: It is never ok to hijack. Hijack is takeover without either explicit approval or community consensus. Following a community approved procedure for takeover without the explicit consent of the former maintainer it is not hijacking. Are we both talking about same meaning of "hijacking" and "excuse"? - Jonas [with a smile]: I also break the rules when abroad, and have fould that especially in USA my smiling risk escalating matters - the policemen get confused when I smile while they write a fine or [just a warning]. [just a warning]: A month ago I drove on a bike on the sidewalk in Brooklyn and nearly ran down three policemen standing at a corner. Surprisingly they only gave me a warning - I had expected a fine then. Thanks to Daniel Kahn Gilmore for lending me the bike! -- * 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: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi Charles, On 12-05-31 at 08:29am, Charles Plessy wrote: > Le Wed, May 30, 2012 at 11:11:51AM +0200, Jonas Smedegaard a écrit : > > > > *nothing* qualifies for a hijacking. > > Dear Jonas, > > your reaction seems to imply that hijacking is an implicit statement > of failure. But this can be dis-ambiguated by thanking the maintainer > for his past work, bringing the package in a team where everybody is > welcome, which is not the same as moving it between two single > maintainers, and by underlining that the reason for transferring the > package to a team is that the mainainer, while not on vacation, could > not be contacted. No, my point is not about lack of recognition for past contributions. No, it is not about teams being welcoming or superior in others ways. It is about Debian not being the Wild West. I distinguish between "hijacking" and "friendly takeover" and "project overruling". What you describe is the proper way of a friendly takeover: You agree with the former maintainer to take over, and in the changelog entry formally announcing it you thank the former maintainer for the past efforts. It can be a person or a team taking over, and if the team also includes the former maintainer it might make sense to skip the "thank you" part. "project overruling" is when Debian by its defined procedures judge that the maintainer is unfit to maintain, and therefore relieve her/him/them of her/his/their duties, Hijacking, in my vocabulary, is when a non-maintainer takes matters in his/her/their own hands and takes over maintainership without the consent of the former maintainer and outside formal Debian procedures. > There is indeed a problem with packages not maintained by DDs as they > can not formally declare themselves on vacation, but search engines > would be able to find such a statement on mailing lists if it had been > posted. My non-Debian-member-as-maintainer rant is not about vacation notices, but about bonding and commitment. It's somewhat like making a baby versus having a baby: Making a Debian package requires certain skills, and some work once (for an hour or a year, depending on who you are). We dearly encourage anyone interested to try it out, and share with the results with us and the rest of the World. Having a package (a.k.a. being a Debian maintainer) additionally requires passion and devotion for a looong time - ideally for the full lifetime of the package. I don't mean to say that only the Debian elite should raise babies, others should use protection - that Debian members are better parents. My point is that the social structures of Debian matters for the quality of maintainance: When you do a poor job in Debian, you get remarks by your peers about it. When you do a poor job outside of Debian, there is silence. Your bonding with Debian helps you either care more or pass it on to someone who cares or get rid of the package. Debian should avoid elitism by welcoming newcomers to our village, not by encouraging raising kids in the jungle. > I think that it is important to have the flexibility to transfer a > package for which the maintainer is not responding, in a neutral way > that is not making any judgement on why he is not responding. I interpret "neutral way" as "through defined process" (i.e. our MIA process or the technical committee) rather than ad hoc. I disagree that we need a defined process for "not responding" regarding a single package as opposed to our "missing in action" affecting all packages a maintainer is involved in: I believe there is no common pattern for the special cases of a maintainer being active but irresponsible towards a subset of packages. MIA process should not be nosy: We should not care _why_, only _if_ a maintainer is not doing the job responsibly. I am unaware if current process is too nosy - but if so it seems ripe for improvements. - 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: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Wed, May 30, 2012 at 06:03:05PM -0700, Steve Langasek wrote: > There is no excuse for hijacking a package, ever. > ... Hmm, this arguing sounds quite German to me. Rules are rules are rules and you should not disregard them. So a German will wait in front of a red traffic light even if there is no visible sign of any car and no sound that might give some signal for any traffic. When I was abroad I enjoyed the habit of other nations just to know when breaking a rule makes perfectly sense. I also think that some common sense could be applied in very obvious cases and this discussion shows that several respected people do agree that there are cases like this where there actually is an excuse for hijacking a package. Kind regards Andreas. -- http://fam-tille.de -- 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/20120531080643.gb6...@an3as.eu
Bug#675310: ITP: grive -- GNU/Linux client for Google Drive
Package: wnpp Severity: wishlist Owner: "José Luis Segura Lucas" * Package name: grive Version : 0.1.0 Upstream Author : Matchman Green * URL : https://github.com/match065/grive * License : GPL2 Programming Lang: C++ Description : GNU/Linux client for Google Drive -- 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/20120531072907.2515.79863.reportbug@mordor
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/30/2012 11:11 AM, Jonas Smedegaard wrote: > On 12-05-30 at 11:30am, Thomas Goirand wrote: >> We aren't kicking him, we want to have the package team maintained. >> He's fine to come and join! > > You want to play by your rules (file), not his. That's kicking to me. > > >> This doesn't really qualify for an NMU, nor does the upgrade to the >> latest upstream version. > > *nothing* qualifies for a hijacking. > > With hijacking I mean disrespectful takeover. > > Either respect maintainership by only NMUing, or respectfully resolve > with the Debian community that the current maintainer is unfit for the > task. You do the latter but instead of the normal use of MIA tracking > you use Debian freeze as argument for swift takeover. I find it not > respectful to rush processing like that! I don't think that hijacking is *that* bad, especially not when its done by a team which welcomes the original maintainer. It is better to have a well maintained package than to ait for somebody who collected a number of NMUs and doesn't react to bug reports for years. > I am not at all surprised that this is yet another sponsored package > bit-rotting. Personally I never liked how we allow maintainer to be > someone not in Debian: There is too great a risk of drive-by > contributions :-( You and a lot of others fail to realize that the *SPONSOR* is responsible for the package. If the maintainer fails to keep the package in a useful shape it is the sponsor's responsibility to do so. And last but not least it should be the sponsor's decision to orphan a package if the maintainer is MIA or not doing his job properly. It is also the sponsors responsibility to try to figure out if a maintainer is willing to do his job longer than one upload before sponsoring a package at all. > ...but we should not improve quality of packages by relaxing the respect > of the maintainer. We should hold maintainers responsible to their > actions - and that is only really possible to do with "social pride" > which is lacking when maintainer is outside of Debian. Yet another job for the sponsor. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc71c48.7070...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thu, May 31, 2012 at 02:01:51PM +0800, Thomas Goirand wrote: > Did you see me writing "I'd like to hijack php-codesniffer in order to rush > and get it into wheezy in time before the freeze"? *NO* ! I didn't write > that. Agreed. I'd have expected people, if anything, to answer suggesting the correct procedure to get things done in this case. I was surprised to see replies harshly escalating matters this way. My understanding is that we have a package that looks unmaintained for 4 years. Yelling at those who volunteer to do some work on it, instead of guiding them to do it in the best way, seems silly and rather un-debianish to me. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
Re: Debian documentation permalinks
[CCing debian-www as requested but I'm not subscribed] Le 31/05/2012 00:34, Charles Plessy a écrit : > Le Sat, May 26, 2012 at 03:03:06AM +0100, Philip Ashmore a écrit : >> >> What I noticed by its absence was that no-one linked to official Debian >> policy detailing the choices made and their justification. >> >> Then it struck me that if such a document existed, it would be subject to >> change as Debian policy itself evolved, making any old links nonsensical or >> misleading. I also think it would be a great thing. > Dear Philip, > > we publish the Debian Policy with the following procedure, that > does not allow permalinks. > > 1) The Policy is developed as a native Debian package. > > 2) Updates of the Policy are published by uploading new > versions of the package. > > 3) www.debian.org extracts the HTML build of the policy from > the latest debian-policy pakcage, and places it under > http://www.debian.org/doc/debian-policy/ > > This helps the Policy team and the WWW team to work without having to learn > each other's build systems, but this means that new versions override old > ones. > > If you have a concrete proposition for a procedure that is as convenient, but > allows to keep old versions somewhere, you can propose it on > debian-...@lists.debian.org, What about a layout similar to this one : http://www.debian.org/doc/debian-policy/@package_version@/[doc extracted] with the following symlinks in http://www.debian.org/doc/debian-policy: "last" or "current" -> `last-version-extracted` X.Y.Z -> last X.Y.Z.T (so that policy are reachable without the minor revision) "squeeze" -> `version included in squeeze` We can also have links for stable/testing/... and/or for number of debian release (release-6.0 -> ...) And anything that does not match the first level is redirected : debian-policy/(.*)$ -> debian-policy/last/$1 with a 304 HTTP redirect so that current links keep the same actual meaning This would allow to target a specific version of the policy in links. Regards, Vincent > but please consider that there can be legitimate > objections to your proposition, and that unless you have time to work on > implementation and maintainance by yourself, your proposition will need to be > exciting enough to decide other volunteers to work on. > > Cheers, > -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/4fc7181f.3090...@free.fr
Re: Claiming the "debian" account on GitHub ?
OoO En cette nuit striée d'éclairs du jeudi 31 mai 2012, vers 02:09,
Charles Plessy disait :
> I do not know why developers prefer GitHub over Gitorious or other providers.
> But I note that even gitlabhq, advertised on this list for its free license,
> has its main download link pointing to GitHub...
GitHub has an issue tracker while Gitorious does not. Moreover, it is
easier to have contribution on a platform where many people have an
account.
--
Vincent Bernat ☯ http://vincent.bernat.im
panic("Oh boy, that early out of memory?");
2.2.16 /usr/src/linux/arch/mips/mm/init.c
pgpnyXe9PH3EY.pgp
Description: PGP signature
