Bug#877024: Modemmanager probing of unknown Devices

[Didier 'OdyX' Raboud]

Le lundi, 30 octobre 2017, 14.06:01 h CET Ian Jackson a écrit :
> I can see why the TC might want to avoid making a final ruling without
> proper input from the maintainers.

> But, should I upload to experimental, and later, to sid, as I have
> proposed ?  It's not quite clear whose permission I need.  To some
> people I have already overstepped the mark[1].
> [1] Apparently referring the matter to the TC a mere 5 years after
> the maintainers rejected changing the behaviour is too hasty.  I
> accept of course that the way I recently brought my renewed awareness
> of this problem to the attention of the maintainers wasn't ideal.

My personal take is that waiting only two days between saying "I'm likely to 
escalate to the TC" and doing so [2,3] is quite pushy "against" the 
maintainers who haven't had a reasonable chance to react, especially after two 
years inactivity on a 5 year-old bug.

[2] https://bugs.debian.org/683839#77
[3] https://bugs.debian.org/877024#5

> The dev ref says "Have you geared the NMU towards helping the
> maintainer?" and it all seems rather awkward to me to claim I am
> "helping the maintainer" when AFAICT the maintainers are quite
> unenthusiastic about these proposals.

Claiming that they are unenthusiastic is far-reaching IMHO. We just don't know 
what they think of the change, really. I wouldn't necessarily interpret the 
removal from the maintainers' field as a statement of opinion on these 
proposed changes, but much more about who the process went, and was handled by 
the TC too.

Le lundi, 30 octobre 2017, 13.45:00 h CET Sam Hartman a écrit :
> Wou/ld it be reasonable for him to make an NMU to experimental, and then
> if there is no objection after testing to unstable?
> 
> In parallel, it seems desirable to see if any of the maintainers are
> active.

The latter looks like a prerequisite to me, frankly. It seems to me from 
reading the bug log again that a solution is being worked out by upstream; and 
that this solution seems fine to the people who have intervened in this very 
bug. So it looks like the solution is ahead, "just" not yet in a Debian 
package. That bug exists in Debian for 5+ years, so I really don't see the 
urgency for an NMU, and would much rather let the current maintainers include 
the upstream version which includes the fix (and configure it appropriately) 
when they see fit.

Cheers,
OdyX

Bug#877024: Modemmanager probing of unknown Devices

[Sam Hartman]

Like Ian, I honestly don't know what the rules are in this situation.

Wou/ld it be reasonable for him to make an NMU to experimental, and then
if there is no objection after testing to unstable?
In parallel, it seems desirable to see if any of the maintainers are
active.

--Sam

Re: Bug#877024: Modemmanager probing of unknown Devices

[Ian Jackson]

Sam Hartman writes ("Re: Bug#877024: Modemmanager probing of unknown Devices"):
> No, that was not the tone of Ian's message.  I wish it had been.

I'm sorry that my message didn't come across as Sam writes:

> He wrote the patch and said roughly "Hey, I know you don't like this,
> and I think we need some outside help  deciding which of us is right.
> I'm going to give you a bit of time in less I've got it all wrong and
> you're OK with this approach and then I'm going to ask for help."

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#877024: Modemmanager probing of unknown Devices

[Ian Jackson]

Sam Hartman writes ("Re: Bug#877024: Modemmanager probing of unknown Devices"):
> I wanted to make you aware of a status update.
> The maintainer who has been doing most of the uploads on modemmanager
> stepped down after receiving my query.

Oh.

> As a matter of process, it's not clear that there's an active maintainer
> of modemmanager.  Speaking as an individual, but not as a TC member (I
> haven't talked to anyone else), I think it would be reasonable to treat
> modemmanager as a package that is under-maintained at the moment in
> which you've found a bug you care about, approaching things and
> balancing the same as you might in any similar situation.

Yes.

I think that means in this case (since there is some controversy)
explaining what I intend to do and seeing if anyone objects.

Concretely, that means that I should be thinking about uploading the
experimental upstream probing change branch to Debian experimental.

> With more of a TC hat on, I am very reluctant to rule on this issue
> without an active modemmanager maintainer.  I don't think there is a
> compelling need to do so, and I don't want to rule out the possibility
> of a modemmanager maintainer coming along later and presenting an
> argument about how we should balance this issue.
> I don't think the lack of a ruling will be a blocking force at the
> current time.

I can see why the TC might want to avoid making a final ruling without
proper input from the maintainers.

But, should I upload to experimental, and later, to sid, as I have
proposed ?  It's not quite clear whose permission I need.  To some
people I have already overstepped the mark[1].

The dev ref says "Have you geared the NMU towards helping the
maintainer?" and it all seems rather awkward to me to claim I am
"helping the maintainer" when AFAICT the maintainers are quite
unenthusiastic about these proposals.

I would welcome a decision by the TC (or informal comments, for that
matter) saying simply that they think it would be appropriate for me
to do those uploads.

Thanks,
Ian.

[1] Apparently referring the matter to the TC a mere 5 years after
the maintainers rejected changing the behaviour is too hasty.  I
accept of course that the way I recently brought my renewed awareness
of this problem to the attention of the maintainers wasn't ideal.

Re: Bug#877024: Modemmanager probing of unknown Devices

[Sam Hartman]

[Bug dropped; I don't think this has value in that bug log]

> "Ansgar" == Ansgar Burchardt  writes:


In reading your message, I realize there is an interesting challenge
here.  When I agree that it might be reasonable for the TC to take a
look at something, what is going through my head may be very different
than what is going through the head of the person bringing the bug to
the TC.

Consider the following interpretation of the same facts you present.
We had a bug opened in 2012.  According to one person, his approach had
already been considered and rejected by the maintainer.
That person wanted a concrete patch available to prove that  it was
possible to implement the approach.
He wrote the patch and said roughly "Hey, I know you don't like this,
and I think we need some outside help  deciding which of us is right.
I'm going to give you a bit of time in less I've got it all wrong and
you're OK with this approach and then I'm going to ask for help."

Under those circumstances, I think it's reasonable for the TC to start
looking at the issue.  In a case where something has been sitting around
since 2012, I think it is reasonable to start looking at whether a
general policy statement or technical advice could help.

No, that was not the tone of Ian's message.  I wish it had been.  But
honestly, yeah, if someone thinks an issue is broken in 2012, and it's
still broken in 2017, and that person is hurt and frustrated by that
experience, I think it is reasonable for the TC to look at the situation
and see if we can help.  I'll be thinking things a lot more like
mediation, helping people understand, providing policy, providing
technical advice than I will override maintainer, provide specific
solution.

--Sam

Bug#877024: Modemmanager probing of unknown Devices

[Ansgar Burchardt]

Sam Hartman  writes:
> Also, as may be obvious from my previous post today, I was shaken by
> some of the meta issues here.  I am much more focused at the moment on
> thinking about the TC process and our community than I am about this issue.

If the ctte believes that escalating an issue to the ctte after not
getting a reply from the maintainer in less than three days (time
between [1] and [2]) is the way to go, I wouldn't be that motivated to
deal with the ctte as a maintainer either.  Also note that the bug has
been inactive for over two years prior.

(Well, on the plus side the package was just hijacked because rules
don't apply to some people...  That's a step forward.)

Ansgar

  [1] https://bugs.debian.org/683839#77
  [2] https://bugs.debian.org/877024

Bug#877024: Modemmanager probing of unknown Devices

[Sam Hartman]

Dear Ian:

I wanted to make you aware of a status update.
The maintainer who has been doing most of the uploads on modemmanager
stepped down after receiving my query.  First, I'd like to extend my
thanks to Michael for his hard work on modemmanager in the past and all
the things he continues to do for Debian.  Second, I'm glad that he
stepped aside when it was time to do so: doing that is an important part
of staying healthy.

As a matter of process, it's not clear that there's an active maintainer
of modemmanager.  Speaking as an individual, but not as a TC member (I
haven't talked to anyone else), I think it would be reasonable to treat
modemmanager as a package that is under-maintained at the moment in
which you've found a bug you care about, approaching things and
balancing the same as you might in any similar situation.

With more of a TC hat on, I am very reluctant to rule on this issue
without an active modemmanager maintainer.  I don't think there is a
compelling need to do so, and I don't want to rule out the possibility
of a modemmanager maintainer coming along later and presenting an
argument about how we should balance this issue.
I don't think the lack of a ruling will be a blocking force at the
current time.


I won't stand in the  way of other members who do want to rule on this
issue.  However, I cannot imagine getting to a point where  I'd vote
anything other than FD or defer on this issue right now

Also, as may be obvious from my previous post today, I was shaken by
some of the meta issues here.  I am much more focused at the moment on
thinking about the TC process and our community than I am about this issue.


signature.asc
Description: PGP signature

Bug#877024: Modemmanager probing of unknown Devices

[Ian Jackson]

Tollef Fog Heen writes ("Bug#877024: Modemmanager probing of unknown Devices"):
> Given there's no indication they were made aware of your bug filing that
> I could find, I don't think that's a conclusion we can make.

In my message on the 25th of September I wrote, in prose, that I
intended to escalate this issue to the TC:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#77

I got no response, so I filed #877024.  When I did so, the BTS sent
this mail CC the maintainers:

   From: ow...@bugs.debian.org (Debian Bug Tracking System)
   To: Ian Jackson <ijack...@chiark.greenend.org.uk>
   CC: debian-ctte@lists.debian.org,
pkg-utopia-maintain...@lists.alioth.debian.org
   Subject: Processed: modemmanager should ask before messing with serial ports
   Date: Wed, 27 Sep 2017 20:51:06 +

   Processing control commands:

   > block 683839 by -1
   Bug #683839 [modemmanager] modemmanager fiddles with ttyUSB devices without 
asking first
   683839 was not blocked by any bugs.
   683839 was not blocking any bugs.
   Added blocking bug(s) of 683839: 877024

   -- 
   683839: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839
   877024: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877024
   Debian Bug Tracking System
   Contact ow...@bugs.debian.org with problems

This is indeed not an ideal as a way to draw the escalation to the
maintainers' attention.  (None of the traffic in #683839 explicitly
mentions the TC.)  I should have used X-Debbugs-CC to CC my initial
report of #877024 to the maintainers.  Sorry for not doing that.

I'm happy to wait a bit longer to see if the maintainers have an
opinion.

Thanks,
Ian.

Bug#877024: Modemmanager probing of unknown Devices

[Tollef Fog Heen]

]] Ian Jackson 

> Sam Hartman writes ("Bug#877024: Modemmanager probing of unknown Devices"):
> > Hi.  In #877024, the TC was asked to rule on whether modemmanager should
> > continue to probe USB devices that might not be modems.
> > 
> > There's been significant involvement from upstream leading to a new
> > optional behavior that is less aggressive about probing unknown devices.
> > 
> > Would it help the maintainer for the TC to rule on this issue?
> > 
> > Do you have any input into the TC process you would like to give?
> 
> Thanks for asking these questions, Sam.
> 
> FAOD, currently, it seems that the Debian maintainers don't have time
> to address this issue in Debian.  That is fine of course.  No-one is
> obliged to do work, even if their name is in the Maintainer or
> Uploaders field.

Given there's no indication they were made aware of your bug filing that
I could find, I don't think that's a conclusion we can make.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#877024: Modemmanager probing of unknown Devices

[Keith Packard]

Ian Jackson  writes:

> I intend to carry on and try to help do the Debian part of this, with
> NMUs as seem appropriate.  My earlier email suggesting an upload to
> experimental is part of that.  If the modemmanager maintainers would
> like to step in then that would be great of course.  Just let me know.

This seems fine to me; I think the TC as a body is happiest when
maintainers work things out collaboratively, using the NMU process
gently to help make the distribution better.

(Thanks for driving this; it's been a personal annoyance for years, just
not enough to get me to actually work on it)

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: Modemmanager probing of unknown Devices

[Ian Jackson]

Sam Hartman writes ("Bug#877024: Modemmanager probing of unknown Devices"):
> Hi.  In #877024, the TC was asked to rule on whether modemmanager should
> continue to probe USB devices that might not be modems.
> 
> There's been significant involvement from upstream leading to a new
> optional behavior that is less aggressive about probing unknown devices.
> 
> Would it help the maintainer for the TC to rule on this issue?
> 
> Do you have any input into the TC process you would like to give?

Thanks for asking these questions, Sam.

FAOD, currently, it seems that the Debian maintainers don't have time
to address this issue in Debian.  That is fine of course.  No-one is
obliged to do work, even if their name is in the Maintainer or
Uploaders field.

It looks like the conversation with upstream is going constructively
and will yield something that should be satisfactory to them, and to
me, at least.

I intend to carry on and try to help do the Debian part of this, with
NMUs as seem appropriate.  My earlier email suggesting an upload to
experimental is part of that.  If the modemmanager maintainers would
like to step in then that would be great of course.  Just let me know.

My main goal is that we should not let this bug go unfixed in buster.

So, addressing the need for a TC decision:

If there is no objection from the modemmanager maintainers to the
general direction which has been proposed and discussed here
(including the use of the `strict' probing policy), and no objection
to NMUs (on a relaxed timescale, but eventually targeting sid and
hence buster), then I don't see the need for a TC ruling.

If there are objections of detail then I think we should be able to
resolve them amicably.  I'm happy to take guidance.

It is mostly if there is an objection about the principle of the
approach that modemmanager should take, or an objection to NMUs, that
a TC decision might be needed.

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#877024: Modemmanager probing of unknown Devices

[Sam Hartman]

Hi.  In #877024, the TC was asked to rule on whether modemmanager should
continue to probe USB devices that might not be modems.

There's been significant involvement from upstream leading to a new
optional behavior that is less aggressive about probing unknown devices.

Would it help the maintainer for the TC to rule on this issue?

Do you have any input into the TC process you would like to give?

Thanks,

--Sam