[PROPOSAL v2] Orphaning another maintainer's packages
Hi, According to the huge thread starting at https://lists.debian.org/debian-devel/2012/10/msg00469.html, it seems that: - there's consensus that a lightweight process for orphaning unmaintained packages is a good idea (if you are not convinced yet, I urge you to read Russ' post at https://lists.debian.org/debian-devel/2012/10/msg00546.html ) - there's consensus on how to initiate the process - there's some disagreement on how to complete the process: + some think waiting for ACKs will not work because not enough people might care to ACK + some would prefer a policy based on "no objection for some time" + some think that NACKs should block the process I think I agree with everybody, so here is a new version of the last step of the proposed procedure: --->8 4. When/if consensus has been reached, or if no objections have been raised, the package can be orphaned by retitling and reassigning the ITO bug accordingly. Here are some example situations where it is considered acceptable to move forward: - one month has passed since the ITO bug was submitted, and nobody objected to the orphaning; - one week has passed since the ITO bug was submitted, and at least 3 DDs supported the orphaning (possibly including the submitter of the ITO bug, if it was a DD), while nobody objected. If someone opposed the orphaning, it is generally a better idea to forward the issue to the Technical Committee. However, if objections have been well addressed and there is consensus (indicated by a very large majority of supporters) in favor of the orphaning, it is still possible to move forward. --->8 For completeness, here is the full proposal. I've also addressed a few cosmetic comments. --->8 Orphaning another maintainer's packages It is not uncommon for some packages to end up in an unclear situation, with a maintainer without enough time to maintain them properly. The NMU procedure (described in developers-reference section 5.11) enables other contributors to fix problems when a maintainer is unavailable, but maintaining packages through NMUs is not a viable long term solution, and it is sometimes required to transfer the maintenance of a package to another contributor. This section describes the recommended procedure to orphan a package, thus giving candidate adopters the possibility to take over the maintenance of a package. This procedure aims at being efficient at addressing simple and obvious cases. It is not suitable for more difficult or controversial cases (e.g. active but non-cooperative maintainer) -- in such cases, the issue should be brought to the Technical Committee, as described in the Debian Constitution, section 6.1. 1. Someone opens an ITO (Intent to Orphan) bug against the package whose orphaning is suggested, with the 'serious' severity. The submitter notifies debian...@lists.debian.org (e.g. using X-Debbugs-Cc: debian...@lists.debian.org) of the process. The bug report should contain a detailed analysis of the state of the package, explaining why it should be orphaned. The analysis should focus on the package, not on the maintainer, and great care should be taken to avoid formulations that would be offensive for the maintainer. Relevant information include: release critical bugs, whether the package blocks progress elsewhere in Debian, history of NMUs, lack of any recent activity on that package by the maintainer, public comments of the maintainer showing a lack of interest in the package, previous attempts to contact the maintainer, etc. 2. The submitter should seek comments from the package maintainer (e.g., by sending a private mail notifying him/her of the process). 3. Debian Developers can then support or oppose the proposed orphaning (using signed mails sent to the bug and to debian...@lists.debian.org). Everybody is welcomed to contribute to the discussion, e.g. to comment on problems experienced by users due to the level of maintenance. 4. When/if consensus has been reached, or if no objections have been raised, the package can be orphaned by retitling and reassigning the ITO bug accordingly. Here are some example situations where it is considered acceptable to move forward: - one month has passed since the ITO bug was submitted, and nobody objected to the orphaning; - one week has passed since the ITO bug was submitted, and at least 3 DDs supported the orphaning (possibly including the submitter of the ITO bug, if it was a DD), while nobody objected. If someone opposed the orphaning, it is generally a better idea to forward the issue to the Technical Committee. However, if objections have been well addressed and there is consensus (indicated by a very large majority of supporters) in favor of the orphaning, it is still possible to mov
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Scott Kitterman (27/10/2012): > If the maintainer never responds, then (it turns out) there was no > need for the delay. So there are cases where delay is pointless, > the problem is that you can't tell in advance if you're in one of > those cases or not. Thankfully, nothing stops anyone from NMUing as needed during this period, so packages can be fixed/improved in the meanwhile. Mraw, KiBi. signature.asc Description: Digital signature
Mandatory -dbg packages
Hi! Libraries with `-dbg` package are a pain to deal with when debugging some problem. The solution to ask each user to rebuild the library without stripping debug symbols[1] seem suboptimal. Asking each maintainer to ship a `-dbg` package may be a solution[2] but couldn't we generate those packages automatically by the builders, like this is done with Ubuntu[3]? I remember we had a discussion about this a few years ago. An automatic service has been setup for this[4] by myon but it does not seem to be updated anymore. Why does this experiment have been stopped? Could we mainstream it? [1]: http://wiki.debian.org/HowToGetABacktrace [2]: http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/18-Mandatory-dbg-packages-for-libraries.html [3]: https://wiki.ubuntu.com/DebuggingProgramCrash [4]: http://debug.debian.net/ -- 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/m3ip9w8b50@neo.luffy.cx
Re: suggestion
Ricardo Obando, le Fri 26 Oct 2012 21:29:37 -0300, a écrit : > When will there be in debian installer for Debian and wubi as Ubuntu? When somebody implements it. 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/20121027103909.gv5...@type.wlan.youpi.perso.aquilenet.fr
Re: Mandatory -dbg packages
On Sat, Oct 27, 2012 at 12:25:31PM +0200, Vincent Bernat wrote: > Libraries with `-dbg` package are a pain to deal with when debugging > some problem. You probably mean "without". -- WBR, wRAR signature.asc Description: Digital signature
Re: Mandatory -dbg packages
❦ 27 octobre 2012 12:42 CEST, Andrey Rahmatullin : >> Libraries with `-dbg` package are a pain to deal with when debugging >> some problem. > You probably mean "without". Yes. -- printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n"); 2.2.16 /usr/src/linux/fs/isofs/inode.c pgpxmlPPBGcp3.pgp Description: PGP signature
Re: Mandatory -dbg packages
Do not kick me, but in Solaris, there are : 1) special ELF section .SUNW_ldynsym extending .dynsym [1] 2) .SUNW_ctf with CTF data [2] 3) Function args are saved in stack for amd64 But from my point all it exists because Solaris lacks robust package manager :-) [1] https://blogs.oracle.com/ali/entry/what_is_sunw_ldynsym [2] http://hub.opensolaris.org/bin/view/Project+ppc-dev/ctf 2012/10/27 Vincent Bernat > ❦ 27 octobre 2012 12:42 CEST, Andrey Rahmatullin : > > >> Libraries with `-dbg` package are a pain to deal with when debugging > >> some problem. > > You probably mean "without". > > Yes. > -- > printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n"); > 2.2.16 /usr/src/linux/fs/isofs/inode.c >
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sat, Oct 27, 2012 at 11:36:15AM +0200, Lucas Nussbaum wrote: > - there's some disagreement [...] More disagreement than I expected. > here is a new version of the last step of > the proposed procedure: > For completeness, here is the full proposal. I've also addressed a few > cosmetic comments. > Comments? Thanks for your effort, Lucas. I don't object against this new text. However, I also had a look at the open wnpp bugs to get an idea of how packages are currently being orphaned or put up for adoption in practice. I started from all open RFA, O and ITA bugs. Then I excluded the wnpp bugs for which the bug submitter is one of the package maintainers. I also excluded the wnpp bugs for packages already having Debian QA Group as the maintainer, mostly for practical reasons, so my study is not complete on this part, but I guess that there's little discussion about these packages. Then I excluded the wnpp bugs for packages for which the maintainer has MIA status inactive, unresponsive, retiring, mia, needs-wat, retired or removed. I have read all remaining wnpp bugs. I noticed that quite some packages are being orphaned and put up for adoption without corresponding status in the MIA database. Sounds alarming, but in reality things go quite smooth. The bug submitters seem to be very reasonable. At this point I see no problem with the currently open O, RFA and ITA bugs. I also realized that I can repeat this study automatically and periodically, daily or so, to early detect suspicious new O, RFA and ITA bugs. It is not much work to review the suspicious ones and whitelist the good ones. The remaining ones can be cancelled or debated. So maybe we could simply allow anyone, including non-DDs, to submit O-bugs for packages which seem abandoned by the maintainer, and to submit ITA-bugs for packages he/she wishes to salvage. Sounds revolutionary, but in reality this is more or less already happening. Thoughts ? Comments ? Am I overlooking something ? 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/20121027141925.gc27...@master.debian.org
Re: (seemingly) declinging bug report numbers
On Mon, 22 Oct 2012 08:27:59 +0200, Stefano Zacchiroli wrote:
> On Sun, Oct 21, 2012 at 11:25:47PM +, Felipe Sateler wrote:
>> Another way to look at it is the number of maintainers, as recorded in
>> the Packages and Sources files. I've done a bit of scripting and came
>> with these numbers:
>
> Did you look only at Maintainer, or also at Uploaders? In the former
> case (Maintainer only), you'll probably end up interpreting the
> evolution from individual maintenance to team maintenance as a decrease
> in the available people power, incorrectly imo.
It also looks at uploaders, and filters out debian lists. The script I
used was:
for dist in {0.93R6,1.{1,2,3.1},2.{0,1,2},3.{0,1},4.0,5.0,6.0.6,7.0} ; do
echo $dist
(cat Packages*-${dist}; echo; cat Sources*-${dist}) | \
grep-dctrl . -sUploaders,Maintainer | \
sed '/^[[:space:]]*$/d' | cut -f2 -d: | \
sed -e 's/\(".*\),\(.*"\)/\1\2/g'| \
sed -e 's/,/\n/g' | sort -u | \
grep -v 'lists.*debian.org' > maints-${dist}
done
I also grepped through the debian-devel-changes list[1] to find unique
Changed-By entries, and it suggests the number of monthly active
maintainers has been kept relatively steady, although much more variable
in recent cycles. Yearly data suggests the same.
I have uploaded to [2] an ods file with the numbers.
[1] zgrep '^Changed-By' $src | sort -u > changed.${date} # done in a loop
[2] http://people.debian.org/~fsateler/activity.ods
--
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/k6gvil$12u$1...@ger.gmane.org
Bug#691624: ITP: dput-ng -- next generation Debian package upload tool
Package: wnpp
Severity: wishlist
Owner: "Arno Töll"
Package: wnpp
Severity: wishlist
Owner: Arno Töll
thanks
* Package name: dput-ng
Version : 1.0.0
Upstream Author : Arno Töll , Paul Tagliamonte
* URL : http://people.debian.org/~paultag/dput-ng
* License : GPL-2+
Programming Lang: Python
Description : next generation Debian package upload tool
dput-ng is a Debian package upload tool which provides an easy to use inter-
face to Debian (like) package archive hosting facilities. It allows anyone who
works with Debian packages to upload their work to a remote service, including
Debian's ftp-master, mentors.debian.net, Launchpad or other package hosting
facilities for Debian package maintainers.
dput-ng features many enhancements over dput, such as more comprehensive
checks, an easy to use plugin system, and code designed to handle the numerous
archives that any Debian package hacker will interact with.
dput-ng aims to be backwards compatible with dput in command-line flags,
configuration files, and expected behavior.
Informal part in case someone is curious:
Everyone interested can look at our work at
http://anonscm.debian.org/gitweb/?p=collab-maint/dputng.git. As of today
dpdput-ng is ready to use for early adotors. Users should beware, this first
version is just barely feature complete, so it's recommended for use by those
who wish to provide early feedback or testing. That being said, the authors are
running this on a daily basis, and most features in both dput and dcut have
been tested in production. Problems are infrequent, but may cause breakage in
these early stages. Having that said, we are not aware of any serious problem,
and it can be used right away for most use cases Documentation on dput can be
found in the -doc package built from this source, or at http://dput.rtfd.org/
Finally, as always: Contributions and suggestions are extremely welcome.
Highlights:
* Compatibility with dput.cf configuration files ("old style configuration")
* A new extremely flexible configuration format permitting inheritance of
profiles
* Pluggable interface for third party pre- and post-upload checks
* A public Python API for those who want to embed dput in their own code
* A detached user interface for a future dput GUI
* Pluggable dcut command support (DM permission handling integrated!)
* Support for SFTP uploader and SHA256 checksums
* We avoid common and open issues with dput (old), including but not limited to
the absence of hardcoded paths for commands, checking distribution mismatches,
and more.
Limitations:
* We do not support all dput (old) configuration flags, most notable we do not
have support for progress indication (yet) and we do not support run_dinstall
(we believe this is barely used anymore these days but relies on SSH scraping
instead)
* We do not support "method = rsync" uploads (relies on SSH scraping
again)
* A few other options are not supported because they are superseded by (in our
opinion) superior replacements * Command line options from dcut differ to the
original
--
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/20121027171854.7370.20014.report...@snowball.fritz.box
Re: Mandatory -dbg packages
On 27.10.2012 12:25, Vincent Bernat wrote: > Hi! > > Libraries with `-dbg` package are a pain to deal with when debugging > some problem. The solution to ask each user to rebuild the library > without stripping debug symbols[1] seem suboptimal. Asking each > maintainer to ship a `-dbg` package may be a solution[2] but couldn't we > generate those packages automatically by the builders, like this is done > with Ubuntu[3]? > > I remember we had a discussion about this a few years ago. An automatic > service has been setup for this[4] by myon but it does not seem to be > updated anymore. > > Why does this experiment have been stopped? Could we mainstream it? > Afaik the work was started by pochu as port of GSoC [1][2]. According to [3], Marc was his mentor. I've CCed both, maybe they can comment on what's still missing. I'd love to see that happen. Michael [1] http://wiki.debian.org/EmilioPozueloMonfort/GSoC2009Ddebs [2] http://wiki.debian.org/AutomaticDebugPackages [3] http://wiki.debian.org/SummerOfCode2009#Automatic_Debug_Packages_Creation_and_Handling -- 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: [PROPOSAL v2] Orphaning another maintainer's packages
On Sat, Oct 27, 2012 at 10:19 AM, Bart Martens wrote: > So maybe we could simply allow > anyone, including non-DDs, to submit O-bugs for packages which seem abandoned > by the maintainer, and to submit ITA-bugs for packages he/she wishes to > salvage. Sounds revolutionary, but in reality this is more or less already > happening. Thoughts ? Comments ? Am I overlooking something ? For change of pace, I am fully supportive of this proposal. This process has been tried, demonstrated, and proven effective for a long time now. It is Debian common law, so let's codify it as devref law now, and get away from these new burdensome bureaucratic proposals. Best wishes, Mike -- 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/CANTw=mng-jxa3acdqc+szucs60gndhtwzlrusbe-_fcuywf...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sun, 28 Oct 2012 01:19:25 Bart Martens wrote: > So maybe we could simply allow anyone, including non-DDs, to > submit O-bugs for packages which seem abandoned by the maintainer, and to > submit ITA-bugs for packages he/she wishes to salvage. Yes please. This is common sense and most obvious thing to do. > Sounds > revolutionary, but in reality this is more or less already happening. To me it sounds very reasonable. Regards, Dmitry. -- 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/201210280923.48889.only...@member.fsf.org
Bug#691645: ITP: python-django-schedule -- calendaring app for Django
Package: wnpp Severity: wishlist Owner: Per Andersson * Package name: python-django-schedule Version : 0.5b~ds1 Upstream Author : Zylinsky, Górny, Hauber * URL : http://github.com/boskee/django-schedule * License : BSD Programming Lang: Python Description : calendaring app for Django A calendaring/scheduling Django application, featuring: . * one-time and recurring events * calendar exceptions (occurrences changed or cancelled) * occurrences accessible through Event API and Period API * relations of events to generic objects * ready to use, nice user interface * view day, week, month, three months and year * project sample which can be launched immediately and reused in your project -- Per -- 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/20121027223716.9451.42558.report...@pong.oshw.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Le Sat, Oct 27, 2012 at 02:19:25PM +, Bart Martens a écrit : > > Thanks for your effort, Lucas. I don't object against this new text. Many thanks and thumbs up to Lucas as well. > maybe we could simply allow anyone, including non-DDs, to submit O-bugs for > packages which seem abandoned by the maintainer, and to submit ITA-bugs for > packages he/she wishes to salvage. I think that this misses one of the reasons for the original proposal, which is to provide guidelines to the contributors who refrain from orphaning packages because they are not sure how to appreciate whether packages "seem abandonned". Everybody who are confident in what they are doing can orphan anything any time. And they are fully responsible for their mistakes. The guidelines that are proposed to be added in the Developers reference are a formal process, which purpose is to help the orphaners to strongly reduce the chances that they make a mistake. In my understanding, the existence of such a process would not prevent people who know what they are doing to orphan packages when it makes sense. But for the non-exceptional cases, let's recomend to follow written recommendations who are clear to everyone. Have a nice Sunday, -- 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/20121028005158.ga24...@falafel.plessy.net
Re: GR: Orphaning another maintainer's packages
I don't think we need GRs to decide development procedures like this. -- 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/caktje6hbvkch7zjgzydqnvy43eys619gt9-e562juytajht...@mail.gmail.com
Re: suggestion
On Sat, Oct 27, 2012 at 6:39 PM, Samuel Thibault wrote: > When somebody implements it. Someone already did: ftp://ftp.debian.org/debian/tools/win32-loader/unstable/win32-loader.txt -- 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/CAKTje6GO+LQUt5nyg7SafW58xToD5czGFmfedEc_Ec=0q_f...@mail.gmail.com
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Sat, Oct 27, 2012 at 8:51 PM, Charles Plessy wrote: >> maybe we could simply allow anyone, including non-DDs, to submit O-bugs for >> packages which seem abandoned by the maintainer, and to submit ITA-bugs for >> packages he/she wishes to salvage. > > I think that this misses one of the reasons for the original proposal, which > is > to provide guidelines to the contributors who refrain from orphaning packages > because they are not sure how to appreciate whether packages "seem > abandonned". > > Everybody who are confident in what they are doing can orphan anything any > time. And they are fully responsible for their mistakes. The guidelines that > are proposed to be added in the Developers reference are a formal process, > which purpose is to help the orphaners to strongly reduce the chances that > they > make a mistake. If, as Bart has found, such mistakes are quite rare, then why worry so much? We don't need new formal processes for rarely occurring social problems. We need more people willing to help those that make social mistakes to learn and improve themselves. Best wishes, Mike -- 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/CANTw=mnvaqc-x21m6tegwzjxd6mhz9kghp4+wpcksxpm7o3...@mail.gmail.com
