Bug#787578: RFS: soci/3.2.3-1 [ITP] -- C++ Database Access Library
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "soci" * Package name: soci Version : 3.2.3-1 * URL : http://sourceforge.net/projects/soci/ * License : Boost 1.0 Section : libs It builds those binary packages: libsoci-core3.2 - C++ Database Access Library (core) libsoci-dbg - C++ Database Access Library (debug symbols) libsoci-dev - C++ Database Access Library (devel) libsoci-doc - C++ Database Access Library (development docs) libsoci-firebird3.2 - C++ Database Access Library (Firebird backend) libsoci-mysql3.2 - C++ Database Access Library (MySQL backend) libsoci-odbc3.2 - C++ Database Access Library (ODBC backend) libsoci-postgresql3.2 - C++ Database Access Library (PostgreSQL backend) libsoci-sqlite3-3.2 - C++ Database Access Library (SQLite3 backend) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/soci Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/soci/soci_3.2.3-1.dsc More information about soci can be obtained from http://sourceforge.net/projects/soci/ Changes since the last upload: * Reintroduce package to archive (Closes: #752696) * New upstream release * Remove patches for issues fixed upstream * Update to debhelper v9 compatibility * Specify source format as 3.0 (quilt) * Update packaging to work with new (cmake-based) build scripts * Update to support multiarch * Update copyright to dep5 format * Add VCS fields in d/control * Rename packages to match SONAMEs * Update to standards version 3.9.6 Note: This package previously existed in the archive, but was removed several years ago due to maintainer request and a mostly-dead upstream. Upstream development has resumed, and my coworkers and I use this library often, so I would like to reintroduce it to the archive and maintain it. Regards, Bill Blough -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150603013850.gb16...@blough.us
Re: Why are old bug reports left open?
On 2015-06-02 20:10, Thaddeus H. Black wrote:
> [...]
> If I were the maintainer, I believe that I would have closed a bug like this.
> The actual maintainer however (now emeritus) is smarter than me. He did not
> close it. This suggests that he knew something I do not understand about
> proper bug handling.
>
The package is orphaned and thus have no "actual maintainer".
There are plenty of reasons why the previous maintainer might not have
closed the bug. The most common/likely one being that he/she simply
forgot about it (and happened to retire before remembering about it).
If I were you, and I saw no reason to keep the bug open, I would close
it. You will hear from people when they disagree strongly with your
actions, but they will be quiet if they agree or don't care.
> [...]
>
> I am confused. What should I learn from this example about proper bug
> handling, please?
>
> (For information, I am thinking of adopting the package in question, orphaned
> six months. I am however reluctant to begin by closing bugs the old, smart
> maintainer saw fit to leave open. I am not the best possible maintainer for
> this package, but no one else is maintaining it. This is why I ask advice.)
>
I believe that [1] is a good resource for you. None of us were perfect
when we joined and none of us are now despite our best efforts (the
"old, smart maintainer" included).
If you want a lesson learned:
* Always tag/update your bugs when you reply to the bug.
* Frequently revisit the bugs for your packages and check if some of
them has expired by now.
- Pro-tip: Have a periodic calender reminder for this. E.g. "spring
clean the bug page for ${list-of-packages}" set for the early
period of March, where it is still too cold to go outside but light
enough for you to leave your winter coat at home despite knowing
you will freeze at the slightest breeze.
Thanks,
~Niels
[1] https://lwn.net/Articles/641779/
signature.asc
Description: OpenPGP digital signature
Re: Why are old bug reports left open?
On Tue, Jun 02, 2015 at 06:10:24PM +, Thaddeus H. Black wrote: > A bug is years old. It will probably not be fixed. It should probably not > be fixed. It is probably not even a bug. > > The bug's submitter is not complaining. > > Why is the bug still open? > > Example: #619363. [1] > > 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619363 > > If I were the maintainer, I believe that I would have closed a bug like this. > The actual maintainer however (now emeritus) is smarter than me. He did not > close it. This suggests that he knew something I do not understand about > proper bug handling. Probably the maintainer was reluctant to close the bug at the same time as providing the info he provided in his email, and wanted to see the submitter's reaction first. Then, when you have 48 bugs on a package, it's easy to lose that one bug, forgetting about it. > I am confused. What should I learn from this example about proper bug > handling, please? That proper and timely bug triaging is a very important (and time consuming) part of maintaining a package with a lot of open bug reports, which is often not done because a maintainer doesn't have time for it. -- WBR, wRAR signature.asc Description: Digital signature
Why are old bug reports left open?
A bug is years old. It will probably not be fixed. It should probably not be fixed. It is probably not even a bug. The bug's submitter is not complaining. Why is the bug still open? Example: #619363. [1] 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619363 If I were the maintainer, I believe that I would have closed a bug like this. The actual maintainer however (now emeritus) is smarter than me. He did not close it. This suggests that he knew something I do not understand about proper bug handling. I cannot find the answer in Developer's Reference, sect. 5.8. I am confused. What should I learn from this example about proper bug handling, please? (For information, I am thinking of adopting the package in question, orphaned six months. I am however reluctant to begin by closing bugs the old, smart maintainer saw fit to leave open. I am not the best possible maintainer for this package, but no one else is maintaining it. This is why I ask advice.) signature.asc Description: Digital signature
