Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
python-xlrd
3 views
Skip to first unread message
Thomas Kluyver
Feb 6, 2013, 6:50:02 AM2/6/13
to
The python-xlrd package is maintained by Thomas Bläsing and the DPMT, but the packaged version is quite old. A PAPT thread from last year suggests that Thomas Bläsing is missing in action [1].
I've prepared a new version of the package, using a patch from the bug tracker, the latest upstream version, and adding a python3- package. Does anyone object to me committing this to the DPMT SVN repository, and seeking sponsorship for the new version?
Sandro Tosi
Feb 6, 2013, 8:00:02 AM2/6/13
to
On Wed, Feb 6, 2013 at 12:48 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote:
> Does
> anyone object to me committing this to the DPMT SVN repository, and seeking
> sponsorship for the new version?
Yes I do: Thomas is set as the Maintainer (as opposed to the team
> Does
> anyone object to me committing this to the DPMT SVN repository, and seeking
> sponsorship for the new version?
being the Maintainer), so your are more forced to ask Thomas first
given the huge changes you're planning to do: did you contact him (it
doesn't seem so from your email)? have you done that in a public
tracable way (pinging a bug, f.e.)? did you give him enough time to
reply?
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAB4XWXyAh8fmRq8wxqsvQUF+VbBSL+D3=xO8GhP3j...@mail.gmail.com
Thomas Kluyver
Feb 6, 2013, 11:20:02 AM2/6/13
to
On 6 February 2013 12:52, Sandro Tosi <sandr...@gmail.com> wrote:
Yes I do: Thomas is set as the Maintainer (as opposed to the team
being the Maintainer), so your are more forced to ask Thomas first
given the huge changes you're planning to do: did you contact him (it
doesn't seem so from your email)? have you done that in a public
tracable way (pinging a bug, f.e.)? did you give him enough time to
reply?
I've just done some digging. I see no activity from Thomas B since 2009. Lintian is complaining about his packages [1], apart from two where people have managed non-maintainer/team uploads. Tomorrow, it will be two years since a bug was filed requesting a new version of python-xlrd [2]. I can't find him on the TU Berlin site, so it's likely that the e-mail address we're trying for him has expired. No new e-mail address is apparent.
No doubt he should have declared his packages orphaned before he left. But whether he got hit by a bus, or just lost interest in them, I'm not interested in blaming him. I have e-mailed the MIA team to start the 2-month process [3] that will probably end with his packages being orphaned. Of course, it's good to exercise due diligence, but the flip side is that technical changes which I hope would be uncontroversial have now taken a back seat to bureaucracy, because one man a few years ago declared himself 'the maintainer'.
It feels like a big enterprise which should have a pretty good bus factor has been artificially split into many small projects, each with a terrible bus factor. There are plenty of people who understand the packaging for something simple like this, and hundreds [4] of Debian developers that we trust to upload packages. But changing a package hinges on an individual maintainer, who could be busy, on holiday, uninterested, or deceased.
I suggest that we encourage packagers to make team maintainership the norm, and individual maintainership the exception, to avoid this kind of problem. This is in line with plenty of other open source projects, where people talk about not becoming a bottleneck or a single point of failure.
[1] http://lintian.debian.org/maintainer/thom...@pool.math.tu-berlin.de.html
[2] https://bugs.launchpad.net/debian/+source/python-xlrd/+bug/714632
[3] http://wiki.debian.org/qa.debian.org/MIATeam
[4] http://www.debian.org/devel/people
Best wishes,
Thomas
Thomas
Barry Warsaw
Feb 6, 2013, 12:00:02 PM2/6/13
to
On Feb 06, 2013, at 04:12 PM, Thomas Kluyver wrote:
>I suggest that we encourage packagers to make team maintainership the norm,
>and individual maintainership the exception, to avoid this kind of problem.
>This is in line with plenty of other open source projects, where people
>talk about not becoming a bottleneck or a single point of failure.
+1. I feel like, while we have some individual differences of opinion within
>I suggest that we encourage packagers to make team maintainership the norm,
>and individual maintainership the exception, to avoid this kind of problem.
>This is in line with plenty of other open source projects, where people
>talk about not becoming a bottleneck or a single point of failure.
the Python teams, they and the people on them function quite well for packages
we maintain. I have no hesitation giving team maintainership to the packages
I care about in Debian.
Cheers,
-Barry
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Elena ``of Valhalla''
Feb 6, 2013, 1:10:02 PM2/6/13
to
On 2013-02-06 at 16:12:21 +0000, Thomas Kluyver wrote:
> No doubt he should have declared his packages orphaned before he left. But
> whether he got hit by a bus, or just lost interest in them, I'm not
> interested in blaming him. I have e-mailed the MIA team to start the
> 2-month process [3] that will probably end with his packages being
> orphaned.
Actually, I have already contacted the MIA team about him back in June
> No doubt he should have declared his packages orphaned before he left. But
> whether he got hit by a bus, or just lost interest in them, I'm not
> interested in blaming him. I have e-mailed the MIA team to start the
> 2-month process [3] that will probably end with his packages being
> orphaned.
to be able to adopt another of his packages (pdfposter);
I believe that they had already been contacted (possibly when the
original email was sent to the mailing list?)
I hope that I didn't miss doing some step of the procedure that could
have helped with this package: I'm still learning about contributing to
debian and it's my first time.
--
Elena ``of Valhalla''
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Simon McVittie
Feb 6, 2013, 2:00:02 PM2/6/13
to
On 06/02/13 16:12, Thomas Kluyver wrote:
> Of course, it's good to exercise due diligence, but the flip
> side is that technical changes which I hope would be uncontroversial
> have now taken a back seat to bureaucracy, because one man a few years
> ago declared himself 'the maintainer'.
If the request for a new version has been open for 2 years, waiting
> Of course, it's good to exercise due diligence, but the flip
> side is that technical changes which I hope would be uncontroversial
> have now taken a back seat to bureaucracy, because one man a few years
> ago declared himself 'the maintainer'.
another couple of months to confirm that the maintainer doesn't object
isn't really going to make much difference - particularly if that's 2
months of release-freeze time.
Debian is currently in a freeze, so any uploads you make now are not
going to reach the next release anyway, unless they meet the freeze
policy <http://release.debian.org/wheezy/freeze_policy.html>.
If you have changes that *do* meet the freeze policy (roughly:
non-invasive fixes for bugs with severity >= important, with a small
enough diffstat for the release team to be able to review it sensibly),
they can be made via a NMU or a team upload.
If you have changes that *don't* meet the freeze policy, I would suggest
that now is not the time: they won't migrate from unstable to testing
anyway, and if important bugs are subsequently reported in python-xlrd,
having a newer version in unstable will make it more difficult to get
those bugs fixed in testing.
New upstream versions are not usually eligible for freeze exceptions
(unless they're targeted, bugfix-only releases from an upstream with a
relatively strict stable-branch policy).
Major packaging changes, like moving from dpatch to 3.0 (quilt) (or cdbs
to dh, or anything similar) are specifically mentioned in the freeze
policy as something that is not eligible.
S
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sandro Tosi
Feb 6, 2013, 2:40:03 PM2/6/13
to
On Wed, Feb 6, 2013 at 5:12 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote:
> I suggest that we encourage packagers to make team maintainership the norm,
> and individual maintainership the exception, to avoid this kind of problem.
> This is in line with plenty of other open source projects, where people talk
> about not becoming a bottleneck or a single point of failure.
please read our "unwritten policy" about Maintainer field at
> I suggest that we encourage packagers to make team maintainership the norm,
> and individual maintainership the exception, to avoid this kind of problem.
> This is in line with plenty of other open source projects, where people talk
> about not becoming a bottleneck or a single point of failure.
http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
Anyone is free to do whatever they want in their spare time, even set
themselves as maintainer for a tool they're packaging, and then let
the project handle their departure: that happened many times, and it
won't be fixed by a false sense of team-maintanership when someone
steps up, do a huge change in a package he doesn't care and then run
away (extreme hypothesis - we would be in the same situation as of
now: the team would fix the issues arising.
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Kluyver
Feb 6, 2013, 4:30:02 PM2/6/13
to
On 6 February 2013 19:30, Sandro Tosi <sandr...@gmail.com> wrote:
please read our "unwritten policy" about Maintainer field at
http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
"As a general rule of thumb, just set Maintainer
to the team; there might be some exceptions, like in situations where
the package is so complex that a check from a knowledgeable person is
welcome before an upload but they are very rare."
This is pretty much what I mean, but I think we should strengthen it a bit from what I think the current case is. Namely, if someone does an RFS for a package with themselves set as the Maintainer, the reviewer should encourage them to put the team there instead. Maybe reviewers are already doing that, although I don't remember seeing it.
Simon:
Simon:
> If the request for a new version has been open for 2 years, waiting
another couple of months to confirm that the maintainer doesn't object
isn't really going to make much difference - particularly if that's 2
months of release-freeze time.
It's two months in which someone has to e-mail Thomas B several times, and in which what I've done will fall out of my memory. Maybe I'll forget about it by April, and someone will end up redoing the work. Maybe my laptop will kick the bucket in the meantime, and the changes that I couldn't commit to the centralised VCS will be lost. (Although in this case, they're in my PPA [1])
It's two months of release freeze time for Debian, but my understanding is that submitting to Debian experimental remains the preferred way to get new versions into Ubuntu. Ubuntu is not currently frozen, but in two months time it will be, so it will miss these changes for another 6 months.
Finally, it's two months as a minimum. Elena contacted the MIA team at least seven months ago, but Thomas B's packages have not been orphaned. That suggests that either they didn't follow up, or that he made contact but hasn't resumed any maintenance. I haven't seen any way to check on that, or to know the fate of my message to the MIA team.
Thomas
Sandro Tosi
Feb 6, 2013, 4:40:02 PM2/6/13
to
On Wed, Feb 6, 2013 at 10:24 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote:
> On 6 February 2013 19:30, Sandro Tosi <sandr...@gmail.com> wrote:
>>
>> please read our "unwritten policy" about Maintainer field at
>> http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
>
>
> "As a general rule of thumb, just set Maintainer to the team; there might be
> some exceptions, like in situations where the package is so complex that a
> check from a knowledgeable person is welcome before an upload but they are
> very rare."
>
> This is pretty much what I mean, but I think we should strengthen it a bit
> from what I think the current case is. Namely, if someone does an RFS for a
> package with themselves set as the Maintainer, the reviewer should encourage
> them to put the team there instead. Maybe reviewers are already doing that,
> although I don't remember seeing it.
if you deliberately skip the other part of my reply, you'd miss a
> On 6 February 2013 19:30, Sandro Tosi <sandr...@gmail.com> wrote:
>>
>> please read our "unwritten policy" about Maintainer field at
>> http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
>
>
> "As a general rule of thumb, just set Maintainer to the team; there might be
> some exceptions, like in situations where the package is so complex that a
> check from a knowledgeable person is welcome before an upload but they are
> very rare."
>
> This is pretty much what I mean, but I think we should strengthen it a bit
> from what I think the current case is. Namely, if someone does an RFS for a
> package with themselves set as the Maintainer, the reviewer should encourage
> them to put the team there instead. Maybe reviewers are already doing that,
> although I don't remember seeing it.
relevant rebuttal to your reasoning that having the team as maintainer
is always and will fix all the problems regarding desappearing
maintainers and team members doing changes to packages and then stop
caring about it.
> It's two months in which someone has to e-mail Thomas B several times, and
> in which what I've done will fall out of my memory. Maybe I'll forget about
> it by April, and someone will end up redoing the work. Maybe my laptop will
> kick the bucket in the meantime, and the changes that I couldn't commit to
> the centralised VCS will be lost. (Although in this case, they're in my PPA
> [1])
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages