Debian Bug report logs - #688772
gnome Depends network-manager-gnome

Package: tech-ctte; Maintainer for tech-ctte is Technical Committee <debian-ctte@lists.debian.org>;

Reported by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Date: Tue, 25 Sep 2012 14:57:02 UTC

Severity: normal

Done: Bdale Garbee <bdale@gag.com>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 14:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
New Bug report received and forwarded. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 14:57:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: submit@bugs.debian.org
Subject: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 15:54:45 +0100
Package: tech-ctte

As I wrote to debian-release:
> As you may be aware, the TC recently overruled the maintainers of the
> gnome-core metapackage, deciding that the dependency from gnome-core
> to network-manager should be weakened from Depends to Recommends.
> (The full TC decision is reproduced below.)
> 
> In response to this the maintainers have uploaded a new version of
> meta-gnome in which the gnome-core package Recommends
> network-manager-gnome, as required.  However, additionally, they have
> reintroduced a dependency from gnome to network-manager-gnome, as
> Depends.  See the changes info, also below.
> 
> The Release Team should be aware that our request to unblock the
> update to meta-gnome implementing the TC decision does not extend to
> this latter change to meta-gnome.
> 
> I am going to try to get the TC to pass another resolution
> specifically overruling this further decision by the gnome-core
> maintainers.

This bug is to track this issue.  Please send all discussion on this
topic only to this bug report.  I will make sure that the gnome
maintainers are pointed to this bug report.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 15:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 15:06:03 GMT) Full text and rfc822 format available.

Message #10 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: meta-gnome@packages.debian.org
Cc: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 16:03:46 +0100
As I wrote to debian-release:
> As you may be aware, the TC recently overruled the maintainers of the
> gnome-core metapackage, deciding that the dependency from gnome-core
> to network-manager should be weakened from Depends to Recommends.
> (The full TC decision is reproduced below.)
> 
> In response to this the maintainers have uploaded a new version of
> meta-gnome in which the gnome-core package Recommends
> network-manager-gnome, as required.  However, additionally, they have
> reintroduced a dependency from gnome to network-manager-gnome, as
> Depends.  See the changes info, also below.
> 
> The Release Team should be aware that our request to unblock the
> update to meta-gnome implementing the TC decision does not extend to
> this latter change to meta-gnome.
> 
> I am going to try to get the TC to pass another resolution
> specifically overruling this further decision by the gnome-core
> maintainers.

As I say I think this needs to be revisited by the TC.  I have filed
#688772 against tech-ctte to track this.  Please send all discussion
on this topic only to this bug report.

You will probably want to subscribe to this bug, and to read its
online archives to catch up with any messages you have missed.

Thanks,
Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 15:36:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 15:36:05 GMT) Full text and rfc822 format available.

Message #15 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 16:33:01 +0100
I'm quite cross.  How about this?

Ian.


Whereas

1. The TC notes the decision of the meta-gnome maintainers to
   implement our decision in #681834 by:
    (a) softening the dependency in the gnome-core metapackage
        from Depends to Recommends, as required
    (b) adding a new dependency in the gnome metapackage,
        as a Depends.  (In squeeze, this is where the dependency
        was, but it was a Recommends.)

2. Our intent, as stated in the rationale section of our previous
   decision (#681834, paras 3 and 5), is that squeeze users who have
   gnome installed but not network-manager do not find that
   network-manager becomes installed when they upgrade to wheey.

3. The actions of the meta-gnome maintainers do not achieve this
   objective.

4. A Recommends from gnome to network-manager-gnome would serve no
   purpose in wheezy as gnome Depends on gnome-core which already
   Recommends network-manager-gnome.

Therefore

4. We overrule the decision of the meta-gnome maintainers to add a
   dependency from gnome to network-manager.  This dependency should
   be removed.

5. We request that the Release Team unblock update(s) to meta-gnome so
   that our decisions may be implemented in wheezy.

6. We specifically forbid anyone from introducing in wheezy, or
   in sid until wheezy is released:
    a. Any new or enhanced dependencies, or any other mechanisms which
       are intended to increase the likelihood of network-manager
       being installed;
    b. Any new or enhanced user-facing warnings, imprecations, or
       other kinds of message regarding the alleged desirability or
       requirement to install network-manager;
    c. Any change which in any way impairs (or further impairs) the
       functioning of systems with GNOME components installed but
       without network-manager;
    d. Any change which is contrary to the spirit or intent of either
       our previous resolution in #681834 or this resolution.
   without first obtaining the permission of at least one member of
   the Technical Committee.

7. We request that the Release Team DO NOT unblock any updates to
   wheezy which appear to the Release Team to be contrary to our
   intent.

Furthermore

8. It should have been obvious that the path chosen by the meta-gnome
   maintainers would not be satisfactory.  If there had been any doubt
   on this point, the maintainers should have proposed this solution
   while the TC resolution was being discussed and drafted so that it
   could have been accepted or rejected accordingly.

9. We conclude that the actions of the meta-gnome maintainers are
   plainly intended to defeat or evade the intent of our previous
   decision.  We note that the Constitution requires members of the
   project not to work against decisions properly made according to
   the project's governance processes.

10. We therefore formally reprimand Josselin Mouette.  We consider his
   behaviour deliberately obstructive and obtuse.

11. On this occasion we do not feel it necessary to refer anyone to the
   Debian Account Managers asking for a review of their status.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 15:36:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 15:36:07 GMT) Full text and rfc822 format available.

Message #20 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: gnome@packages.debian.org
Cc: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 16:34:27 +0100
(Sorry, trying this again because p.d.o doesn't recognise the source
package name, only the binary package name:)

As I wrote to debian-release:
> As you may be aware, the TC recently overruled the maintainers of the
> gnome-core metapackage, deciding that the dependency from gnome-core
> to network-manager should be weakened from Depends to Recommends.
> (The full TC decision is reproduced below.)
> 
> In response to this the maintainers have uploaded a new version of
> meta-gnome in which the gnome-core package Recommends
> network-manager-gnome, as required.  However, additionally, they have
> reintroduced a dependency from gnome to network-manager-gnome, as
> Depends.  See the changes info, also below.
> 
> The Release Team should be aware that our request to unblock the
> update to meta-gnome implementing the TC decision does not extend to
> this latter change to meta-gnome.
> 
> I am going to try to get the TC to pass another resolution
> specifically overruling this further decision by the gnome-core
> maintainers.

As I say I think this needs to be revisited by the TC.  I have filed
#688772 against tech-ctte to track this.  Please send all discussion
on this topic only to this bug report.

You will probably want to subscribe to this bug, and to read its
online archives to catch up with any messages you have missed.

Thanks,
Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 15:42:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 15:42:06 GMT) Full text and rfc822 format available.

Message #25 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 16:38:08 +0100
Ian Jackson writes ("Bug#688772: gnome Depends network-manager-gnome"):
> 6. We specifically forbid anyone from introducing in wheezy, or
>    in sid until wheezy is released:
>     a. Any new or enhanced dependencies, or any other mechanisms which
>        are intended to increase the likelihood of network-manager
>        being installed;

This is missing an important comma and should read:

      a. Any new or enhanced dependencies, or any other mechanisms, which
         are intended to increase the likelihood of network-manager
         being installed;

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 16:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 16:06:03 GMT) Full text and rfc822 format available.

Message #30 received at 688772@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: gnome@packages.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 18:02:46 +0200
[Message part 1 (text/plain, inline)]
On 25.09.2012 17:34, Ian Jackson wrote:

>> I am going to try to get the TC to pass another resolution
>> specifically overruling this further decision by the gnome-core
>> maintainers.

Seriously, WTF!
Don't you have better things to do then pissing off everyone?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 16:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 16:27:06 GMT) Full text and rfc822 format available.

Message #35 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Cc: Rene Engelhard <rene@debian.org>
Subject: Re: Please do not unblock gnome-meta just yet
Date: Tue, 25 Sep 2012 17:24:57 +0100
(Discussion redirected to the TC bug report.)

Rene Engelhard writes ("Re: Please do not unblock gnome-meta just yet"):
> On Tue, Sep 25, 2012 at 03:51:17PM +0100, Ian Jackson wrote:
> > The Release Team should be aware that our request to unblock the
> > update to meta-gnome implementing the TC decision does not extend to
> > this latter change to meta-gnome.
> 
> I believe that exceeds your powers. Your decision was implemented
> correct.

I'm not in what way you think I'm exceeding my powers.  I'm pointing
out to the Release Team that the TC resolution does not request that
the Release Team unblock this particular update.

It is of course for the Release Team to make an unblock decision but I
doubt they will make an unblock now; if I were them I would wait to
see whether the TC makes a further resolution.

> Ans n-m - as people might like or not like, I am one who deson't (as a n-m
> user) - is part of GNOME depending on it for the *full* *gnome* IMHO is ok.

As you must be aware, this does not address the arguments made in the
rationale for the TC decision.  There is no logical connection between
n-m becoming part of GNOME core (as defined upstream) as opposed to
just part of GNOME as a whole, and strengthening the gnome
metapackage's Recommends to a Depends.

> > I am going to try to get the TC to pass another resolution
> > specifically overruling this further decision by the gnome-core
> > maintainers.
> 
> I agree with Josselin here completely. Stop the crusade.

Describing a unanimous decision of the Technical Committee as a
crusade is rude, and IMO shows a lack of contact with reality.

Having lost the argument in the TC, the right approach is not to
cause more useless work by deliberately undermining the TC's
decision, and then to hurl insults when we take exception.

You should either allow the TC decision to stand, and implement it
honestly (or allow someone else to do so), or attempt to overrule it
using a General Resolution.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 16:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jeremy Bicha <jbicha@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 16:30:03 GMT) Full text and rfc822 format available.

Message #40 received at 688772@bugs.debian.org (full text, mbox):

From: Jeremy Bicha <jbicha@ubuntu.com>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 12:25:53 -0400
>10. We therefore formally reprimand Josselin Mouette.  We consider his
>   behaviour deliberately obstructive and obtuse.

Is that really necessary?

I mean, if this new resolution gets approved, wouldn't the Tech
Committee have already succeeded in embarrassing the GNOME team in
front of the rest of the Debian project without the need to rudely
call out an individual?

Jeremy Bicha



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 16:36:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sam Hartman <hartmans@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 16:36:06 GMT) Full text and rfc822 format available.

Message #45 received at 688772@bugs.debian.org (full text, mbox):

From: Sam Hartman <hartmans@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 12:26:10 -0400
Ian, I consider myself an uninvolved party in this matter; I don't
really want network-manager installed on my systems, but I'm not
particularly keyed up about it.
I'm not on the TC.
I have been following the issue enough to have an opinion.
I'm reasonably good at process issues, and think I understand the
process issues involved here.

I'm disappointed to immediately see this discussion turn to assumptions
of malice and reprimands.
Would you be willing to consider how the TC as an organization and you
in particular might learn from this incident and be more effective in
the future.
When I find something like this happens to me, I try and put myself in
the head of the other person and ask what they might be doing.

When I do that I hear I find a couple of possibilities.
One is that  the gnome-meta maintainer is trying to  meet the letter of
your intent while trying to work around it.
Would you be willing to set that aside for a moment and think about
other possibilities.

Another possibility is that the gnome-meta folks have been confused and
frustrated by  this whole discussion. They don't see what the big deal
about n-m is and they want to provide a good experience for the users.
They received a decision they don't really like from the TC with some
complex rationale and so they  tried to follow through that rationale
and balance their goals against the rationale the TC stated as best they
could.

In point 3 of your resolution, one of the points you make is that users
don't have an alternative because only the most minimal gnome package
(gnome-session) can be installed without pulling in n-m.

I think  a reasonable person could read that section of the resolution
and conclude that if n-m were pushed into more inclusive meta-packages,
then the argument might be different.

Now, I'll admit that there was probably some  searching going on for how
to fit some goals into  what the TC proposed. I'll admit that there
might have been some ask for forgiveness not permission going on.
But all those things are normal with frustration.

Would you be willing to consider
1) focusing on accomplishing the specific immediate goal you
want--perhaps points 1-6 in your proposed resolution.
And then later having a serious discussion about how you and the TC can
write resolutions  that are more likely to achieve the long-term goals
of the TC while avoiding frustration.
I would be happy to contribute some thoughts there if desired.

Thanks for considering my requests, and thanks for continuing to spend
the time to follow this issue.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 16:57:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 16:57:07 GMT) Full text and rfc822 format available.

Message #50 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Sam Hartman <hartmans@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 17:54:03 +0100
Sam Hartman writes ("Bug#688772: gnome Depends network-manager-gnome"):
> I'm disappointed to immediately see this discussion turn to assumptions
> of malice and reprimands.

Josselin described the TC decision as a "crusade" in his upload.  
I think that is sufficient for me to infer malice.

> One is that  the gnome-meta maintainer is trying to  meet the letter of
> your intent while trying to work around it.

Right...

> Would you be willing to set that aside for a moment and think about
> other possibilities.

OK, fair enough ...

> Another possibility is that the gnome-meta folks have been confused and
> frustrated by  this whole discussion. They don't see what the big deal
> about n-m is and they want to provide a good experience for the users.
> They received a decision they don't really like from the TC with some
> complex rationale and so they  tried to follow through that rationale
> and balance their goals against the rationale the TC stated as best they
> could.

I don't think you could read the rationale that way.  At least, not
without a lot of wilful blindness.  It clearly explains that the
biggest part of the problem was that users who had gnome but not n-m
in squeeze would get n-m when upgrading to wheezy:

  3. [...]  users who have gnome or gnome-core installed but have
     removed or never installed network-manager will have
     network-manager installed during an upgrade from squeeze.

  4. [ description of why network-manager can be problematic ]

  5. The Technical Committee believes that this will cause undesireable
     behavior for upgrades from squeeze, and (of somewhat lesser
     importance) will make it more difficult than necessary for GNOME users
     to swap network management components, something for which there
     appears to be noticable demand.  We therefore believe that
     network-manager should be moved to Recommends in gnome-core.

> I think  a reasonable person could read that section of the resolution
> and conclude that if n-m were pushed into more inclusive meta-packages,
> then the argument might be different.

As I write I don't understand why, if this idea was thought to be a
good one, the maintainers didn't suggest this approach to the TC.
It's not as if there wasn't time, and it's hardly a difficult thing to
think of.

The real answer is of course that if anyone had suggested this as a
possibility our resolution would have unambiguously ruled it out.  So
the purpose of subverting the decision was only served by producing
this change afterwards.

> Now, I'll admit that there was probably some  searching going on for how
> to fit some goals into  what the TC proposed. I'll admit that there
> might have been some ask for forgiveness not permission going on.
> But all those things are normal with frustration.

What kind of emotional state do you think I should have after the
legitimate and unanimous authority of the TC has been undermined in
this way ?  Perhaps I would be frustrated.

> Would you be willing to consider
> 1) focusing on accomplishing the specific immediate goal you
> want--perhaps points 1-6 in your proposed resolution.

To be honest I don't expect to be able to get a 4:1 majority in the TC
in favour of publicly denouncing Josselin.  (Since the resolution as a
whole overrules a maintainer, that would be necessary.)  But I wanted
to put my feelings, which IMO are legitimate, on the record.

> And then later having a serious discussion about how you and the TC can
> write resolutions  that are more likely to achieve the long-term goals
> of the TC while avoiding frustration.

Normally we write our resolutions with the intent that people will not
subvert them, or work against their intent.  That is after all
required by the Constitution.

If we need to make them watertight against malicious and lawyerish
interpretation, then we will need to anticipate every way in which the
maintainers might try to subvert our intent.  Along the lines of point
6 in my proposal.

I think it would be very rude to routinely write that kind of thing in
overruling resolutions.  It it amounts to assuming and anticipating
bad faith on the part of the overruled maintainer.

> I would be happy to contribute some thoughts there if desired.

Please do.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 17:54:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 17:54:06 GMT) Full text and rfc822 format available.

Message #55 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 18:51:42 +0100
Andreas Barth writes ("Re: Bug#688772: gnome Depends network-manager-gnome"):
> However, I'm not sure if 6. is too detailed, or should just be written
> as 
>     a. Any way which increases the likelihood of network-manager
>        being installed (this includes also messages, user-face
>        warnings etc)

6 was a list of the further ways I thought of to subvert the
decision.  I do have the catch-all as well, so I think my list is
broader.  I do think it's necessary to preempt sabotage of non-nm
gnome systems.

> Also the first sentence of 9. might need to be dropped. Perhaps adding
> something like "using words like 'crusade' together with implementing
> a tech ctte decision is inappropriate" might be better?

TBH I think it unlikely that enough of our colleagues will agree to
even 9.  And it may be unnecessary, given the rest.  I think 8 is
necessary.

I don't think mentioning the rude language in the TC resolution is
really appropriate.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 18:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 18:06:03 GMT) Full text and rfc822 format available.

Message #60 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 11:03:23 -0700
Tollef Fog Heen <tfheen@err.no> writes:
> ]] Ian Jackson 

>> 10. We therefore formally reprimand Josselin Mouette.  We consider his
>>    behaviour deliberately obstructive and obtuse.

> I don't think it's within the mandate of the tech-ctte to reprimand any
> developers.

I agree.

The duties of the tech-ctte do verge on project governance in some places,
but by and large our goal is technical decision-making, and where we can
I'd rather keep the resolutions focused on that decision unless the social
aspects (like maintainership disputes) have been explicitly invoked.  And
even what governance role we have doesn't include reprimands or other
types of censure, IMO.  (I also personally am extremely uncomfortable with
formal censure in a volunteer project, even apart from this particular
case where it feels like an argument that spiraled out of control rather
than something worthy of formal notice.)

Also, in general, I agree with Sam's message.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 18:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jeremy Bicha <jbicha@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 18:15:05 GMT) Full text and rfc822 format available.

Message #65 received at 688772@bugs.debian.org (full text, mbox):

From: Jeremy Bicha <jbicha@ubuntu.com>
To: 688772 <688772@bugs.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 14:11:17 -0400
On 25 September 2012 13:51, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> TBH I think it unlikely that enough of our colleagues will agree to
> even 9.  And it may be unnecessary, given the rest.  I think 8 is
> necessary.
>
> I don't think mentioning the rude language in the TC resolution is
> really appropriate.

Why do you have the authority to use language like "We therefore
formally reprimand Josselin Mouette.  We consider his
behaviour deliberately obstructive and obtuse." but he is not allowed
to use the word "Crusade"? "Crusade" does seem accurate for definition
#3 of http://dictionary.reference.com/browse/crusade

And if you don't think that the Tech Committee is likely to agree to
an unnecessary part of your proposal, why are you wasting their time
by including it?

Jeremy



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 18:27:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 18:27:07 GMT) Full text and rfc822 format available.

Message #70 received at 688772@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 19:43:55 +0200
* Ian Jackson (ijackson@chiark.greenend.org.uk) [120925 19:33]:
> Andreas Barth writes ("Re: Bug#688772: gnome Depends network-manager-gnome"):
> > Though I think that the change is against our decision, I'd prefer
> > dropping that line from our next decision.
> 
> OK.  Do you have an opinion about the rest of it ?

The spirit is fine.

However, I'm not sure if 6. is too detailed, or should just be written
as 
    a. Any way which increases the likelihood of network-manager
       being installed (this includes also messages, user-face
       warnings etc)
    b. Any other change which is contrary to the spirit or intent of
       either our previous resolution in #681834 or this resolution.


Also the first sentence of 9. might need to be dropped. Perhaps adding
something like "using words like 'crusade' together with implementing
a tech ctte decision is inappropriate" might be better?


Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 19:30:19 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 19:30:19 GMT) Full text and rfc822 format available.

Message #75 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 12:27:27 -0700
I've been thinking about this over lunch, and I do feel like the gnome
metapackage is substantively different than the gnome-core metapackage.
I'm not sure if it's sufficiently different to warrant a different
decision, but it does seem different enough to warrant a separate
discussion.

The historic point of the gnome metapackage is not to just install the
base machinery of GNOME in the same way that gnome-core is.  It's rather
to give the user a complete desktop environment built around GNOME.  There
have historically been all sorts of applications in there that people may
or may not use.  It's a fairly "heavy-weight" metapackage; it pulls in
everything from office suites to a mail client.

We still have the upgrade problem with network-manager from squeeze gnome
to wheezy gnome, but I would expect, if I had the full gnome metapackage
installed, for quite a lot to potentially change across versions: new
applications added or dropped, new implementations of particular common
tasks to be blessed upstream, etc.  So I'm not sure if that's as strong of
a reason to stick with Recommends in that metapackage.

To be clear, if I were the GNOME maintainers, I would use Recommends.  But
I'm not, and I'd rather that they make the call as much as possible.
Putting aside the communication breakdowns and the heated arguments and so
forth, if just the gnome metapackage issue in its current form had come to
us cold, I'm trying to work through what decision I'd make.

I'm wondering if we should just document the change to the gnome
metapackage in the release notes.  I think there's really something to be
said for treating this as a compromise position.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 25 Sep 2012 20:21:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 25 Sep 2012 20:21:11 GMT) Full text and rfc822 format available.

Message #80 received at 688772@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: Russ Allbery <rra@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 25 Sep 2012 22:18:24 +0200
* Russ Allbery (rra@debian.org) [120925 21:30]:
> I'm wondering if we should just document the change to the gnome
> metapackage in the release notes.  I think there's really something to be
> said for treating this as a compromise position.

In case the packages stay as they are right now, I think putting the
changes into the release notes would be the standard procedure (as any
other larger change). However, having said this, release notes are not
read as much as they should, or only after people notice issues. (I'm
more asking myself why n-m couldn't be better integrated into Debian
and more happily being just installed, which would be the better
answer to that - but that's probably not for the tech ctte, even if it
would be nice.)


Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 26 Sep 2012 12:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 26 Sep 2012 12:18:03 GMT) Full text and rfc822 format available.

Message #85 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 26 Sep 2012 13:16:13 +0100
Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):
> I've been thinking about this over lunch, and I do feel like the gnome
> metapackage is substantively different than the gnome-core metapackage.
> I'm not sure if it's sufficiently different to warrant a different
> decision, but it does seem different enough to warrant a separate
> discussion.

Most of the points that were determinative of our decision on
gnome-core apply to gnome too.

> The historic point of the gnome metapackage is not to just install the
> base machinery of GNOME in the same way that gnome-core is.  It's rather
> to give the user a complete desktop environment built around GNOME.  There
> have historically been all sorts of applications in there that people may
> or may not use.  It's a fairly "heavy-weight" metapackage; it pulls in
> everything from office suites to a mail client.

All of that is fine but of course as you yourself wrote:

  4. For most applications and components, the only drawback of this would
     be some additional disk space usage, since the application, despite
     being installed, wouldn't need to be used.  However, network-manager
     assumes that, if it is installed, it should attempt to manage the
     system's network configuration.  It attempts to avoid overriding local
     manual configuration, but it isn't able to detect all cases where the
     user is using some other component or system to manage networking.
     The user has to take separate, explicit (and somewhat unusual for the
     average user) action to disable network-manager after it has been
     installed.

So n-m is special.

> We still have the upgrade problem with network-manager from squeeze gnome
> to wheezy gnome, but I would expect, if I had the full gnome metapackage
> installed, for quite a lot to potentially change across versions: new
> applications added or dropped, new implementations of particular common
> tasks to be blessed upstream, etc.  So I'm not sure if that's as strong of
> a reason to stick with Recommends in that metapackage.

The point is that if a user deliberately deinstalls something (as
would have to be the case with a violated Recommends in squeeze), we
should not undo that decision willy-nilly.

From the point of view of the gnome metapackage, I can see no
justification at all for the increased strictness of the dependency.
The fact that GNOME upstream have decreed that n-m is part of "GNOME
Core" rather than just part of "GNOME" isn't relevant to the gnome
metapackage, except insofar as it means that the dependency should
move down onto gnome-core.

> To be clear, if I were the GNOME maintainers, I would use Recommends.  But
> I'm not, and I'd rather that they make the call as much as possible.

The issues seem very similar to me.  It is perhaps less important that
people be able to conveniently install a whole application suite
without getting n-m.

But the upgrade issue is the same and will affect nearly as many
users.  And on the face of it it is simply entirely wrong to upgrade
the dependency.  I can see no justification for it.  And the
maintainers haven't even provided one!

> Putting aside the communication breakdowns and the heated arguments and so
> forth, if just the gnome metapackage issue in its current form had come to
> us cold, I'm trying to work through what decision I'd make.

I would have made the same decision.

But I'm not convinced that this is the right basis to think about it.
It is not a good precedent to set that if a matter is brought to the
TC, the maintainer who loses the debate in the TC will do something
which undermines the effect of the TC decision and which wasn't
proposed in the TC discussion.

Having taken hold of the matter and overruled the maintainer, we have
a responsibility to see through the consequences, and to avoid
backsliding by the maintainer.

> I'm wondering if we should just document the change to the gnome
> metapackage in the release notes.  I think there's really something to be
> said for treating this as a compromise position.

What you are proposing is a compromise between doing the right thing
for our users, and upholding the autonomy of the maintainer.

That is contrary to our stated principles.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 26 Sep 2012 13:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sam Hartman <hartmans@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 26 Sep 2012 13:24:03 GMT) Full text and rfc822 format available.

Message #90 received at 688772@bugs.debian.org (full text, mbox):

From: Sam Hartman <hartmans@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 26 Sep 2012 09:14:44 -0400
>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
Hi.
I'm very pleased that you took the time to write a thoughtful response
to my message.
I appreciate that you're trying to work with me even though the
situation is frustrating and you feel under pressure to work towards the
solution you want in time for wheezy.

    >> Now, I'll admit that there was probably some searching going on
    >> for how to fit some goals into what the TC proposed. I'll admit
    >> that there might have been some ask for forgiveness not
    >> permission going on.  But all those things are normal with
    >> frustration.

    Ian> What kind of emotional state do you think I should have after
    Ian> the legitimate and unanimous authority of the TC has been
    Ian> undermined in this way ?  Perhaps I would be frustrated.

So, you're frustrated because you went to a lot of work  and you feel
that someone is working to undermine your work?

You'd like to express those feelings and get them onto the record?
If I've got that right, I'd ask you to think about various ways of
accomplishing those goals.
For myself, I think I might have better luck if I tried to connect with
the  gnome-meta maintainer and help them understand how I felt.
I would hope that by achieving that connection they'd be more likely to
consider their impact on me in the future.
My hope would be to get to a state where they say "Sam tried to work
with us even though we disagreed and the decision was against us so I
should consider my impact on him."
I think that's going to be more productive than someone who thinks "Well,
Sam's going to dislike this and yell at me."

So I might right a message to the gnome-meta maintainer (copying a list
if I felt I needed to do that) talking about how I was frustrated and
how I was having a hard time finding an interpretation that was not
about subverting the decision.
I'd probe for misunderstandings as well as try and build an
understanding of the emotional impact on me if there was no
misunderstanding in fact.

Everyone has different communication styles.  What works for me might
seem verbose and silly to someone else.  However, I'd ask that you
consider the effects of communication both on others (even if you don't
feel you're getting that from them) and on accomplishing your goals
whatever they are.
    >> And then later having a serious discussion about how you and the
    >> TC can write resolutions that are more likely to achieve the
    >> long-term goals of the TC while avoiding frustration.

    Ian> Normally we write our resolutions with the intent that people
    Ian> will not subvert them, or work against their intent.  That is
    Ian> after all required by the Constitution.

    Ian> If we need to make them watertight against malicious and
    Ian> lawyerish interpretation, then we will need to anticipate every
    Ian> way in which the maintainers might try to subvert our intent.
    Ian> Along the lines of point 6 in my proposal.

So, you're concerned that if you try to make the resolutions water-tight
that others might wish for more respect?

That makes a lot of sense to me.
I think  though that  whenever a maintainer is overruled there is likely
to be a lot of frustration and disappointment.
That can get in the way even when there is no malice.
I might have added something like "The TC requests that the gnome-meta
maintainer confirm that upgrading from squeeze to wheezy without
network-manager installed does not install network-manager. We'd be
happy to assist with this work if desired."
I might move some of the rationale text out of the resolution proper.
So the resolution focuses on the specific actions as well as the desired
state in the decision part and avoids too much other text.

Obviously others would approach things differently. For example, I think
you considered the rationale portion important to have in the body of
the resolution.

I think though that discussing the desirability of the upgrade behavior
in the decision part would not be overly-legalistic. If I were
overruled, I don't think a nicely worded request like that would
increase my frustration or disappointment.

Thanks again for your time.
I wish you the best of luck on quickly reaching a decision within the
TC.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 01:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 01:03:03 GMT) Full text and rfc822 format available.

Message #95 received at 688772@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: debian-ctte@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 03:01:23 +0200
[Message part 1 (text/plain, inline)]
> Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):
>> I've been thinking about this over lunch, and I do feel like the gnome
>> metapackage is substantively different than the gnome-core metapackage.
>> I'm not sure if it's sufficiently different to warrant a different
>> decision, but it does seem different enough to warrant a separate
>> discussion.

One of the major complaints was, that there is no longer a meta-package
which gives a sufficient and complete enough GNOME desktop environment
without a NM dependency. The gnome-session package was considered to be
not appropriate.
Joss solution definitely addresses that while trying to preserve our
vision what we (as a team) and upstream define a default GNOME environment.

Assuming bad faith and the language that was chosen by Ian really
troubles me, especially his attempt to reprimand Joss.
Somehow I have the feeling Ian is taken this whole issue to personally
(which he admits himself) and that clouds his judgements on a technical
level.

That all said, and I hope we can leave this behind us, as this "infight"
leads nowhere.



> Most of the points that were determinative of our decision on
> gnome-core apply to gnome too.
> 
>> The historic point of the gnome metapackage is not to just install the
>> base machinery of GNOME in the same way that gnome-core is.  It's rather
>> to give the user a complete desktop environment built around GNOME.  There
>> have historically been all sorts of applications in there that people may
>> or may not use.  It's a fairly "heavy-weight" metapackage; it pulls in
>> everything from office suites to a mail client.
> 
> All of that is fine but of course as you yourself wrote:
> 
>   4. For most applications and components, the only drawback of this would
>      be some additional disk space usage, since the application, despite
>      being installed, wouldn't need to be used.  However, network-manager
>      assumes that, if it is installed, it should attempt to manage the
>      system's network configuration.  It attempts to avoid overriding local
>      manual configuration, but it isn't able to detect all cases where the
>      user is using some other component or system to manage networking.
>      The user has to take separate, explicit (and somewhat unusual for the
>      average user) action to disable network-manager after it has been
>      installed.
> 
> So n-m is special.

Actually, NM is not really special. The "gnome" and "gnome-core"
meta-packages install a wide variety of applications and infrastructure,
which are

a/ active by default. E.g. components like avahi-daemon are started by
default.

b/ being used as default application after being installed, e.g. via
mime associations and default settings. The GNOME desktop environment
sets up a default web browser, email client, Texteditor, Music Player
etc. Whenever you try to open a file, a link, those default applications
will be opened. The user needs to explicitely configure other
alternatives. This can mean changing dconf/gconf settings, and requires,
as Ian called it, "unusual, explicit actions".
So it is false to say that those applications only use some disk space
and aren't noticeable when not used.
Indeed, I would argue that for most users, the default choice we set for
the web browser, email client, video or music player, etc. is a much
more visible and important issue.

> But the upgrade issue is the same and will affect nearly as many
> users.  And on the face of it it is simply entirely wrong to upgrade
> the dependency.  I can see no justification for it.  And the
> maintainers haven't even provided one!

This is simply wrong. The GNOME team (and others) has provided a
justification on several occasions. It's simply that Ian conveniently
dismisses/ignores that.
The reason the Recommends was upgraded to a Depends is twofold:
a/ a much tighter integration of NM into the desktop compared to
squeeze.
This involves integration into the Shell, gnome-control-center,
applications making more extended usage of NM, e.g. PackageKit being
more clever and trying to avoid costly updates when being online via
Mobile Broadband. Just to name a few examples.

b/ a change in how our users have become more mobile.
Wireless is a commodity nowadays, Mobile broadband for many is an
essential feature they use on a daily basis. Or the road warrior which
needs VPN access. Only NM provides these features today.

> What you are proposing is a compromise between doing the right thing
> for our users, and upholding the autonomy of the maintainer.

Changing the Depends to Recommends was never the right solution to the
real issue, imo. The underlying problem is that:

a/ some users will always be unhappy with the choices we make for those
meta-packages. Some want A instead of B, some want no C at all, some
want D being added and such. It is simply impossible to please everyone.
My simple recommendation for such users is, to juse not use those
meta-packages then and pick and chose what you want instead.
You do that *once* during a dist-upgrade and you can take the
meta-package we provide as input. So this isn't a lot effort.
I actually somehow doubt, that there are a lot of squeeze users, which
have the whole gnome meta-package installed but decided to remove NM.
So this upgrade scenario which was mentioned as one the main points
isn't a major issue in practice.

b/ among those users are some that are unhappy with NM. That doesn't
need to be based on actual, technical issues. Some just don't like it.
As for users which have real problems with NM, this is something we can
fix, if we know about those problems. So far, I don't remember those
users providing more details, so I can only tell what I know about:
 1/ NM's handling of /e/n/i when being installed, where it comments out
plain DHCP interface configurations so it can manage that interface.
Some users don't like that automatic mangling.
 2/ NM's handling of /etc/resolv.conf. When you have both ifupdown and
NM manage a (different) device, it can happen that NM overwrites or
clears /etc/resolv.conf.

Both those issues are currently being addressed.
for 1/ we have patches pending for d-i, so we no longer need that
/e/n/i mangling in NM or at least can make it optional being hidden
behind a debconf prompt.
for 2/ I plan to change how NM manges /etc/resolv.conf in the presence
unmanaged devices and be more conservative.
If there are other issues, then I urge anybody to report them. I/We
can't fix issues which we don't know about.

I would really appreciate, if the ctte could leave this case as it is
now and let us concentrate our efforts on fixing real issues and bugs
instead of having to spend our time writing several pages long emails
where we need to defend our work. The lack of trust that was shown
towards us has definitely saddened me and taken out all the fun and
enthusiasm I have for Debian.

Let's not work against each other.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 10:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 10:36:03 GMT) Full text and rfc822 format available.

Message #100 received at 688772@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Russ Allbery <rra@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 11:32:25 +0100
On Tue, Sep 25, 2012 at 12:27:27PM -0700, Russ Allbery wrote:
> We still have the upgrade problem with network-manager from squeeze gnome
> to wheezy gnome, but I would expect, if I had the full gnome metapackage
> installed, for quite a lot to potentially change across versions: new
> applications added or dropped, new implementations of particular common
> tasks to be blessed upstream, etc.  So I'm not sure if that's as strong of
> a reason to stick with Recommends in that metapackage.
> 
> To be clear, if I were the GNOME maintainers, I would use Recommends.  But
> I'm not, and I'd rather that they make the call as much as possible.
> Putting aside the communication breakdowns and the heated arguments and so
> forth, if just the gnome metapackage issue in its current form had come to
> us cold, I'm trying to work through what decision I'd make.

I agree that the issue is less serious in gnome than in gnome-core.
Still, the upgrade problem seems unchanged.  The users who removed
network-manager in squeeze presumably made an explicit decision to do
so, since package managers would have honoured the Recommends by
default; I'm really troubled by overruling that in this way.

I think I would have ended up voting the same way if the original
question put to us had been about gnome rather than gnome-core.

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 11:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 11:03:06 GMT) Full text and rfc822 format available.

Message #105 received at 688772@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 12:01:32 +0100
On Thu, Sep 27, 2012 at 03:01:23AM +0200, Michael Biebl wrote:
> Ian Jackson wrote:
> > What you are proposing is a compromise between doing the right thing
> > for our users, and upholding the autonomy of the maintainer.
> 
> Changing the Depends to Recommends was never the right solution to the
> real issue, imo. The underlying problem is that:
> 
> a/ some users will always be unhappy with the choices we make for those
> meta-packages. Some want A instead of B, some want no C at all, some
> want D being added and such. It is simply impossible to please everyone.
> My simple recommendation for such users is, to juse not use those
> meta-packages then and pick and chose what you want instead.
> You do that *once* during a dist-upgrade and you can take the
> meta-package we provide as input. So this isn't a lot effort.

Hmm.  This is a common statement regarding metapackages - I've made it
myself in the past - but my experience is that it isn't really as true
as we'd like to think.  If you aren't familiar with the details of a
subsystem, removing its metapackage just for the sake of avoiding a
single troublesome package means that you end up taking on the task of
identifying all that subsystem's essential components in future
upgrades; and if you miss one, your system may well behave oddly after
the next release and it's quite possible that the maintainers won't have
a great deal of sympathy since you brought it upon yourself.  It can be
a quick road to a world of pain.  If you're a developer, maybe it's not
so hard, but there are people who have good and valid reasons to be
uncomfortable with one choice or another who aren't deeply familiar with
the whole subsystem.

Our practice in Ubuntu is to try to subdivide metapackages into
essential components - those where we simply aren't prepared to call the
system, say, an "Ubuntu desktop" without them - and ones that are merely
strongly recommended, where we can reasonably envisage alternatives.
network-manager has long fallen into the second category, despite its
usefulness; as do many of the default applications, because those are
things many people choose to substitute for good and valid reasons.
Now, I know that Ubuntu isn't Debian and Unity isn't GNOME Shell and all
that, and I'm certainly aware that Ubuntu doesn't get this totally right
either, but I do think there's a strong case for erring on the side of
using Recommends in metapackages where there is contention.  It just
makes users' lives easier in so many situations.

> I actually somehow doubt, that there are a lot of squeeze users, which
> have the whole gnome meta-package installed but decided to remove NM.

Unfortunately popcon doesn't have this kind of correlation data.
network-manager is installed on more systems than gnome, but I'm not
sure how much information we can derive from that since it'll have some
users from other environments too.  It does seem to be something that's
come up a fair bit anecdotally, though.  For me, if I were the
metapackage maintainer, the mere presence of a giant argument about one
of the components of my metapackage would be enough to make me
reconsider, regardless of whether I agreed with the reasoning.

If it were somehow to be established that this is indeed vanishingly
rare, I would probably reluctantly withdraw my objection.  We can assert
things at each other until the cows come home, but I don't honestly see
how it can be established clearly.  Sometimes it happens that as a
maintainer you paint yourself into a corner one way or another, and
sometimes you just have to live with it because the upgrade experience
matters.  It's not unusual for maintainers to create new packages in
order to work around this.  (For example, I would have no objection to a
solution whereby the GNOME team created a new metapackage which has
stricter dependencies even on a wider range of things than
network-manager, and made that be part of fresh installations of wheezy;
that would seem quite reasonable and would comfortably sidestep any
upgrade questions.)

> I would really appreciate, if the ctte could leave this case as it is
> now and let us concentrate our efforts on fixing real issues and bugs
> instead of having to spend our time writing several pages long emails
> where we need to defend our work. The lack of trust that was shown
> towards us has definitely saddened me and taken out all the fun and
> enthusiasm I have for Debian.

Well, I understand that the GNOME team are frustrated - it's quite plain
to see - but this goes both ways.  I'm saddened by the attempt to find a
solution that at least partially satisfied the letter of the TC's
resolution while going against its spirit, and the apparent lack of
respect for the dispute resolution arrangements that we all surely
implicitly signed up to when we joined Debian.  We're trying to make
Debian better too.

I don't think we enjoy having to extend this debate any more than you
do; but really it would have been much more helpful to propose
alternative solutions in advance so that we could discuss them.  Did
anyone suggest the option of putting the Depends in gnome during the
previous TC discussion?  If so, I certainly didn't see it.

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 11:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 11:06:03 GMT) Full text and rfc822 format available.

Message #110 received at 688772@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Jeremy Bicha <jbicha@ubuntu.com>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 12:03:46 +0100
On Tue, Sep 25, 2012 at 12:25:53PM -0400, Jeremy Bicha wrote:
> Ian Jackson wrote:
> >10. We therefore formally reprimand Josselin Mouette.  We consider his
> >   behaviour deliberately obstructive and obtuse.
> 
> Is that really necessary?
> 
> I mean, if this new resolution gets approved, wouldn't the Tech
> Committee have already succeeded in embarrassing the GNOME team in
> front of the rest of the Debian project without the need to rudely
> call out an individual?

I don't think it's likely to be helpful, so IMO it should be omitted.

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 11:33:03 GMT) Full text and rfc822 format available.

Message #113 received at 688772@bugs.debian.org (full text, mbox):

From: Jakub Wilk <jwilk@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 13:28:04 +0200
* Colin Watson <cjwatson@debian.org>, 2012-09-27, 12:01:
>>I actually somehow doubt, that there are a lot of squeeze users, which 
>>have the whole gnome meta-package installed but decided to remove NM.
>Unfortunately popcon doesn't have this kind of correlation data.

It can be extracted from the raw popcon data (which isn't publicly 
accessible, for obvious reasons).

I'll give you the numbers later today.

-- 
Jakub Wilk



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 12:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 12:45:03 GMT) Full text and rfc822 format available.

Message #118 received at 688772@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 14:40:25 +0200
Hi,

On Wed, 26 Sep 2012, Ian Jackson wrote:
> But I'm not convinced that this is the right basis to think about it.
> It is not a good precedent to set that if a matter is brought to the
> TC, the maintainer who loses the debate in the TC will do something
> which undermines the effect of the TC decision and which wasn't
> proposed in the TC discussion.
> 
> Having taken hold of the matter and overruled the maintainer, we have
> a responsibility to see through the consequences, and to avoid
> backsliding by the maintainer.

http://bugs.debian.org/640874

$ apt-get source leave
[...]
$ head -n 1 leave-1.12/debian/rules 
#!/bin/sh -e

It seems pretty clear that the TC is currently not making sure that his
decisions get acted upon (and this despite Jakub who pointed out the
mistake in https://lists.debian.org/debian-ctte/2012/08/msg00001.html).

But in this particular case, you took it in a very personal way and
made the effort to follow through. IMO this discrepancy and your 
antagonistic attitude is harming the committee's reputation.

I agree that Josselin's decision was a poor one but frankly I would much
rather see people work on better N-M integration. If the time spent on
those discussions would have been invested in getting d-i to write
proper N-M configuration entries, some of the reasons why N-M is unpopular
in Debian would have been squashed.

/me hopes Michael Biebl is not demotivated by this series of GR
and ends up working with Sorina to get this fixed:
https://lists.debian.org/debian-boot/2012/09/msg00252.html

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 13:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefano Zacchiroli <leader@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 13:15:03 GMT) Full text and rfc822 format available.

Message #123 received at 688772@bugs.debian.org (full text, mbox):

From: Stefano Zacchiroli <leader@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 15:12:06 +0200
[Message part 1 (text/plain, inline)]
On Thu, Sep 27, 2012 at 12:01:32PM +0100, Colin Watson wrote:
> > I would really appreciate, if the ctte could leave this case as it is
> > now and let us concentrate our efforts on fixing real issues and bugs
> > instead of having to spend our time writing several pages long emails
> > where we need to defend our work. The lack of trust that was shown
> > towards us has definitely saddened me and taken out all the fun and
> > enthusiasm I have for Debian.
> 
> Well, I understand that the GNOME team are frustrated - it's quite plain
> to see - but this goes both ways.  I'm saddened by the attempt to find a
> solution that at least partially satisfied the letter of the TC's
> resolution while going against its spirit, and the apparent lack of
> respect for the dispute resolution arrangements that we all surely
> implicitly signed up to when we joined Debian.  We're trying to make
> Debian better too.

I'm following this discussion attentively, but I didn't have anything to
add up to now. FWIW, I've very much appreciated Sam Hartman's first post
and similar comments by other participants on both "sides".

There is clearly frustration on both those sides.  For the maintainers
it is not easy to be overruled, nor it is pleasant to perceive something
as a "crusade" (as Joss put it) against them. No matter whether the
perception is correct or not, the feeling is there and need to be dealt
with.  For the tech-ctte, and for everyone else who believe in it as a
dispute resolution body (which, I really have to observe, shall be the
case for every member of the Debian Project), it is not acceptable to
have the impression that the maintainers have tried to "work around" the
spirit of a resolution. Again: no matter whether that is true or not,
the feeling is on the table and need to be dealt with.  There are no
magic solutions for this. Please just don't assume the others are acting
against you and try to see if at least part of what they are proposing
could in fact benefit Debian users.

According to what I've read up to now, it seems that the distinction
between gnome-core and gnome could use further discussion. Surely it is
a discussion that could have happened before, and _would_ probably have
happened if people have pointed that out earlier. But it is happening
now, and it is useful. Good!

What worries me is the apparent lack of an important information: the
greater goal/mission that the GNOME team have in mind.  OTOH, the spirit
of the recent tech-ctte decision can be summarized as: "allow users to
opt-out of N-M + respect past (Squeeze) user choices to do so".

I'm at loss at formulating a similarly succinct goal for the GNOME team.
Maybe members of the GNOME team can help with that?

For instance, Michael has written a few post ago:

> Joss solution definitely addresses that while trying to preserve our
> vision what we (as a team) and upstream define a default GNOME
> environment.

*If* the main point is adhering to an agreed upon notion of "*default*
GNOME environment", any easy to use opt-out mechanism (including
Recommends) should work, no? So I guess I am, and others with me,
missing a relevant part of GNOME team's goals on this matter. If these
goals can easily be stated, maybe we won't even need further votes and
imposed decisions. Maybe we can just find a consensual course of action
that both respect user choices *and* adhere to GNOME team greater goals.

Thanks for considering,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 16:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 16:21:03 GMT) Full text and rfc822 format available.

Message #128 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 17:17:31 +0100
Raphael Hertzog writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Wed, 26 Sep 2012, Ian Jackson wrote:
> > Having taken hold of the matter and overruled the maintainer, we have
> > a responsibility to see through the consequences, and to avoid
> > backsliding by the maintainer.
> 
> http://bugs.debian.org/640874
> 
> $ apt-get source leave
> [...]
> $ head -n 1 leave-1.12/debian/rules 
> #!/bin/sh -e

The Constitution is quite clear that the maintainer is not required to
do the work.  So until there is a patch available to leave available
implement the TC-mandated policy requirement this bug will remain
unfixed.

Note also that in this case we didn't specifically override the leave
maintainer's decision not to comply with policy.

Even if we had, in general I would expect a fair proportion of
overrulings to require NMUs.  It would be too much to expect
maintainers to always have the fortitude to implement a decision they
didn't agree with.  Naturally the complainants should give a
maintainer the time and space to make the upload themselves, but after
a reasonable interval I think an upload to a DELAYED queue is entirely
appropriate.

I don't think it is necessarily the TC members' job to make that NMU,
but I guess it could help in some situations from a social point of
view to have the upload come from one of the TC.  And I think it would
be too much to ask TC members to (for example) implement the required
rewrite of the leave rules file.

However, the management of the bug report(s) is not ideal.  As the bug
was reassigned to TC and then closed when the TC made its decision,
there is not currently a bug open against leave.  Please feel free to
clone #688772 into a new bug and reopen it and assign it to leave.

> It seems pretty clear that the TC is currently not making sure that his
> decisions get acted upon (and this despite Jakub who pointed out the
> mistake in https://lists.debian.org/debian-ctte/2012/08/msg00001.html).

I'm sorry that we didn't spot that this needed further action.  I read
Jakub's message in support, and didn't follow through to the link,
which I read not as a separate point needing action but rather simply
as evidence he was advancing in support of my proposal.  Since no-one
seemed to disagree with the proposal (apart from mailing list problems
now fixed) I didn't go and read the background.

But there is no reason why anyone else can't help us out with this bug
gardening.  If you don't have time or inclination to do the bug
gardening for "leave" please let me know and I will do it.

Ian.

PS: I would like to point out that as I myself don't actually agree
with the TC policy decision in #688772, again I am I think excused
from a requirement to do the work to help implement it.  I don't think
me insisting on this point is valuable, at least when we're just
talking about bug gardening.  My inclination to rewrite the leave
rules file is limited, though.  Do you think that's reasonable ?



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 16:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 16:24:03 GMT) Full text and rfc822 format available.

Message #133 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 17:20:37 +0100
In my last mail I referred several times to #688772 when I meant
#640874.  Sorry for the confusion.  Here is a fixed copy:

Ian Jackson writes ("Re: Bug#688772: gnome Depends network-manager-gnome"):
> Raphael Hertzog writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > On Wed, 26 Sep 2012, Ian Jackson wrote:
> > > Having taken hold of the matter and overruled the maintainer, we have
> > > a responsibility to see through the consequences, and to avoid
> > > backsliding by the maintainer.
> > 
> > http://bugs.debian.org/640874
> > 
> > $ apt-get source leave
> > [...]
> > $ head -n 1 leave-1.12/debian/rules 
> > #!/bin/sh -e
> 
> The Constitution is quite clear that the maintainer is not required to
> do the work.  So until there is a patch available to leave available
> implement the TC-mandated policy requirement this bug will remain
> unfixed.
> 
> Note also that in this case we didn't specifically override the leave
> maintainer's decision not to comply with policy.
> 
> Even if we had, in general I would expect a fair proportion of
> overrulings to require NMUs.  It would be too much to expect
> maintainers to always have the fortitude to implement a decision they
> didn't agree with.  Naturally the complainants should give a
> maintainer the time and space to make the upload themselves, but after
> a reasonable interval I think an upload to a DELAYED queue is entirely
> appropriate.
> 
> I don't think it is necessarily the TC members' job to make that NMU,
> but I guess it could help in some situations from a social point of
> view to have the upload come from one of the TC.  And I think it would
> be too much to ask TC members to (for example) implement the required
> rewrite of the leave rules file.
> 
> However, the management of the bug report(s) is not ideal.  As the bug
> was reassigned to TC and then closed when the TC made its decision,
> there is not currently a bug open against leave.  Please feel free to
> clone #640874 into a new bug and reopen it and assign it to leave.
> 
> > It seems pretty clear that the TC is currently not making sure that his
> > decisions get acted upon (and this despite Jakub who pointed out the
> > mistake in https://lists.debian.org/debian-ctte/2012/08/msg00001.html).
> 
> I'm sorry that we didn't spot that this needed further action.  I read
> Jakub's message in support, and didn't follow through to the link,
> which I read not as a separate point needing action but rather simply
> as evidence he was advancing in support of my proposal.  Since no-one
> seemed to disagree with the proposal (apart from mailing list problems
> now fixed) I didn't go and read the background.
> 
> But there is no reason why anyone else can't help us out with this bug
> gardening.  If you don't have time or inclination to do the bug
> gardening for "leave" please let me know and I will do it.
> 
> Ian.
> 
> PS: I would like to point out that as I myself don't actually agree
> with the TC policy decision in #640874, again I am I think excused
> from a requirement to do the work to help implement it.  I don't think
> me insisting on this point is valuable, at least when we're just
> talking about bug gardening.  My inclination to rewrite the leave
> rules file is limited, though.  Do you think that's reasonable ?



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 16:24:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 16:24:05 GMT) Full text and rfc822 format available.

Message #138 received at 688772@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 688772@bugs.debian.org
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 17:21:08 +0100
On Thu, Sep 27, 2012 at 02:40:25PM +0200, Raphael Hertzog wrote:
> On Wed, 26 Sep 2012, Ian Jackson wrote:
> > But I'm not convinced that this is the right basis to think about it.
> > It is not a good precedent to set that if a matter is brought to the
> > TC, the maintainer who loses the debate in the TC will do something
> > which undermines the effect of the TC decision and which wasn't
> > proposed in the TC discussion.
> > 
> > Having taken hold of the matter and overruled the maintainer, we have
> > a responsibility to see through the consequences, and to avoid
> > backsliding by the maintainer.
> 
> http://bugs.debian.org/640874
> 
> $ apt-get source leave
> [...]
> $ head -n 1 leave-1.12/debian/rules 
> #!/bin/sh -e
> 
> It seems pretty clear that the TC is currently not making sure that his
> decisions get acted upon (and this despite Jakub who pointed out the
> mistake in https://lists.debian.org/debian-ctte/2012/08/msg00001.html).

Apologies for missing this.  I've now sent that bug back to the leave
maintainer.

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 16:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 16:27:03 GMT) Full text and rfc822 format available.

Message #143 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 17:24:17 +0100
Ian Jackson writes ("Re: Bug#688772: gnome Depends network-manager-gnome"):
> In my last mail I referred several times to #688772 when I meant
> #640874.  Sorry for the confusion.  Here is a fixed copy:

I wrote:

> Ian Jackson writes ("Re: Bug#688772: gnome Depends network-manager-gnome"):
> > But there is no reason why anyone else can't help us out with this bug
> > gardening.  If you don't have time or inclination to do the bug
> > gardening for "leave" please let me know and I will do it.

I see Colin has done it.  Thanks, Colin.

(I didn't do it myself right away because I've been doing nothing but
fighting awful websites all day and have become very error-prone; see
also my mistaken reference to the wrong bug number.)

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 16:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 16:39:03 GMT) Full text and rfc822 format available.

Message #148 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: Stefano Zacchiroli <leader@debian.org>
Cc: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 18:36:01 +0200
Hi Stefano,

Le jeudi 27 septembre 2012 à 15:12 +0200, Stefano Zacchiroli a écrit : 
> What worries me is the apparent lack of an important information: the
> greater goal/mission that the GNOME team have in mind.  OTOH, the spirit
> of the recent tech-ctte decision can be summarized as: "allow users to
> opt-out of N-M + respect past (Squeeze) user choices to do so".
> 
> I'm at loss at formulating a similarly succinct goal for the GNOME team.
> Maybe members of the GNOME team can help with that?

Our goal regarding metapackages is to ensure that people wanting to use
GNOME have the standard set of packages that we agree on to support
best.

Also, it has been repeatedly stated that metapackages are not a
supermarket. They don’t contain anything, and people can make their own
if they don’t like them. If they work for 95% of users, that goal is
reached. The remaining 5% also happen to be those with the ability to
deal without them.

> *If* the main point is adhering to an agreed upon notion of "*default*
> GNOME environment", any easy to use opt-out mechanism (including
> Recommends) should work, no? So I guess I am, and others with me,
> missing a relevant part of GNOME team's goals on this matter. If these
> goals can easily be stated, maybe we won't even need further votes and
> imposed decisions. Maybe we can just find a consensual course of action
> that both respect user choices *and* adhere to GNOME team greater goals.

Recommends are not enough to ensure that packages are installed,
especially upon upgrades. For example regarding NM, we definitely *want*
people who upgrade from squeeze to get NM installed.

As for the opt-out mechanism, it already exists, and is called “service
network-manager disable”. In the same way that most (if not all) GNOME
packages, once installed, can be disabled one way or another - be it by
unshowing menu entries, locking dbus services or disabling init scripts.

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 17:24:03 GMT) Full text and rfc822 format available.

Message #151 received at 688772@bugs.debian.org (full text, mbox):

From: Jakub Wilk <jwilk@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 19:20:17 +0200
* Jakub Wilk <jwilk@debian.org>, 2012-09-27, 13:28:
>>>I actually somehow doubt, that there are a lot of squeeze users, 
>>>which have the whole gnome meta-package installed but decided to 
>>>remove NM.
>>Unfortunately popcon doesn't have this kind of correlation data.
>
>It can be extracted from the raw popcon data (which isn't publicly 
>accessible, for obvious reasons).
>
>I'll give you the numbers later today.

According to the popcon data, 1812 out of 31630 the "gnome" metapackage 
users don't have the "network-manager" package installed.

-- 
Jakub Wilk



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 27 Sep 2012 17:30:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Sep 2012 17:30:13 GMT) Full text and rfc822 format available.

Message #156 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 27 Sep 2012 18:28:53 +0100
Jakub Wilk writes ("Bug#688772: gnome Depends network-manager-gnome"):
> According to the popcon data, 1812 out of 31630 the "gnome" metapackage 
> users don't have the "network-manager" package installed.

Thank you.  That's 5.73%.  Quite a high number given that you have to
override the Recommends (which have been installed by default for some
time now).

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 28 Sep 2012 13:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sam Hartman <hartmans@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 28 Sep 2012 13:27:03 GMT) Full text and rfc822 format available.

Message #161 received at 688772@bugs.debian.org (full text, mbox):

From: Sam Hartman <hartmans@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 28 Sep 2012 09:22:12 -0400
>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

    Ian> Ian Jackson writes ("Bug#688772: gnome Depends
    Ian> network-manager-gnome"):
    >> 6. We specifically forbid anyone from introducing in wheezy, or
    >> in sid until wheezy is released: a. Any new or enhanced
    >> dependencies, or any other mechanisms which are intended to
    >> increase the likelihood of network-manager being installed;

    Ian> This is missing an important comma and should read:

    Ian>       a. Any new or enhanced dependencies, or any other
    Ian> mechanisms, which are intended to increase the likelihood of
    Ian> network-manager being installed;

May I suggest s/which are intended/which have the affect of/

With the current clause you're setting yourself up for future fights
about what people were trying to do.  If your actual goal is to avoid
increasing the probability that network-manager is increased on upgrade,
then focus on that.  That way, if something comes up that has the affect
of increasing network-manager installs you can agree it's a bug without
a disagreement about intent.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 05 Oct 2012 17:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 05 Oct 2012 17:12:03 GMT) Full text and rfc822 format available.

Message #166 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 5 Oct 2012 18:09:54 +0100
From the IRC meeting:
>   * ACTION: dondelelcaro to follow this up with the gnome maintainers to
>     get a clear argument from the GNOME maintainers about why this
>     *must* be a depends and not a recommends  (dondelelcaro, 18:08:51)

I don't know if this was followed up, but there still doesn't seem to
be any such clear argument as far as I'm aware.

Here is a revised version of my draft resolution.  I have incorporated
all the comments and weakened and/or removed the "political"
paragraphs dealing with the maintainers' behaviour.  The only comment
I have rejected is the one suggesting a smaller version of what is now
para.8.  I have introduced a new para.4 mentioning the lack of
convincing reasons for the dependency.

Is there anyone who is unhappy with the draft below ?

Ian.


Whereas

1. The TC notes the decision of the meta-gnome maintainers to
   implement our decision in #681834 by:
    (a) softening the dependency in the gnome-core metapackage
        from Depends to Recommends, as required
    (b) adding a new dependency in the gnome metapackage,
        as a Depends.  (In squeeze, this is where the dependency
        was, but it was a Recommends.)

2. Our intent, as stated in the rationale section of our previous
   decision (#681834, paras 3 and 5), is that squeeze users who have
   gnome installed but not network-manager do not find that
   network-manager becomes installed when they upgrade to wheey.

3. The actions of the meta-gnome maintainers do not achieve this
   objective.

4. Insofar as any reasons have been advanced for the meta-gnome
   maintainer's decision, we do not find them convincing.

5. A Recommends from gnome to network-manager-gnome would serve no
   purpose in wheezy as gnome Depends on gnome-core which already
   Recommends network-manager-gnome.

Therefore

6. We overrule the decision of the meta-gnome maintainers to add a
   dependency from gnome to network-manager-gnome.  This dependency
   should be removed.

7. We request that the Release Team unblock update(s) to meta-gnome so
   that our decisions may be implemented in wheezy.

8. We specifically forbid anyone from introducing in wheezy, or
   in sid until wheezy is released:
    a. Any new or enhanced dependencies, or any other mechanisms,
       which increase the likelihood of network-manager being
       installed;
    b. Any new or enhanced user-facing warnings, imprecations, or
       other kinds of message regarding the alleged desirability or
       requirement to install network-manager;
    c. Any change which in any way impairs (or further impairs) the
       functioning of systems with GNOME components installed but
       without network-manager;
    d. Any change which is contrary to the spirit or intent of either
       our previous resolution in #681834 or this resolution.
   without first obtaining the permission of at least one member of
   the Technical Committee.

Furthermore

9. It is disappointing that this proposed solution to the problem was
   not mentioned during the TC discussion.  If it had been, it could
   have been accepted or rejected by the TC at the time.

10. We remind everyone that the Constitution requires members of the
   project not to work against decisions properly made according to
   the project's governance processes.  On this occasion we do not
   feel it necessary to refer anyone to the Debian Account Managers
   asking for a review of their status.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 05 Oct 2012 18:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 05 Oct 2012 18:39:03 GMT) Full text and rfc822 format available.

Message #171 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 5 Oct 2012 11:36:43 -0700
On Thu, 27 Sep 2012, Josselin Mouette wrote:
> Recommends are not enough to ensure that packages are installed,
> especially upon upgrades. For example regarding NM, we definitely
> *want* people who upgrade from squeeze to get NM installed.

What is still missing is the technical rationale for this desire. If
there were specific technical reason(s) why everyone who uses gnome
should have NM installed, then it would weigh more for forcing NM to
be installed if the gnome meta package was installed.

From what I know so far, the primary rationale appears to be that
gnome upstream considers NM part of gnome, and so it should be
installed. I believe the CTTE addressed this rationale in §2 of the
decision. We decided that unacceptable upgrade behavior outweighed
this, as outlined in §5 and §6.


Don Armstrong

-- 
Sometimes I wish I could take back all my mistakes
but then I think
what if my mother could take back hers?
 -- a softer world #498
    http://www.asofterworld.com/index.php?id=498

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 05 Oct 2012 18:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 05 Oct 2012 18:45:03 GMT) Full text and rfc822 format available.

Message #176 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 5 Oct 2012 11:43:14 -0700
On Fri, 05 Oct 2012, Ian Jackson wrote:
> >From the IRC meeting:
> >   * ACTION: dondelelcaro to follow this up with the gnome maintainers to
> >     get a clear argument from the GNOME maintainers about why this
> >     *must* be a depends and not a recommends  (dondelelcaro, 18:08:51)
> 
> I don't know if this was followed up, but there still doesn't seem to
> be any such clear argument as far as I'm aware.

I've followed up just now; had sort of been working out precisely what
I would like to say.

> Is there anyone who is unhappy with the draft below ?

I personally don't support 8, 9 and 10. [I'd do something like 8, but
I believe it assumes too much bad faith on the part of the gnome
maintainers.]


Don Armstrong

-- 
For a moment, nothing happened. Then, after a second or so, nothing
continued to happen.
 -- Douglas Adams

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 05 Oct 2012 23:12:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 05 Oct 2012 23:12:04 GMT) Full text and rfc822 format available.

Message #181 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: Don Armstrong <don@debian.org>
Cc: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sat, 06 Oct 2012 01:08:07 +0200
Hi Don,

Le vendredi 05 octobre 2012 à 11:36 -0700, Don Armstrong a écrit : 
> On Thu, 27 Sep 2012, Josselin Mouette wrote:
> > Recommends are not enough to ensure that packages are installed,
> > especially upon upgrades. For example regarding NM, we definitely
> > *want* people who upgrade from squeeze to get NM installed.
> 
> What is still missing is the technical rationale for this desire. If
> there were specific technical reason(s) why everyone who uses gnome
> should have NM installed, then it would weigh more for forcing NM to
> be installed if the gnome meta package was installed.

The reason is that GNOME includes NM. Just like it includes gnome-shell
or whatever module. It’s not just an upstream decision: GNOME without NM
is a stripped down GNOME, with reduced functionality in many modules. We
consider GNOME as a tightly integrated environment, with components made
to work together. The metapackages are here to install this integrated
environment (which, despite that, differs from upstream on other
matters), and not just some random set of packages.

The code that makes it actually *work* without NM installed was added
for kFreeBSD – incidentally, by the same NM maintainer whose work has
been repeatedly thrown into mud in the discussions. His intent was
certainly not to give people an excuse to cripple down the Linux ports.
We do not consider this requirement to be optional on architectures
where it can be satisfied.

> From what I know so far, the primary rationale appears to be that
> gnome upstream considers NM part of gnome, and so it should be
> installed. I believe the CTTE addressed this rationale in §2 of the
> decision. We decided that unacceptable upgrade behavior outweighed
> this, as outlined in §5 and §6.

I disagree with the contents of §5 and §6. The release notes are here
precisely for this kind of cases. The reason why NM was only optional is
that historically (in lenny and before) it was buggy and wrongly
designed; which no longer applies.

The resolution also doesn’t mention which problems upgrading from a
squeeze system without NM to a wheezy system with NM causes. The cases
for potential breakage are rare (if they exist at all), and
administrators of systems with complicated network setups have all
reasons to read the release notes before upgrading blindly.

For these reasons, I consider resolution #681834 to be driven by
religious motives rather than technical ones, and that it was conducted
in haste. I have not said anything so far because the wording allows
(and again, I thought this was intentional) for the compromise to move
the dependency to the gnome package. But if people from either side
start questioning this compromise, I am afraid they are going to do a
lot of harm to the project.

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 05 Oct 2012 23:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 05 Oct 2012 23:51:03 GMT) Full text and rfc822 format available.

Message #186 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 5 Oct 2012 16:46:32 -0700
On Sat, 06 Oct 2012, Josselin Mouette wrote:
> The code that makes it actually *work* without NM installed was
> added for kFreeBSD – incidentally, by the same NM maintainer whose
> work has been repeatedly thrown into mud in the discussions.

So, besides the important goal of a complete gnome experience, there's
no other technical reason why NM must be installed?

> I disagree with the contents of §5 and §6.

What in particular about §5 and §6?

> The release notes are here precisely for this kind of cases.

This is certainly one of the possibilities that the CTTE (or a
maintainer) could proscribe to resolve this problem; I wouldn't be
averse to seeing an additional option proposed for a vote which did
just this.

> The resolution also doesn’t mention which problems upgrading from a
> squeeze system without NM to a wheezy system with NM causes.

 "It attempts to avoid overriding local manual configuration, but it
  isn't able to detect all cases where the user is using some other
  component or system to manage networking."

> For these reasons, I consider resolution #681834 to be driven by
> religious motives rather than technical ones,

It's inflammatory to accuse others of having religious motives.[1] I
personally have no interest in punishing, persecuting, or otherwise
attacking the gnome maintainers or any other maintainer in Debian, and
I would be surprised if all of the other members of the CTTE don't
feel the same way.

We all want Debian to be a technically excellent distribution which
users want to use, and while we *often* have very different ideas on
what that actually means, we have come to those ideas by honest means.

> and that it was conducted in haste.

I'm not sure if I would consider a two month long decision process
hasty, but since we seem to be doomed to readdress this issue again,
lets please try to make all of the arguments and solutions out front
so we can make a ideal decision.

> I have not said anything so far because the wording allows (and
> again, I thought this was intentional) for the compromise to move
> the dependency to the gnome package.

I certainly didn't expect that to be a compromise position given the
underlying logic of the decision, and I certainly would have liked to
have addressed that point during the decision. I concede, however,
that it would be possible to construe the decision this way.

> But if people from either side start questioning this compromise, I
> am afraid they are going to do a lot of harm to the project.

We're all on the same side together.


Don Armstrong

1: Additionally, the negative connotation is offensive to the many
people who are involved in or use Debian who have religious beliefs.
-- 
-tommorow is our permanent address
and there they'll scarcely find us(if they do,
we'll move away still further:into now
 -- e.e. cummings "XXXIX" _1 x 1_

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 06 Oct 2012 00:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Oct 2012 00:36:03 GMT) Full text and rfc822 format available.

Message #191 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: Don Armstrong <don@debian.org>
Cc: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sat, 06 Oct 2012 02:32:33 +0200
Le vendredi 05 octobre 2012 à 16:46 -0700, Don Armstrong a écrit : 
> On Sat, 06 Oct 2012, Josselin Mouette wrote:
> > The code that makes it actually *work* without NM installed was
> > added for kFreeBSD – incidentally, by the same NM maintainer whose
> > work has been repeatedly thrown into mud in the discussions.
> 
> So, besides the important goal of a complete gnome experience, there's
> no other technical reason why NM must be installed?

Why would there be? The very purpose of metapackages is to define the
complete gnome experience. For other packages, dependencies indicate
what is required by what.

> > I disagree with the contents of §5 and §6.
> 
> What in particular about §5 and §6?

      * The affirmation that this will cause undesirable upgrade
        behavior is grossly exaggerated. 
      * The reason for the historical Recommends instead of Depends is
        not mentioned, while this history is used as an excuse for the
        whole decision. 
      * The claim that NM can be replaced by another component without
        functionality loss is preposterous. 
      * The excuse of the squeeze→wheezy upgrade serves as a basis for a
        seemingly irrevocable decision that affects all future versions
        of GNOME metapackages.

> It's inflammatory to accuse others of having religious motives.[1] I
> personally have no interest in punishing, persecuting, or otherwise
> attacking the gnome maintainers or any other maintainer in Debian, and
> I would be surprised if all of the other members of the CTTE don't
> feel the same way.

Yet you should wonder why there is such a broad consensus among GNOME
maintainers that NM should be a dependency, while most people pursuing
the goal of NM removal are not even GNOME users. I don’t think what we
do with GNOME affects autopkgtest, curl or hashalot.

> We all want Debian to be a technically excellent distribution which
> users want to use, and while we *often* have very different ideas on
> what that actually means, we have come to those ideas by honest means.

Ideally, yes. However I feel obliged to question the honesty of people
spreading misinformation before using this misinformation to request
CTTE decisions.

> > But if people from either side start questioning this compromise, I
> > am afraid they are going to do a lot of harm to the project.
> 
> We're all on the same side together.

Looking at Ian’s last proposal, I’m afraid not.

        8. We specifically forbid anyone from introducing in wheezy, or
in sid until wheezy is released:
    a. Any new or enhanced dependencies, or any other mechanisms,
       which increase the likelihood of network-manager being
       installed;
    b. Any new or enhanced user-facing warnings, imprecations, or
       other kinds of message regarding the alleged desirability or
       requirement to install network-manager;
    c. Any change which in any way impairs (or further impairs) the
       functioning of systems with GNOME components installed but
       without network-manager;

I’m having a hard time not seeing this as religious, but I’m ready to
listen to other explanations.

> 1: Additionally, the negative connotation is offensive to the many
> people who are involved in or use Debian who have religious beliefs.

People being offended because of their imaginary friend, just like
people being offended by at the idea of not developing Debian like
System V, are officially Not My Problem™.

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 06 Oct 2012 03:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Oct 2012 03:30:03 GMT) Full text and rfc822 format available.

Message #196 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 5 Oct 2012 20:26:01 -0700
On Sat, 06 Oct 2012, Josselin Mouette wrote:
> Le vendredi 05 octobre 2012 à 16:46 -0700, Don Armstrong a écrit : 
> > So, besides the important goal of a complete gnome experience,
> > there's no other technical reason why NM must be installed?
> 
> Why would there be?

If for example, network-manager was so inextricably linked to gnome
that it caused a particular kind of breakage such that it wasn't
reasonable for anyone who wanted the other gnome bits not have it
installed.

>  * The affirmation that this will cause undesirable upgrade behavior
>    is grossly exaggerated.

From what I understand, nm and wicd are not capable of co-existing.[1]
Furthermore, nm does not always catch that other systems (such as
ifupdown) are configuring the interfaces, and may lead to broken
behavior on upgrade (such as #656584 and #688355, just glancing at
it).

>  * The reason for the historical Recommends instead of Depends is
>    not mentioned, while this history is used as an excuse for the
>    whole decision.

What was the reason?

>  * The claim that NM can be replaced by another component without
>    functionality loss is preposterous.

Which functionality loss are we talking about? For simple
configurations, it seems quite possible to replace NM with ifupdown
with no loss of functionality. 

>  * The excuse of the squeeze→wheezy upgrade serves as a basis for a
>    seemingly irrevocable decision that affects all future versions
>    of GNOME metapackages.

No CTTE decision is irrevocable. It's trivial to come back to the CTTE
and get us to sunset a decision. I personally would also not have had
a problem making this decision for the gnome meta packages only in
wheezy, with some transition plan to be worked out in the future.

Finally, in the future, please bring forward all of these concerns
about what the CTTE is deciding during the actual decision process so
we can address them.
 
> I don’t think what we do with GNOME affects autopkgtest, curl or
> hashalot.

It affects the users of Debian, which is what we're here for. [I'm
certainly not spending a nice Friday evening trying to sort this all
out for my own personal use of Debian.[2]]


Don Armstrong

1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#215
-- 
Live and learn
or die and teach by example
 -- a softer world #625
    http://www.asofterworld.com/index.php?id=625

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 06 Oct 2012 04:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Oct 2012 04:09:03 GMT) Full text and rfc822 format available.

Message #201 received at 688772@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Josselin Mouette <joss@debian.org>, 688772@bugs.debian.org, Don Armstrong <don@debian.org>
Cc: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 05 Oct 2012 22:07:10 -0600
[Message part 1 (text/plain, inline)]
Josselin Mouette <joss@debian.org> writes:

>       * The reason for the historical Recommends instead of Depends is
>         not mentioned, while this history is used as an excuse for the
>         whole decision. 

I personally believe that metapackages should be primarily populated
with Recommends, with Depends largely reserved for actual technical
dependencies between real packages.  This is consistent with my belief
that we should try to empower our users to be able to exercise a
reasonable amount of choice in configuring and operating their Debian
systems.  Thus, my bias is to believe that when there's no strong
technical need, a Recommends is the appropriate choice, and any change
From a Recommends to Depends causes me to want to understand why the
change was made and what we hope to gain from it.

>       * The claim that NM can be replaced by another component without
>         functionality loss is preposterous. 

I won't argue this point, since I use NM myself on my notebook because
it is the best fit for my needs at the moment of the available choices.
The degree to which using NM "entangles me" in other GNOME-related bits
that are not otherwise particularly useful to me is annoying, but a
burden I'm willing to bear because I like what NM does for me.

>       * The excuse of the squeeze→wheezy upgrade serves as a basis for a
>         seemingly irrevocable decision that affects all future versions
>         of GNOME metapackages.

I would personally like *all* metapackage maintainers to re-evaluate the
need for Depends vs Recommends in all future versions... this is
certainly not something in which *I* am personally trying to single out
GNOME. 

>> We all want Debian to be a technically excellent distribution which
>> users want to use, and while we *often* have very different ideas on
>> what that actually means, we have come to those ideas by honest means.
>
> Ideally, yes. However I feel obliged to question the honesty of people
> spreading misinformation before using this misinformation to request
> CTTE decisions.

Regardless of what happens before, once an item is brought before the
CTTE, the only choice we all have is to try and make the discussion as
well-informed and balanced as possible, so that each CTTE member can
make the best possible decision given the information available.

We've already had some discussion about how much we should all as CTTE
members try to avoid bringing emotions into play.  It is clear that Ian
has struggled with that on this issue, but that's precisely the reason
that we have a diverse committee that uses a voting process to make
decisions...

Bdale
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 06 Oct 2012 05:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Oct 2012 05:45:06 GMT) Full text and rfc822 format available.

Message #206 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Josselin Mouette <joss@debian.org>
Cc: 688772@bugs.debian.org, Don Armstrong <don@debian.org>, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 05 Oct 2012 22:40:02 -0700
Josselin Mouette <joss@debian.org> writes:

>       * The claim that NM can be replaced by another component without
>         functionality loss is preposterous. 

That's not what section 6 says.  It says:

    (ii) There is both demonstrable, intentional widespread replacement of
       that package by Debian GNOME users and no significant loss of
       unrelated GNOME desktop functionality by replacing it with a
       different component.

You dropped the word "unrelated" in your objection, but I put that word in
there intentionally precisely because I think there *is* loss of
functionality, but it's functionality directly related to the decision
that the user is making.

There is clear loss of networking configuration functionality in GNOME by
removing Network Manager.  But that's exactly the choice that the user is
making: giving up Network Manager network configuration functionality in
favor of something else.  Presumably they're making an informed choice
about the value of the lost functionality to them, since it's directly
related to the component that they're replacing.

The situation would be considerably different if removing Network Manager
caused significant loss of *unrelated* functionality: functionality of the
desktop other than network configuration.  Indeed, in that case I would
consider Depends to be entirely appropriate even for gnome-core.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 06 Oct 2012 07:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Oct 2012 07:45:04 GMT) Full text and rfc822 format available.

Message #211 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: Bdale Garbee <bdale@gag.com>
Cc: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sat, 06 Oct 2012 09:41:53 +0200
Le vendredi 05 octobre 2012 à 22:07 -0600, Bdale Garbee a écrit : 
> I personally believe that metapackages should be primarily populated
> with Recommends, with Depends largely reserved for actual technical
> dependencies between real packages.

This point is probably worth discussing because it comes up very often.

I don’t think it is reasonable to do so until metapackages are treated
differently by APT.
1. Removing them should not mark their dependencies autoremove.
2. A major upgrade (which is something that needs defining, especially
for testing/unstable users) should try to reinstall all dependencies or
ask, one way or another, whether the administrator still wants to
exclude them.
Basically this means going back to a tasks system from the current
metapackages situation (whether the implementation is based on packages
or not).

> This is consistent with my belief
> that we should try to empower our users to be able to exercise a
> reasonable amount of choice in configuring and operating their Debian
> systems.

Most of the time packages get removed, it is due to upgrade problems,
with APT not choosing the best solution. Strict dependencies alleviate
most of these problems.

Maybe you are unfamiliar with what clueless newbies do with their
systems. You want to empower users, that’s fine; but GNOME is for all
users. Those who have the technical knowledge to handle their packages
manually should also know how to make it happen without metapackages.

> Thus, my bias is to believe that when there's no strong
> technical need, a Recommends is the appropriate choice, 

The purpose of a metapackage is to install all packages related to a
certain environment or functionality class. Let us not forget that when
choosing technical solutions.

> and any change
> From a Recommends to Depends causes me to want to understand why the
> change was made and what we hope to gain from it.

What has changed since lenny is that NM has been rearchitectured and is
easy to disable. You cannot even treat it like it was the same piece of
software.
Therefore, this change was supposed to happen in squeeze, but we already
delayed it at that time because of upgrades from lenny, and because the
configuration format for system connections was still new and thus
unfamiliar to many.
If we delay it once again, what do we do for jessie?

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 06 Oct 2012 11:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Oct 2012 11:57:06 GMT) Full text and rfc822 format available.

Message #216 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sat, 6 Oct 2012 07:22:43 -0400
On Friday, October 05, 2012 23:26:01, Don Armstrong wrote:
> On Sat, 06 Oct 2012, Josselin Mouette wrote:
[…]
> >  * The affirmation that this will cause undesirable upgrade behavior
> >    is grossly exaggerated.
> 
> From what I understand, nm and wicd are not capable of co-existing.[1]

As it has been mentioned that n-m had design issues that it may no longer 
have, it means that /when/ I was having the issues I cited in the link above 
with n-m may be important.  I looked into my records, and the issues I was 
having with n-m breakage on upgrades, n-m interfering with wicd, and upgrades 
of n-m "undoing" user-made init script modifications to disable it occurred in 
the Fall of 2009.  Package/metapackage dependencies were also directly related 
to why I was having the issue at the time  too -- I remember trying to remove 
n-m and found the system "fighting me" on it, and was too busy to work out how 
to immediately get around the dependencies; I had the technical capability to 
do so, but my focus needed to be elsewhere.  Instead I kept having to use the 
"field bandage" of re-modifying the init script after n-m broke the use of 
wicd on each upgrade.  IIRC I eventually ended up having to compromise and 
remove certain programs I used and liked in order to remove n-m.  wicd at that 
time did not have a wicd-kde package, so I used wicd-gtk and wicd-curses; it 
didn't matter much to me that these didn't integrate with the rest of the 
system, because unlike n-m they didn't break on upgrades.

As I also mentioned [2], recent changes to the task-xfce-desktop package in 
Wheezy pulled in n-m in a VM I run even though wicd had previously been 
installed by default, and at least for the wired interface there didn't seem 
to be a bad interaction.

I think my data on n-m is outdated, so I think more present-day testing of n-m 
and wicd interaction is needed to know if any conflicts exist today.

> >  * The claim that NM can be replaced by another component without
> >    functionality loss is preposterous.
> 
> Which functionality loss are we talking about? For simple
> configurations, it seems quite possible to replace NM with ifupdown
> with no loss of functionality.

One cited example: Phillip Kern mentioned [3] that n-m supports IPv6 where 
wicd does not, which is why he had to switch back from wicd.



I'm not convinced by the argument of "functionality loss" compared to another 
component as a reason for the Dependency.  If an alternative works fine for 
the user, I don't see why continuing to use it /shouldn't/ be allowed without 
having to work-around the metapackage.  I agree that n-m /does/ have 
additional features to alternatives (and that it integrates better with 
Gnome), but that still does /not/ mean that every user would want it or need 
it.  For instance there are often features n-m has that a user won't have the 
capability of taking advantage of because they lack the hardware to do so.


I share Colin's concerns about having to work around the metapackage.  Being 
that Debian's mantra is "The /Universal/ Operating System", this implies that 
it tries to cater to everyone, including those who my not yet have figured out 
what reverse dependencies are and how to work around the metapackage at their 
own risk.  Removing one package and installing another is generally a 
operation of a lower bar than working around a metapackage is.  An interesting 
situation to consider in this context is accidentily removing the network 
configuration tool on a wireless-only system, and thus not having network 
connectivity to install another one.

In addition my experience it's common to install several Window Managers and 
Development Environments simultaneously on shared systems as well as users 
wishing to try out the various choices; I think the dependency on n-m in the 
gnome metapackage may impact that experience.  It's of course also common to 
run Gnome programs from a different DE or WM than Gnome, too.  For both of 
these reasons, the fact that the gnome metapackage is installed doesn't 
necessarily mean Gnome is the primary environment being used.



I think this issue borders the gap between "user experience design" and 
"allowing user choice by design".  I believe the Gnome maintainers are looking 
more towards the former, and I think the dependency has some impact on the 
latter.  I'm still not sure I understand the ramifications of a focus on the 
latter; that is, what if any negative impact there would be if n-m was a 
Recommends in the gnome metapackage.



> 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#215

2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#235

3: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#255

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 09 Oct 2012 09:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 09 Oct 2012 09:12:03 GMT) Full text and rfc822 format available.

Message #221 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 9 Oct 2012 05:09:15 -0400
On Saturday, October 06, 2012 07:22:43, Chris Knadle wrote:
> On Friday, October 05, 2012 23:26:01, Don Armstrong wrote:
> > On Sat, 06 Oct 2012, Josselin Mouette wrote:
> […]
> 
> > >  * The affirmation that this will cause undesirable upgrade behavior
> > >    is grossly exaggerated.
> > 
> > From what I understand, nm and wicd are not capable of co-existing.[1]
...
> I think my data on n-m is outdated, so I think more present-day testing of
> n-m and wicd interaction is needed to know if any conflicts exist today.

I've retested this.  If the network-manager daemon is running, I find that any 
attempt to get wicd to connect to my wireless router fails with an error 
message of "bad password".  (Also tested all three wicd UIs.)  Attempts 
succeed once network-manager is stopped.  After switching back to wired and 
starting network-manager, attempts to connect to wireless via wicd once again 
fail with the same error.

> > 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#215

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 11 Oct 2012 01:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 11 Oct 2012 01:21:05 GMT) Full text and rfc822 format available.

Message #226 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 10 Oct 2012 18:18:52 -0700
On Fri, 05 Oct 2012, Don Armstrong wrote:
> From what I understand, nm and wicd are not capable of
> co-existing.[1] Furthermore, nm does not always catch that other
> systems (such as ifupdown) are configuring the interfaces, and may
> lead to broken behavior on upgrade (such as #656584 and #688355,
> just glancing at it).

Assuming that

1) we decide that failures of NM to detect basic ifupdown
configurations and avoid overriding them are bugs, possibly of RC
severity

2) given the gnome maintainer's desire to have NM installed by default
from the gnome metapackage

allowing gnome to Depends: nm | wicd; would deal with the most
concerning form of breakage for me.

Does this work for anyone else?


Don Armstrong

-- 
It was a very familiar voice. [...] It was a voice you could have used
to open a bottle of whine.
 -- Terry Pratchett _The Last Continent_ p270

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 05:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 05:12:03 GMT) Full text and rfc822 format available.

Message #231 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 01:08:52 -0400
On Wednesday, October 10, 2012 21:18:52, Don Armstrong wrote:
> On Fri, 05 Oct 2012, Don Armstrong wrote:
> > From what I understand, nm and wicd are not capable of
> > co-existing.[1] Furthermore, nm does not always catch that other
> > systems (such as ifupdown) are configuring the interfaces, and may
> > lead to broken behavior on upgrade (such as #656584 and #688355,
> > just glancing at it).
> 
> Assuming that
> 
> 1) we decide that failures of NM to detect basic ifupdown
> configurations and avoid overriding them are bugs, possibly of RC
> severity
> 
> 2) given the gnome maintainer's desire to have NM installed by default
> from the gnome metapackage
> 
> allowing gnome to Depends: nm | wicd; would deal with the most
> concerning form of breakage for me.
> 
> Does this work for anyone else?

I think this would work assuming that wicd is a usable replacement for n-m 
within Gnome, which it might or might not be depending on the particular 
user's needs.  I've been testing for a couple of days with wicd installed but 
n-m removed by installing a minimally modified gnome metapackge, so I'll 
report what I've found so far.

wicd-gtk doesn't integrate into the top bar in a "Gnome" login, but it does 
(automatically) in a "Gnome Compatability" login.  In a "Gnome" login, running 
'wicd-gtk' manually via a terminal works, except that the icon that normally 
gives visual status of connectivity isn't shown anywhere.  Under either login 
type, opening System Settings -> Network shows the message "The system network 
services are not compatible with this version."

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 11:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 11:33:05 GMT) Full text and rfc822 format available.

Message #236 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 12:31:44 +0100
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> 1) we decide that failures of NM to detect basic ifupdown
> configurations and avoid overriding them are bugs, possibly of RC
> severity
> 
> 2) given the gnome maintainer's desire to have NM installed by default
> from the gnome metapackage
> 
> allowing gnome to Depends: nm | wicd; would deal with the most
> concerning form of breakage for me.
> 
> Does this work for anyone else?

Why do you think the gnome metapackage depending on, rather than
recommending, wicd, is a good idea ?  I don't really see the logical
connection between any of the goals (whether the TC's or the GNOME
maintainers') and your proposal.

For example, consider the position of someone who has deliberately
removed n-m in squeeze, and is using ifupdown or running ifconfig by
hand or whatever, and upgrades to wheezy.  This still gives them n-m
back.  That's not respecting their previous choice to remove it.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 11:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 11:45:03 GMT) Full text and rfc822 format available.

Message #241 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 12:42:48 +0100
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Fri, 05 Oct 2012, Ian Jackson wrote:
> > Is there anyone who is unhappy with the draft below ?
> 
> I personally don't support 8, 9 and 10.

Losing 9 and 10 is fine by me if that gets your vote.

>  [I'd do something like 8, but I believe it assumes too much bad
> faith on the part of the gnome maintainers.]

Let me try to understand this position of yours more clearly:

You agree that the things prohibited by 8 are bad.  But you think the
gnome maintainers would certainly not do them.  Therefore spelling out
that they are forbidden is unnecessary and offensive.

So are you saying that we should leave off 8.  But if the gnome
maintainers do the bad things prohibted by 8, you would be happy to
overrule them a third time ?

I don't think that's wise but I'm willing to proceed on that basis if
that's what gets us some progress on this issue now.


No-one else has objected to my draft.  I'm therefore considering
proposing a vote; I would probably call for votes on two positive
resolutions:

  A  paras 1-7 of my previous draft
     gnome metapackage must not depend on n-m (3:1 required)
     
  B  1-8 of my previous draft
     as above, also prohibit backsliding (3:1 required)



Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 12:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jeremy Bicha <jbicha@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 12:00:03 GMT) Full text and rfc822 format available.

Message #246 received at 688772@bugs.debian.org (full text, mbox):

From: Jeremy Bicha <jbicha@ubuntu.com>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 07:57:29 -0400
On 12 October 2012 07:31, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
>> 1) we decide that failures of NM to detect basic ifupdown
>> configurations and avoid overriding them are bugs, possibly of RC
>> severity
>>
>> 2) given the gnome maintainer's desire to have NM installed by default
>> from the gnome metapackage
>>
>> allowing gnome to Depends: nm | wicd; would deal with the most
>> concerning form of breakage for me.
>>
>> Does this work for anyone else?
>
> Why do you think the gnome metapackage depending on, rather than
> recommending, wicd, is a good idea ?  I don't really see the logical
> connection between any of the goals (whether the TC's or the GNOME
> maintainers') and your proposal.
>
> For example, consider the position of someone who has deliberately
> removed n-m in squeeze, and is using ifupdown or running ifconfig by
> hand or whatever, and upgrades to wheezy.  This still gives them n-m
> back.  That's not respecting their previous choice to remove it.

The point I took away from Chris' post is that wicd does not integrate
with GNOME Shell at all. There is only one networking solution that is
supported with GNOME 3.

Not to put more ideas in Ian's head about packaging decisions to
overrule, but nobody objects to gnome-core depending on gdm, which
also starts by default after installation unless you explicitly
disable it, and conflicts with several other display managers that are
part of Debian.

I consider a usable UI for setting up mobile networking (to include
WiFi) to be a fundamental piece of any desktop, especially GNOME.

I support Don's proposal to consider bugs where NM does not work right
with basic ifupdown configs to be RC-severity.

Jeremy



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 13:36:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 13:36:05 GMT) Full text and rfc822 format available.

Message #251 received at 688772@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 688772@bugs.debian.org
Cc: Don Armstrong <don@debian.org>, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 15:32:43 +0200
On Fri, 12 Oct 2012, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > 1) we decide that failures of NM to detect basic ifupdown
> > configurations and avoid overriding them are bugs, possibly of RC
> > severity
> > 
> > 2) given the gnome maintainer's desire to have NM installed by default
> > from the gnome metapackage
> > 
> > allowing gnome to Depends: nm | wicd; would deal with the most
> > concerning form of breakage for me.
> > 
> > Does this work for anyone else?
> 
> Why do you think the gnome metapackage depending on, rather than
> recommending, wicd, is a good idea ?  I don't really see the logical
> connection between any of the goals (whether the TC's or the GNOME
> maintainers') and your proposal.
> 
> For example, consider the position of someone who has deliberately
> removed n-m in squeeze, and is using ifupdown or running ifconfig by
> hand or whatever, and upgrades to wheezy.  This still gives them n-m
> back.  That's not respecting their previous choice to remove it.

The logic behind Don's proposition is that, if you're not using NM, then
you're likely either using wicd or simple ifupdown config. That leaves
two cases:

1/ Having wicd and nm active at the same time creates problems, so Don
ensures that you can install either one of them and still have the
gnome-core package installed (and still have nm by default if you don't
make any specific choice).

2/ If you're an ifupdown user, then you can have nm installed even if it
was not installed before hand, it won't hurt because NM ignores any
interface listed in /etc/network/interfaces. Failing to comply with this
rule are bugs that we could consider RC.


In this situation, it seems that all parties would be satisfied (provided
that the majority of persons who are not using NM are in fact using wicd
or ifupdown).

It looks like an acceptable outcome to me. Thank you Don for trying to find
a third way out of this situation.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 13:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sam Hartman <hartmans@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 13:48:03 GMT) Full text and rfc822 format available.

Message #256 received at 688772@bugs.debian.org (full text, mbox):

From: Sam Hartman <hartmans@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 688772@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, Don Armstrong <don@debian.org>, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 09:44:11 -0400
I'm still confused why recommends doesn't work for everyone.

I understand that the Gnome maintainers want N-M installed by default.
Except I think recommends gets you that.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 15:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 15:39:06 GMT) Full text and rfc822 format available.

Message #261 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jeremy Bicha <jbicha@ubuntu.com>
Cc: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 08:30:36 -0700
Jeremy Bicha <jbicha@ubuntu.com> writes:

> Not to put more ideas in Ian's head about packaging decisions to
> overrule, but nobody objects to gnome-core depending on gdm, which also
> starts by default after installation unless you explicitly disable it,
> and conflicts with several other display managers that are part of
> Debian.

That's the point, though.  No one objects.  In other words, we don't have
a regular trickle of users of Debian stating that they want to disable
gdm3 and use a different display manager while still wanting to use GNOME
and expressing dissatisfaction with the metapackage because of it.  So
there's no problem.  I personally have a lot of sympathy for Bdale's
position that metapackages would work better in general with Recommends,
but when no one's complaining, I'm certainly not going to poke my nose in
the GNOME team's business.

All three of the reasons in the original n-m decision are there for a
reason, and analogies to situations where one or more of those reasons
don't apply are not as relevant.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 16:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 16:36:03 GMT) Full text and rfc822 format available.

Message #266 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>, Jeremy Bicha <jbicha@ubuntu.com>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 12:32:08 -0400
On Friday, October 12, 2012 11:30:36, Russ Allbery wrote:
> Jeremy Bicha <jbicha@ubuntu.com> writes:
> > Not to put more ideas in Ian's head about packaging decisions to
> > overrule, but nobody objects to gnome-core depending on gdm, which also
> > starts by default after installation unless you explicitly disable it,
> > and conflicts with several other display managers that are part of
> > Debian.
> 
> That's the point, though.  No one objects.  In other words, we don't have
> a regular trickle of users of Debian stating that they want to disable
> gdm3 and use a different display manager while still wanting to use GNOME
> and expressing dissatisfaction with the metapackage because of it.  So
> there's no problem.

During an attempt to install a second X display manager, a question is asked 
during the inatall for which of the display managers is to be used to /avoid/ 
a conflict.  That's why there aren't complaints about gdm3 conflicting with 
kdm, xdm, wdm, etc -- if it did, there would be.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 18:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 18:09:03 GMT) Full text and rfc822 format available.

Message #271 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 11:05:12 -0700
On Fri, 12 Oct 2012, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > 1) we decide that failures of NM to detect basic ifupdown
> > configurations and avoid overriding them are bugs, possibly of RC
> > severity
> > 
> > 2) given the gnome maintainer's desire to have NM installed by default
> > from the gnome metapackage
> > 
> > allowing gnome to Depends: nm | wicd; would deal with the most
> > concerning form of breakage for me.
> > 
> > Does this work for anyone else?
> 
> Why do you think the gnome metapackage depending on, rather than
> recommending, wicd, is a good idea?

The primary case of NM breaking things is when it's installed with
wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.

> For example, consider the position of someone who has deliberately
> removed n-m in squeeze, and is using ifupdown or running ifconfig by
> hand or whatever, and upgrades to wheezy. This still gives them n-m
> back. That's not respecting their previous choice to remove it.

Right, but if they get NM back, and nothing breaks because of it,[0]
it's just the same as any other package being installed by a meta
package. They've wasted some disk space, and they've got another
program running, but everything continues to work.

It's certainly not the way I would do it,[1] but it's one way to
mitigate the problems with unconditionally installing NM while
allowing a further insistence that NM be installed which the gnome
maintainers appear to strongly believe is necessary.


Don Armstrong

0: This requires some buy-in by the NM maintainer(s), though.
1: But then, I don't run gnome, nor do I care to help maintain it.
-- 
As nightfall does not come at once, neither does oppression. In both
instances, there is a twilight when everything remains seemingly
unchanged. And it is in such twilight that we all must be most aware
of change in the air -- however slight -- lest we become unwitting
victims of the darkness.
 -- William O. Douglas

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 18:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 18:39:03 GMT) Full text and rfc822 format available.

Message #276 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 19:38:07 +0100
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Fri, 12 Oct 2012, Ian Jackson wrote:
> > Why do you think the gnome metapackage depending on, rather than
> > recommending, wicd, is a good idea?
> 
> The primary case of NM breaking things is when it's installed with
> wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.

There are no other competitors to wicd and n-m then ?

> > For example, consider the position of someone who has deliberately
> > removed n-m in squeeze, and is using ifupdown or running ifconfig by
> > hand or whatever, and upgrades to wheezy. This still gives them n-m
> > back. That's not respecting their previous choice to remove it.
> 
> Right, but if they get NM back, and nothing breaks because of it,[0]
> it's just the same as any other package being installed by a meta
> package. They've wasted some disk space, and they've got another
> program running, but everything continues to work.

And you're saying nothing will break because in the case where they
have wicd, n-m won't be installed because of the alternative.  And in
the case where they don't have wicd "there are no such bugs that
aren't rc".

Are we sure that all these rc bugs are going to be fixed and not
downgraded at the last moment ?  Are we sure that we will find them
all, for that matter, before the release ?

Given the very strong insistence by n-m's proponents that these bugs
aren't even real, in many cases, it seems more likely that n-m will be
released in wheezy with infelicities which will be argued by the gnome
maintainers to be not bugs, or not rc, or someone else's fault.

For example, if I want to use ifupdown then I probably don't want n-m
to bring up even interfaces which exist but which I haven't mentioned
in /etc/network/interfaces - but managing those interfaces is
precisely the point of n-m.  So I'm cast back into "install n-m but
disable it", which is clearly inferior.

The result is surely going to be more friction between users who find
n-m doesn't work for them, and developers who insist on forcing n-m on
them.

It is very simple to avoid all of these kind of disagreements: allow
users to conveniently not have n-m if they don't want it.  It seems to
me unarguable that a user who doesn't want n-m should be allowed to
not have it, and still gain the other benefits of the metapackages
provided.

In all cases where removing the hard dependency (from the gnome
metapackage, in this case) makes any difference at all, it is to the
benefit of the user in question.  Assuming, as we should, that it is
to the benefit of a user who makes a conscious and informed decision
for that decision to be honoured even if some of us might not consider
it wise.

Our priorities are our users and free software.  How does pushing n-m
onto unwilling users benefit the users or free software ?

> It's certainly not the way I would do it,[1] but it's one way to
> mitigate the problems with unconditionally installing NM while
> allowing a further insistence that NM be installed which the gnome
> maintainers appear to strongly believe is necessary.

They do indeed appear to strongly believe that but they have advanced
no cogent reasons.  (You agree, don't you, that they haven't advanced
any cogent reasons?)

I have to say that the continued attempts to placate this unjustified
insistence are very perplexing to me, particularly given that the
"compromises" are:
 - clearly technically inferior
 - less respectful of our users' choices

The _only_ downside of my proposed decision is that it would annoy the
Debian gnome maintainers.  Our job however is to make technical
judgements on technical questions.  That doing the right thing would
annoy the maintainer, because the maintainer feels strongly but is
plainly wrong, is not a good reason for doing the wrong thing.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 18:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 18:45:03 GMT) Full text and rfc822 format available.

Message #281 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 11:41:37 -0700
On Fri, 12 Oct 2012, Sam Hartman wrote:
> I'm still confused why recommends doesn't work for everyone.
>
> I understand that the Gnome maintainers want N-M installed by default.
> Except I think recommends gets you that.

That's what I'm confused about too, but I'm assuming that there is
indeed a reason why Recommends isn't enough, and the gnome meta
package has to Depends: NM. [The questions I posed earlier still
haven't been answered, unfortunately.]


Don Armstrong

-- 
"For those who understand, no explanation is necessary.
 For those who do not, none is possible."

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 18:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 18:48:03 GMT) Full text and rfc822 format available.

Message #286 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 19:46:28 +0100
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Fri, 12 Oct 2012, Sam Hartman wrote:
> > I understand that the Gnome maintainers want N-M installed by default.
> > Except I think recommends gets you that.
> 
> That's what I'm confused about too, but I'm assuming that there is
> indeed a reason why Recommends isn't enough, and the gnome meta
> package has to Depends: NM. [The questions I posed earlier still
> haven't been answered, unfortunately.]

I think your assumption is incorrect.

The gnome maintainers have written a great deal in these bug reports
but have failed to come up with the reason you are looking for.

The simpler hypothesis is that there is no reason.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 18:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 18:54:03 GMT) Full text and rfc822 format available.

Message #291 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 19:51:44 +0100
Ian Jackson writes ("Re: Bug#688772: gnome Depends network-manager-gnome"):
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > That's what I'm confused about too, but I'm assuming that there is
> > indeed a reason why Recommends isn't enough, and the gnome meta
> > package has to Depends: NM. [The questions I posed earlier still
> > haven't been answered, unfortunately.]
...
> The simpler hypothesis is that there is no reason.

I should expand on that, because it makes it sound like I think the
gnome maintainerss' behaviour is entirely inexplicable.  That's not
what I mean.  I should have said "no good reason".

It seems to me that the gnome maintainers have a philosophical view
that Network Manager is very strongly part of GNOME, and that they
feel that this philosophical position can only be properly reflected
by a hard dependency.  That is, that demoting the dependency to
Recommends would be failing to properly give effect to the truth that
N-M is part of GNOME.

This seems to me to be the core of the opposition.  Naturally
I disagree that that's a good reason for having a Depends.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 19:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefano Zacchiroli <zack@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 19:09:03 GMT) Full text and rfc822 format available.

Message #296 received at 688772@bugs.debian.org (full text, mbox):

From: Stefano Zacchiroli <zack@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 21:07:03 +0200
[Message part 1 (text/plain, inline)]
On Fri, Oct 12, 2012 at 07:51:44PM +0100, Ian Jackson wrote:
> It seems to me that the gnome maintainers have a philosophical view
> that Network Manager is very strongly part of GNOME, and that they
> feel that this philosophical position can only be properly reflected
> by a hard dependency.  That is, that demoting the dependency to
> Recommends would be failing to properly give effect to the truth that
> N-M is part of GNOME.

To be fair, it seems to me that Joss has provided an additional answer
to the "why recommends?" question in

  https://lists.debian.org/debian-ctte/2012/09/msg00089.html

For lack of a better synopsis, the argument there is "because recommends
do not behave properly across upgrades".

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 19:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 19:18:02 GMT) Full text and rfc822 format available.

Message #301 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 20:15:58 +0100
Stefano Zacchiroli writes ("Bug#688772: gnome Depends network-manager-gnome"):
> To be fair, it seems to me that Joss has provided an additional answer
> to the "why recommends?" question in
> 
>   https://lists.debian.org/debian-ctte/2012/09/msg00089.html
> 
> For lack of a better synopsis, the argument there is "because recommends
> do not behave properly across upgrades".

That's a reason not to use Recommends in metapackages everywhere
(indeed, it's _the_ reason why metapackages shouldn't just all use
Recommends).

But in this specific case, it isn't a good reason, because the bug
(failing to honour a newly-appearing Recommends) will not occur in the
case of people upgrading from squeeze's "gnome", because the squeeze's
"gnome" package already had that recommends.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 19:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 19:57:04 GMT) Full text and rfc822 format available.

Message #306 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 21:55:15 +0200
Le vendredi 12 octobre 2012 à 19:51 +0100, Ian Jackson a écrit :
> > The simpler hypothesis is that there is no reason.
> 
> I should expand on that, because it makes it sound like I think the
> gnome maintainerss' behaviour is entirely inexplicable.  

Don’t worry, it just sounds like yourself.

-- 
.''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 20:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 20:09:04 GMT) Full text and rfc822 format available.

Message #311 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 13:06:29 -0700
On Fri, 12 Oct 2012, Josselin Mouette wrote:
> Le vendredi 12 octobre 2012 à 19:51 +0100, Ian Jackson a écrit :
> > > The simpler hypothesis is that there is no reason.
> > 
> > I should expand on that, because it makes it sound like I think the
> > gnome maintainerss' behaviour is entirely inexplicable.  
> 
> Don’t worry, it just sounds like yourself.

Continuing to attack Ian like this is not helpful. Please stop.


Don Armstrong

-- 
UF: What's your favorite coffee blend?
PD: Dark Crude with heavy water. You are understandink? "If geiger
    counter does not click, the coffee, she is just not thick."

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 20:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 20:27:06 GMT) Full text and rfc822 format available.

Message #316 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 22:22:34 +0200
Le vendredi 12 octobre 2012 à 21:07 +0200, Stefano Zacchiroli a écrit :
> For lack of a better synopsis, the argument there is "because recommends
> do not behave properly across upgrades".

And also, the purpose of metapackages is to ship dependencies.

-- 
.''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 20:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 20:30:03 GMT) Full text and rfc822 format available.

Message #321 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 22:28:24 +0200
Le vendredi 12 octobre 2012 à 13:06 -0700, Don Armstrong a écrit :
> Continuing to attack Ian like this is not helpful. Please stop.

No, you please stop.

You should be glad there is one remaining GNOME maintainer willing to
talk about the crusade. Seeing Ian talk his usual crap is a good way to
reduce this number further.

-- 
.''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 12 Oct 2012 23:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 12 Oct 2012 23:33:05 GMT) Full text and rfc822 format available.

Message #326 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 12 Oct 2012 16:28:49 -0700
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):

>> The primary case of NM breaking things is when it's installed with
>> wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.

> There are no other competitors to wicd and n-m then ?

It's also possible to configure wireless networking manually without using
either wicd or ifup and using wpa_supplicant directly, but I think that's
close enough to the ifup use case (and similar enough from the n-m
perspective) that we can consider it the same.

There may be other more comprehensive systems like n-m and wicd, but if so
I've not heard of them.

> They do indeed appear to strongly believe that but they have advanced no
> cogent reasons.  (You agree, don't you, that they haven't advanced any
> cogent reasons?)

Actually, Josselin did say, in one of his recent messages, the reason that
I had hypothesized: that n-m is so much better that he's not sure that
people who previously opted out of n-m stated a preference that should
apply to the current n-m.

Whether or not one agrees with that reason, I do think it's cogent and
goes directly to the point, namely upgrade behavior.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 13 Oct 2012 09:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 13 Oct 2012 09:48:05 GMT) Full text and rfc822 format available.

Message #331 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sat, 13 Oct 2012 05:44:53 -0400
On Friday, October 12, 2012 14:38:07, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > On Fri, 12 Oct 2012, Ian Jackson wrote:
> > > Why do you think the gnome metapackage depending on, rather than
> > > recommending, wicd, is a good idea?
> > 
> > The primary case of NM breaking things is when it's installed with
> > wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.
> 
> There are no other competitors to wicd and n-m then ?

'apt-cache search "network manager"' also comes up with nova-network which is 
a network manager for OpenStack, which I think is Cloud related, but I'm not 
familiar with it.  Here's the relevant portion of the description:

   This package equips a system to function as a network node. This
   service is responsible for managing floating and fixed IP addresses,
   DHCP, bridging, and VLANs, and in some cases acts as a gateway.
   Different networking strategies can be accessed by setting the
   network_manager flag to FlatManager, FlatDHCPManager, or VlanManager
   (the default).

> > > For example, consider the position of someone who has deliberately
> > > removed n-m in squeeze, and is using ifupdown or running ifconfig by
> > > hand or whatever, and upgrades to wheezy. This still gives them n-m
> > > back. That's not respecting their previous choice to remove it.
> > 
> > Right, but if they get NM back, and nothing breaks because of it,[0]
> > it's just the same as any other package being installed by a meta
> > package. They've wasted some disk space, and they've got another
> > program running, but everything continues to work.
> 
> And you're saying nothing will break because in the case where they
> have wicd, n-m won't be installed because of the alternative.  And in
> the case where they don't have wicd "there are no such bugs that
> aren't rc".
> 
> Are we sure that all these rc bugs are going to be fixed and not
> downgraded at the last moment ?  Are we sure that we will find them
> all, for that matter, before the release ?
> 
> Given the very strong insistence by n-m's proponents that these bugs
> aren't even real, in many cases, it seems more likely that n-m will be
> released in wheezy with infelicities which will be argued by the gnome
> maintainers to be not bugs, or not rc, or someone else's fault.
> 
> For example, if I want to use ifupdown then I probably don't want n-m
> to bring up even interfaces which exist but which I haven't mentioned
> in /etc/network/interfaces - but managing those interfaces is
> precisely the point of n-m.  So I'm cast back into "install n-m but
> disable it", which is clearly inferior.
> 
> The result is surely going to be more friction between users who find
> n-m doesn't work for them, and developers who insist on forcing n-m on
> them.

I keep thinking about this in the context of laptops, and forgetting the 
context of "traditional desktop boxes" and servers.  In the context of either, 
it's common to want to install Gnome without any wireless manager installed 
and use ifupdown "just like with any other server" -- and specifically not 
install n-m due to previous bad experiences people have had with it, or to 
have trouble figuring out how to configure n-m for a static IP if they aren't 
able to remove it.  [It can do it, but is apparently not intuitive.]

There are a couple of people at my local LUG that run Gnome on their server 
(usually on Ubuntu).  I've overheard a few discussions about the difficulties 
of removing n-m in this context, and the advice given to the server owner 
generally ranges between "remove n-m -- it's worth it" to "you might as well 
configure n-m for a static IP, because the system will fight you on removing 
it too much".

I thought running Gnome3 on a server was a crazy idea until I asked about it; 
the basic premise is that the server then has a similar interface as the 
traditional Desktop, and allows for running GUI administration programs.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 13 Oct 2012 13:54:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 13 Oct 2012 13:54:08 GMT) Full text and rfc822 format available.

Message #336 received at 688772@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Josselin Mouette <joss@debian.org>, 688772@bugs.debian.org, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sat, 13 Oct 2012 07:51:01 -0600
[Message part 1 (text/plain, inline)]
Josselin Mouette <joss@debian.org> writes:

> Le vendredi 12 octobre 2012 à 21:07 +0200, Stefano Zacchiroli a écrit :
>> For lack of a better synopsis, the argument there is "because recommends
>> do not behave properly across upgrades".
>
> And also, the purpose of metapackages is to ship dependencies.

Repeating this more times doesn't make it more true.  The purpose of
metapackages is to deliver meta-data, including dependency
information.  That information does not have to be, and in many cases
should *not* be, in the form of hard dependencies.

Bdale
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sun, 14 Oct 2012 17:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 14 Oct 2012 17:54:03 GMT) Full text and rfc822 format available.

Message #341 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sun, 14 Oct 2012 18:50:03 +0100
Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):
> Actually, Josselin did say, in one of his recent messages, the reason that
> I had hypothesized: that n-m is so much better that he's not sure that
> people who previously opted out of n-m stated a preference that should
> apply to the current n-m.

I did read that, and basically what it amounts to is this:

 N-M has improved enough that for a user who has deliberately decided
 to remove it, we should no longer respect that choice (as being no
 longer applicable to the current situation).

Now I acknowledge that there might be cases where such a statement
about a user's prior choice might be true.  I think such situations
will be very rare but it is possible that they might exist.

However, we are not making this decision in the abstract.  We are
making it for n-m, specifically.  And in the cases where a user has
deliberately removed n-m they will have made other arrangements for
their networking.  Under those circumstances reinstalling n-m during
the upgrade is certainly not helpful to the user; at best it does
nothing useful because n-m does not disturb their existing setup.  At
worst it breaks something and forces the user to untangle the mess.

> Whether or not one agrees with that reason, I do think it's cogent and
> goes directly to the point, namely upgrade behavior.

Do you think it's a good reason, in the case of n-m ?

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sun, 14 Oct 2012 19:27:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 14 Oct 2012 19:27:09 GMT) Full text and rfc822 format available.

Message #346 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sun, 14 Oct 2012 12:24:00 -0700
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):

>> Whether or not one agrees with that reason, I do think it's cogent and
>> goes directly to the point, namely upgrade behavior.

> Do you think it's a good reason, in the case of n-m ?

I'm hesitant to express a strong opinion.  I can see good arguments for
both sides.  The way in which integration of components in GNOME is done
has changed considerably in GNOME 3 as I understand it, and wicd does not
integrate well with the new way of doing integration.  The behavior of n-m
with statically-configured local networks has also improved considerably,
according to various discussion in this thread.

Having n-m take over from wicd during an upgrade is still awkward.
However, it's not at all clear that the reasons why I, at least, switched
to wicd when I was using GNOME would still apply, so it's possible that
many users will now be better off with n-m again.

All that weighs against what I think is a fairly compelling case for using
Recommends in metapackages.

I'm feeling particularly sensitive to the fact that I personally don't use
the software involved, in part because I prefer a different philosophical
approach to assembling my desktop, and therefore the reasons why I might
make decisions about components are not necessarily in the spirit of
GNOME.

That's the reason why I'm inclined to try to stay out of the decision as
much as possible and leave it to the GNOME maintainers, who know
considerably more about the system than I do.  While the current situation
is not the compromise that I would have proposed, it does feel like a
workable compromise (in conjunction with release notes), and I do think
it's valuable to compromise some in situations like this.

The tension in the discussion is making it very hard to hold that
position.  People on all sides of this discussion seem to be pushing it
towards becoming a referendum on the legitimacy of the Technical Committee
rather than a method for arriving at the best all-around compromise for
both GNOME users and the project, and that's making me really
uncomfortable.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sun, 14 Oct 2012 20:06:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 14 Oct 2012 20:06:05 GMT) Full text and rfc822 format available.

Message #351 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sun, 14 Oct 2012 21:03:07 +0100
Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):
> That's the reason why I'm inclined to try to stay out of the decision as
> much as possible and leave it to the GNOME maintainers, who know
> considerably more about the system than I do.

One might as well say that we should leave it to the users, who know
considerably more about their system.

It is important to remember that fundamentally the dispute here is not
between me and the gnome maintainers.  I don't have a dog in the fight
- or at least I didn't until I called out the maintainers' mistakes.
(I don't have gnome or gnome-core on any of my systems and I do have
network-manager on my netbook.)

The complainants are certain users who have decided against n-m.  The
question is whether the disbenefit to those users outweighs the
alleged benefit to other users who previously decided against n-m but
who in the opinion of the gnome maintainers would be best served by
reinstalling n-m.

It would take an extremely convincing argument for me to conclude that
we should overrule an explicit decision by a user in favour of a
blanket decision by a maintainer.

This is particularly true when these users have already decided not to
take the maintainer's advice.  By the decision not to install n-m,
those users have already overruled the maintainer for their own
systems.  To say that we think the maintainer knows best is going
against the clearly expressed opinion of a user who has deliberately
deinstalled n-m.

And, as you say, reinstalling n-m during the upgrade is deeply
problematic.  At the very best it will have no beneficial
effect until the user take explicit action to reconfigure their
networking to use n-m.  There is of course no particular reason why it
would be difficult for a user who changed their mind to reinstall n-m
as and when they felt like it - under conditions where they are
prepared for a failure of their networking and have the time and
inclination to reconfigure.

Under these circumstances I think it would be wrong of us to
countenance the maintainer's escalation in the war of competing
preferences.

> That's the reason why I'm inclined to try to stay out of the decision as
> much as possible and leave it to the GNOME maintainers, who know
> considerably more about the system than I do.  While the current situation
> is not the compromise that I would have proposed, it does feel like a
> workable compromise (in conjunction with release notes), and I do think
> it's valuable to compromise some in situations like this.

I think this proposed compromise is a compromise between the rights of
our users to configure their systems the way they want, and the
desire of the GNOME project and its supporters to make a strong
declaration about the status of Network Manager.

The claims that n-m has improved have to be seen in the context of a
persistent and long-running battle between that strong declaration and
users' desire to set up their systems the way they prefer.  The reason
there is so much heat here is precisely because of that long-running
battle.  But, frankly, in that battle I think there is a right side
and a wrong side.

I don't think we should compromise on the principle that the software
we ship should honour the explicitly stated wishes of our users.

> The tension in the discussion is making it very hard to hold that
> position.  People on all sides of this discussion seem to be pushing it
> towards becoming a referendum on the legitimacy of the Technical Committee
> rather than a method for arriving at the best all-around compromise for
> both GNOME users and the project, and that's making me really
> uncomfortable.

A referendum on the legitimacy of the TC would surely be a GR.

I'm just trying to do the right thing by the users.  That means that
when the user chooses to disregard the maintainers' advice, we should
not allow the maintainer to now impose that advice simply because the
maintainer claims that the basis for the user's original decision is
no longer true.  That is a decision for the user, not the maintainer,
to make.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 23 Oct 2012 22:21:07 GMT) Full text and rfc822 format available.

Message #354 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 23 Oct 2012 15:16:42 -0700
[Message part 1 (text/plain, inline)]
On Tue, 25 Sep 2012, Ian Jackson wrote:
> This bug is to track this issue. Please send all discussion on this
> topic only to this bug report. I will make sure that the gnome
> maintainers are pointed to this bug report.

Discussion seems to have stopped on this bug; I have drafted an
additional set of options for discussion, both of which borrow
liberally from ian's draft, and are presented below.

I'd like to either reconcile these options in the next few days so we
can vote on this issue and resolve it before it impacts the release
schedule. [I don't anticipate calling for votes before our meeting on
Thursday, but we should at least try to get any preliminaries out of
the way first if possible.]


Don Armstrong

-- 
When I was a kid I used to pray every night for a new bicycle. Then I 
realized that the Lord doesn't work that way so I stole one and asked
Him to forgive me.
 -- Emo Philips.

http://www.donarmstrong.com              http://rzlab.ucr.edu
[don_draft.txt (text/plain, attachment)]
[ian_draft.txt (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 01:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sam Hartman <hartmans@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 01:42:02 GMT) Full text and rfc822 format available.

Message #359 received at 688772@bugs.debian.org (full text, mbox):

From: Sam Hartman <hartmans@debian.org>
To: Don Armstrong <don@debian.org>
Cc: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 23 Oct 2012 21:29:43 -0400
Don, in your option 4B, I wonder if it would be a good idea to  have the
depend be something like g-n-m|wicd|no-network-manager

ANd have an empty extra package that users can install if they really
want neither n-m or wicd?

While I don't get a vote, I think that would be a reasonable option if
you buy the idea that you want to install n-m for people who uninstalled
it for squeeze, but you still want a way for people to say "no I hate
n-m".

I think 4A is a better option, bum my proposal may help the question of
whether the TC missed another case where n-m is the wrong answer.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 01:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 01:57:03 GMT) Full text and rfc822 format available.

Message #364 received at 688772@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Sam Hartman <hartmans@debian.org>
Cc: Don Armstrong <don@debian.org>, 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 03:53:27 +0200
[Message part 1 (text/plain, inline)]
On 24.10.2012 03:29, Sam Hartman wrote:
> Don, in your option 4B, I wonder if it would be a good idea to  have the
> depend be something like g-n-m|wicd|no-network-manager

The "gnome" meta-package certainly won't get an alternative dependency
on wicd. That would be completely stupid and miss the point of this
dependency. The GNOME desktop has zero integration with wicd, so this
alternative dependency is completely backwards.
Why don't you force a dependency on ifupdown on us, or ifplugd or whatever.

This whole crusade by the ctte is so ridiculous, but unfortunately I
can't laugh about that anymore.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 08:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 08:00:03 GMT) Full text and rfc822 format available.

Message #369 received at 688772@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: Michael Biebl <biebl@debian.org>, 688772@bugs.debian.org
Cc: Sam Hartman <hartmans@debian.org>, Don Armstrong <don@debian.org>, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 09:57:07 +0200
* Michael Biebl (biebl@debian.org) [121024 03:57]:
> On 24.10.2012 03:29, Sam Hartman wrote:
> > Don, in your option 4B, I wonder if it would be a good idea to  have the
> > depend be something like g-n-m|wicd|no-network-manager
> 
> The "gnome" meta-package certainly won't get an alternative dependency
> on wicd. That would be completely stupid and miss the point of this
> dependency. The GNOME desktop has zero integration with wicd, so this
> alternative dependency is completely backwards.

You think it would be better to move it to recommends instead?


> Why don't you force a dependency on ifupdown on us, or ifplugd or whatever.

Do you think that would be better for our users?


> This whole crusade by the ctte is so ridiculous, but unfortunately I
> can't laugh about that anymore.

Where is there a crusade? I don't see any. And btw, it doesn't help to
replace reason by emotion.



Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 08:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 08:39:06 GMT) Full text and rfc822 format available.

Message #374 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 10:38:26 +0200
Le mercredi 24 octobre 2012 à 09:57 +0200, Andreas Barth a écrit : 
> > This whole crusade by the ctte is so ridiculous, but unfortunately I
> > can't laugh about that anymore.
> 
> Where is there a crusade? I don't see any. 

Maybe you should remove that blindfold of yours?

> And btw, it doesn't help to replace reason by emotion.

Reason has abandoned this discussion long ago. This has always been
about people who don’t even use GNOME but who won’t accept the idea that
we would install NM on other people’s computers.

-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 08:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 08:57:02 GMT) Full text and rfc822 format available.

Message #379 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 10:51:49 +0200
Let me comment on the proposals again.

Le mardi 23 octobre 2012 à 15:16 -0700, Don Armstrong a écrit :
> 2. Our intent, as stated in the rationale section of our previous
>    decision (#681834, paras 3 and 5), is that squeeze users who have
>    gnome installed but not network-manager do not find that
>    network-manager becomes installed when they upgrade to wheezy.

There lies the real disagreement.

Our very intent is that squeeze users who have gnome installed but not
NM *do* find that NM becomes installed when they upgrade to wheezy.
(Actually we should have done that for the lenny→squeeze upgrade but
vocal people already won that time.)

The fact that it could potentially, in very specific to-be-described
cases, break something, should be documented in the release notes.

Everything else Ian and you have proposed derives from the fact that you
want to force NM out.

> B 4. We overrule the decision of the meta-gnome maintainers to add a
> B    dependency from gnome to network-manager-gnome; this dependency
> B    should be replaced with a dependecy on network-manager-gnome (>=
> B    0.9.4) | wicd.

Seriously, WTFF? Is it just a show-off option to make us think it’s
better to use a Recommends instead?

> B 5. Bugs in network-manager-gnome which break the functionality of
> B    existing /etc/network/interfaces rules are to be considered RC.

Not replacing /e/n/i means that NM will not detect your connection, and
as such your desktop will be unusable. If your intent is to generate RC
bugs, congratulations, but that will not help with the release.

And as for Ian’s hateful prose…

> 8. We specifically forbid anyone from introducing in wheezy, or
>    in sid until wheezy is released:
>     a. Any new or enhanced dependencies, or any other mechanisms,
>        which increase the likelihood of network-manager being
>        installed;
>     b. Any new or enhanced user-facing warnings, imprecations, or
>        other kinds of message regarding the alleged desirability or
>        requirement to install network-manager;
>     c. Any change which in any way impairs (or further impairs) the
>        functioning of systems with GNOME components installed but
>        without network-manager;
>     d. Any change which is contrary to the spirit or intent of either
>        our previous resolution in #681834 or this resolution.
>    without first obtaining the permission of at least one member of
>    the Technical Committee.

Does it really need commenting?

> 9. It is disappointing that this proposed solution to the problem was
>    not mentioned during the TC discussion.  If it had been, it could
>    have been accepted or rejected by the TC at the time.

Maybe more communication would have occurred if this discussion had been
driven by a reasonable person.

> 10. We remind everyone that the Constitution requires members of the
>    project not to work against decisions properly made according to
>    the project's governance processes.  On this occasion we do not
>    feel it necessary to refer anyone to the Debian Account Managers
>    asking for a review of their status.

I still stand on the stance that Ian’s behavior is unacceptable; and
proposing this kind of passive-agressive wording in a TC decision is
part of the problem. He should step down from the committee or be forced
to do so.

In the current situation, I do not feel bound by any decisions the
committee might make.

-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 11:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 11:15:03 GMT) Full text and rfc822 format available.

Message #384 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Michael Biebl <biebl@debian.org>, 688772@bugs.debian.org
Cc: Sam Hartman <hartmans@debian.org>, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 12:13:50 +0100
Michael Biebl writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On 24.10.2012 03:29, Sam Hartman wrote:
> > Don, in your option 4B, I wonder if it would be a good idea to  have the
> > depend be something like g-n-m|wicd|no-network-manager
> 
> The "gnome" meta-package certainly won't get an alternative dependency
> on wicd. That would be completely stupid and miss the point of this
> dependency. The GNOME desktop has zero integration with wicd, so this
> alternative dependency is completely backwards.
> Why don't you force a dependency on ifupdown on us, or ifplugd or whatever.

Shockingly, I find myself in agreement with at least some of the views
of the GNOME maintainers.  As I have said, I don't think this proposed
dependency on wicd makes any kind of sense.  It achieves neither the
objectives of the GNOME maintainers nor the objectives of users who
have chosen to remove n-m.

AIUI the point of introducing wicd was to try to find some kind of
compromise.  Given the response from the GNOME maintainers, I think it
is a bad idea.

Of course, Don, you're still entitled to put it on the ballot.  And to
be honest if it's there I would still vote for it over FD as it does
assist some of the affected users.  But really I think it's just
introducing confusion (or, indeed, is itself the result of confusion)
and it should be dropped.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 11:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 11:24:03 GMT) Full text and rfc822 format available.

Message #389 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 12:21:43 +0100
Josselin Mouette writes ("Bug#688772: gnome Depends network-manager-gnome"):
> Le mardi 23 octobre 2012 à 15:16 -0700, Don Armstrong a écrit :
> > 2. Our intent, as stated in the rationale section of our previous
> >    decision (#681834, paras 3 and 5), is that squeeze users who have
> >    gnome installed but not network-manager do not find that
> >    network-manager becomes installed when they upgrade to wheezy.
> 
> There lies the real disagreement.
> 
> Our very intent is that squeeze users who have gnome installed but not
> NM *do* find that NM becomes installed when they upgrade to wheezy.

Thank you for stating this so clearly.  

I'm not sure there's much more to be said about this.  I would like to
remind my colleagues on the TC that these users are users who have
deliberately chosen to disregard the recommendation of n-m.  (And yes,
I do mean also users who have globally disabled recommends.)

So as I have said we face a clear choice between respecting the
explicit decisions of our users, and the strongly expressed views of
the maintainer.  There can be only one answer to this, surely ?

> Everything else Ian and you have proposed derives from the fact that you
> want to force NM out.

What I want is for users who have forced NM out to have that decision
respected.  I am entirely happy for NM to remain the default.

> > B 4. We overrule the decision of the meta-gnome maintainers to add a
> > B    dependency from gnome to network-manager-gnome; this dependency
> > B    should be replaced with a dependecy on network-manager-gnome (>=
> > B    0.9.4) | wicd.
> 
> Seriously, WTFF? Is it just a show-off option to make us think it’s
> better to use a Recommends instead?

As I have said I think this option is a bad idea.  But it has arisen
as a result of attempts by my colleagues on the TC to find a
compromise position between your view, and mine.  In the absence of
clear and technically-grounded statements from the GNOME maintainers
this has been happening in a vacuum, with my colleagues apparently
guessing what your objectives are.

> And as for Ian’s hateful prose…
> 
> > 8. We specifically forbid anyone from introducing in wheezy, or
> >    in sid until wheezy is released:
> >     a. Any new or enhanced dependencies, or any other mechanisms,
> >        which increase the likelihood of network-manager being
> >        installed;
> >     b. Any new or enhanced user-facing warnings, imprecations, or
> >        other kinds of message regarding the alleged desirability or
> >        requirement to install network-manager;
> >     c. Any change which in any way impairs (or further impairs) the
> >        functioning of systems with GNOME components installed but
> >        without network-manager;
> >     d. Any change which is contrary to the spirit or intent of either
> >        our previous resolution in #681834 or this resolution.
> >    without first obtaining the permission of at least one member of
> >    the Technical Committee.
> 
> Does it really need commenting?

I'm glad to hear that you don't intend to do any of these things.
Thank you.  Then there is no need for us to say so explicitly that you
shouldn't.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 11:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 11:27:03 GMT) Full text and rfc822 format available.

Message #394 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 12:23:27 +0100
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> Discussion seems to have stopped on this bug; I have drafted an
> additional set of options for discussion, both of which borrow
> liberally from ian's draft, and are presented below.

Thanks.

> I'd like to either reconcile these options in the next few days so we
> can vote on this issue and resolve it before it impacts the release
> schedule. [I don't anticipate calling for votes before our meeting on
> Thursday, but we should at least try to get any preliminaries out of
> the way first if possible.]

I would be happy with your option A.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 15:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 15:57:03 GMT) Full text and rfc822 format available.

Message #399 received at 688772@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Josselin Mouette <joss@debian.org>, 688772@bugs.debian.org, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 09:53:40 -0600
[Message part 1 (text/plain, inline)]
Josselin Mouette <joss@debian.org> writes:

> Our very intent is that squeeze users who have gnome installed but not
> NM *do* find that NM becomes installed when they upgrade to wheezy.

Thank you for stating this so plainly.

>> 9. It is disappointing that this proposed solution to the problem was
>>    not mentioned during the TC discussion.  If it had been, it could
>>    have been accepted or rejected by the TC at the time.
>
> Maybe more communication would have occurred if this discussion had been
> driven by a reasonable person.
  ...
> I still stand on the stance that Ian’s behavior is unacceptable; and
> proposing this kind of passive-agressive wording in a TC decision is
> part of the problem. 

While I understand your feelings on this and agree that Ian has allowed
his emotions to get the better of him at least once in this process, as
I've already asserted, one of the reason we have a *committee* defined
by our constitution to act as the ultimate decision making authority on
technical issues is precisely to ensure that the emotions of a single
individual do not dictate project policy.

Please un-wind your emotional reaction to Ian's participation in this
process, and realize that his is only one voice, and you are dealing
with a level-headed committee that is trying very hard to make the best
decisions possible for the project overall.  There is no "crusade" here
beyond the genuine desire to deliver on item 4 of our Social Contract,
and the longer you, Michael, and others continue to assert that there
is, the harder it is for those of us less *emotionally* invested in this
decision to stay focused on doing the right things for Debian.

> He should step down from the committee or be forced
> to do so.

Personally, I think Ian's usual objectivity and attention to detail are
valuable to the committee... enough so that I'm willing to cope with 
an occasional reminder that he is only human, and I would not initiate a
move to remove him from the committee per 6.2.5 of our Constitution.

However, if you feel sufficiently strongly about this, 4.1.4 of our
Constitution suggests that a GR resulting in a super-majority of support
From voting members of the project should suffice to remove a TC member.

> In the current situation, I do not feel bound by any decisions the
> committee might make.

A standard part of becoming a DD through the NM process is accepting the
Social Contract and agreeing to be bound by our Constitution.  And it is
our Constitution that defines the existence and role of the Technical
Committee.

I urge to you reconsider and retract this statement. 

Regards,

Bdale
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 17:15:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 17:15:08 GMT) Full text and rfc822 format available.

Message #404 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 10:13:54 -0700
On Wed, 24 Oct 2012, Josselin Mouette wrote:
> Le mardi 23 octobre 2012 à 15:16 -0700, Don Armstrong a écrit :
> > 2. Our intent, as stated in the rationale section of our previous
> >    decision (#681834, paras 3 and 5), is that squeeze users who have
> >    gnome installed but not network-manager do not find that
> >    network-manager becomes installed when they upgrade to wheezy.
> 
> There lies the real disagreement.
> 
> Our very intent is that squeeze users who have gnome installed but not
> NM *do* find that NM becomes installed when they upgrade to wheezy.
> (Actually we should have done that for the lenny→squeeze upgrade but
> vocal people already won that time.)

What in particular breaks if NM is not installed?[2] I personally
understand that the gnome maintainers want NM to be installed by
default in all but unusual configurations, which is why I even
bothered to draft option B.

> The fact that it could potentially, in very specific to-be-described
> cases, break something, should be documented in the release notes.

This is certainly one approach that could be taken. However, from the
information available to me, the breakage caused by these situations
outweighs the breakage caused by not having NM installed[2] if someone
has chosen to ignore recommends.

> Everything else Ian and you have proposed derives from the fact that
> you want to force NM out.

My only concern is for the users of gnome; I don't have a personal
stake in this race at all. Continuing to ascribe these motivations to
me and Ian is hurtful, and not appropriate. Please stop.

> > B 4. We overrule the decision of the meta-gnome maintainers to add a
> > B    dependency from gnome to network-manager-gnome; this dependency
> > B    should be replaced with a dependecy on network-manager-gnome (>=
> > B    0.9.4) | wicd.
> 
> Seriously, WTFF? Is it just a show-off option to make us think it’s
> better to use a Recommends instead?

I proposed this option[1] as an attempt to mitigate the breakage
caused by having NM installed when wicd is being used to configure
networking. I personally don't like it, but I proposed it to attempt
to address your concerns about making sure that NM was installed,
while still mitigating breakage for people who have installed wicd.

> > B 5. Bugs in network-manager-gnome which break the functionality of
> > B    existing /etc/network/interfaces rules are to be considered RC.
> 
> Not replacing /e/n/i means that NM will not detect your connection,
> and as such your desktop will be unusable.

In what specific way?[2]

Don Armstrong

1: http://lists.debian.org/debian-ctte/2012/10/msg00027.html with
rationale here:
http://lists.debian.org/debian-ctte/2012/10/msg00036.html along with
the ensuing thread.

2: I still don't have an answer to this question after I and others
have repeatedly asked for it.
http://lists.debian.org/debian-ctte/2012/10/msg00011.html
-- 
life's not a paragraph
And death i think is no parenthesis
 -- e.e. cummings "Four VII" _is 5_

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 17:21:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 17:21:09 GMT) Full text and rfc822 format available.

Message #409 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 10:18:31 -0700
On Wed, 24 Oct 2012, Ian Jackson wrote:
> Shockingly, I find myself in agreement with at least some of the
> views of the GNOME maintainers. As I have said, I don't think this
> proposed dependency on wicd makes any kind of sense. It achieves
> neither the objectives of the GNOME maintainers nor the objectives
> of users who have chosen to remove n-m.
> 
> AIUI the point of introducing wicd was to try to find some kind of
> compromise. Given the response from the GNOME maintainers, I think
> it is a bad idea.

That's correct. I was hoping to find some kind of compromise that
would satisfy the gnome maintainers' requirement to have NM installed
by default whilst mitigating breakage.

Since the option appears to have done neither, and I'm not
particularly enamored with it either, I'm going to drop it. [If
someone else feels strongly about having it on the ballot, please feel
free to reintroduce it.]


Don Armstrong

-- 
But if, after all, we are on the wrong track, what then? Only
disappointed human hopes, nothing more. And even if we perish, what
will it matter in the endless cycles of eternity?
 -- Fridtjof Nansen _Farthest North_ p152

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 17:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 17:30:03 GMT) Full text and rfc822 format available.

Message #414 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 24 Oct 2012 18:26:48 +0100
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Wed, 24 Oct 2012, Ian Jackson wrote:
> > AIUI the point of introducing wicd was to try to find some kind of
> > compromise. Given the response from the GNOME maintainers, I think
> > it is a bad idea.
> 
> That's correct. I was hoping to find some kind of compromise that
> would satisfy the gnome maintainers' requirement to have NM installed
> by default whilst mitigating breakage.

Right.

(Although I need to quibble with your "by default".  No-one is
suggesting that n-m should not be installed by default.  The gnome
maintainers' requirement is to have n-m installed even when the user
has previously deliberately deinstalled it.)

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 24 Oct 2012 22:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 24 Oct 2012 22:15:03 GMT) Full text and rfc822 format available.

Message #419 received at 688772@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@debian.org>
To: Josselin Mouette <joss@debian.org>
Cc: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 25 Oct 2012 00:13:44 +0200
On 13009 March 1977, Josselin Mouette wrote:

> In the current situation, I do not feel bound by any decisions the
> committee might make.

You know, if it really comes to one more CTTE decision around NM and
Gnome, which you don't like - the above is a pretty clean resignation
from the project. Which would be a shame - but still, directly violating
one of our core documents? Seriously?

-- 
bye, Joerg
<madduck> and yes, the ftpmasters are not the most clueful people



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 25 Oct 2012 09:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 25 Oct 2012 09:21:06 GMT) Full text and rfc822 format available.

Message #424 received at 688772@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: Joerg Jaspert <joerg@debian.org>
Cc: 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 25 Oct 2012 11:19:58 +0200
Hi,

Le jeudi 25 octobre 2012 à 00:13 +0200, Joerg Jaspert a écrit : 
> On 13009 March 1977, Josselin Mouette wrote:
> 
> > In the current situation, I do not feel bound by any decisions the
> > committee might make.
> 
> You know, if it really comes to one more CTTE decision around NM and
> Gnome, which you don't like - the above is a pretty clean resignation
> from the project. Which would be a shame - but still, directly violating
> one of our core documents? Seriously?

I’m not the one who has violated the Constitution so far. The CTTE, on
the other hand, is currently acting in direct violation of Constitution
§6.3.6. No discussion was ever attempted after the upload of meta-gnome3
1:3.4+2 which implements the decision for bug#645656. There is consensus
among the GNOME team that this is the correct course of action, and no
one has requested a decision from the TC apart from Ian himself.

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 25 Oct 2012 15:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 25 Oct 2012 15:21:06 GMT) Full text and rfc822 format available.

Message #429 received at 688772@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 688772@bugs.debian.org
Cc: Jeremy Bicha <jbicha@ubuntu.com>
Subject: Re: Bug#681834: Call for votes on network-manager, gnome
Date: Thu, 25 Oct 2012 17:18:42 +0200
Hi,

this is a reply to a message from the older bug but it has never
been answered and I believe it's useful to take a proper decision
so I answer in the new bug:

On Tue, 11 Sep 2012, Ian Jackson wrote:
> Jeremy Bicha writes ("Bug#681834: Call for votes on network-manager, gnome"):
> > I see two things missing from this resolution:
> >
> > 1. GNOME has a stronger dependency on NM than they did when Squeeze
> > was released. GNOME Shell now has a hard dependency on NM.
> 
> Do you mean
>   http://packages.debian.org/wheezy/gnome-shell
> ?  Because that doesn't have any dependency on network-manager.
> 
> So on a Debian wheezy system it is possible to install gnome-shell
> without network-manager.  (There is a dependency on
> gir1.2-networkmanager-1.0 but that's just introspection data and
> doesn't pull-in n-m itself, just some libraries.)

Nobody responded to this but while discussing with the GNOME maintainers
I quickly got the answer. NM is a build-time dependency of GNOME Shell
but Debian has patched GNOME Shell to make it optional to allow
it to compile on kfreebsd:
http://patch-tracker.debian.org/patch/series/view/gnome-shell/3.4.2-2/10-make-NetworkManager-optional.patch

During run time, NM is not required but its absence results in:
- non-working network configuration screens in the GNOME settings
- empathy/evolution and the like not being aware when they are offline
  and thus trying to connect when they should not (and generate/display
  potentially annoying errors)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 25 Oct 2012 16:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 25 Oct 2012 16:21:06 GMT) Full text and rfc822 format available.

Message #434 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>, secretary@debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 25 Oct 2012 09:17:59 -0700
On Thu, 25 Oct 2012, Josselin Mouette wrote:
> Le jeudi 25 octobre 2012 à 00:13 +0200, Joerg Jaspert a écrit : 
> > On 13009 March 1977, Josselin Mouette wrote:
> > 
> > > In the current situation, I do not feel bound by any decisions the
> > > committee might make.
> > 
> > You know, if it really comes to one more CTTE decision around NM and
> > Gnome, which you don't like - the above is a pretty clean resignation
> > from the project. Which would be a shame - but still, directly violating
> > one of our core documents? Seriously?
> 
> I’m not the one who has violated the Constitution so far. The CTTE, on
> the other hand, is currently acting in direct violation of Constitution
> §6.3.6. No discussion was ever attempted after the upload of meta-gnome3
> 1:3.4+2 which implements the decision for bug#645656.

It's true that discussion and consensus building should have happened
before any drafting (even if just as a general courtesy.) However,
we've been discussing this issue with the attempt to reach consensus
or at least some understanding for the past month, and still have yet
to even start to make a technical decision. [Not to mention the fact
that it stems from an issue which has been discussed extensively for
the past six months.]

That said, if I'm wrong, and you believe that there is a compromise
which would resolve the concerns raised beyond those already presented
(status quo with/without release notes), now would be the time to
present it.

Finally, if you believe the committee to be acting improperly, please
point it out. It's easy for us to either change, or if we disagree in
the interpretation of the constitution, get the secretary to interpret
the constitution for us. [I've gone ahead and put Kurt in the loop so he can 


Don Armstrong

-- 
I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 25 Oct 2012 16:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 25 Oct 2012 16:39:06 GMT) Full text and rfc822 format available.

Message #439 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>, secretary@debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 25 Oct 2012 17:36:40 +0100
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Thu, 25 Oct 2012, Josselin Mouette wrote:
> > I’m not the one who has violated the Constitution so far. The CTTE, on
> > the other hand, is currently acting in direct violation of Constitution
> > §6.3.6. No discussion was ever attempted after the upload of meta-gnome3
> > 1:3.4+2 which implements the decision for bug#645656.
> 
> It's true that discussion and consensus building should have happened
> before any drafting (even if just as a general courtesy.) However,
> we've been discussing this issue with the attempt to reach consensus
> or at least some understanding for the past month, and still have yet
> to even start to make a technical decision. [Not to mention the fact
> that it stems from an issue which has been discussed extensively for
> the past six months.]

Personally I don't see this as a new issue.  As you say it stems from
the previous issue which seems not to have been fully closed.  An
alternative interpretation would be that I, wearing my "individual"
hat, referred the matter to the TC.  I don't think there's anything in
the constitution preventing a TC member from referring a matter to the
TC.

I think it would have been quite wrong to require one of the original
complainants, or a new complainant, to make an explicit referral to
the TC of what I consider to be the maintainers' failure to
satisfactorily implement the previous TC resolution; or to put it
another way, the failure of the previous TC resolution to explicitly
rule out an undesirable approach which wasn't anticipated in the
previous discussions.

And from a practical point of view, I don't think it would be
reasonable to expect anyone to voluntarily stick their head above the
parapet into the toxic atmosphere surrounding this issue.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 25 Oct 2012 16:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jeremy Bicha <jbicha@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 25 Oct 2012 16:51:06 GMT) Full text and rfc822 format available.

Message #444 received at 688772@bugs.debian.org (full text, mbox):

From: Jeremy Bicha <jbicha@ubuntu.com>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 25 Oct 2012 12:47:14 -0400
On 25 October 2012 12:17, Don Armstrong <don@debian.org> wrote:
> That said, if I'm wrong, and you believe that there is a compromise
> which would resolve the concerns raised beyond those already presented
> (status quo with/without release notes), now would be the time to
> present it.

My proposal is to:
1. Add a paragraph to the Release Notes with the one line command
people should use if they don't want NetworkManager running:
"update-rc.d disable network-manager"
2. And cases where that doesn't work are RC.

The advantages of this proposal:
1. Users that don't want NetworkManager messing with their networking
configuration can get it and wouldn't have to worry about babysitting
upgrades or new installs to make sure that NetworkManager isn't pulled
in by some package.
2. Users who've upgraded from Lenny can be sure to have NetworkManager
installed and working, which really is far better for most GNOME users
than anything else. Those that have opted out previously are given an
opportunity to revisit their decision since the circumstances have
changed significantly.
3. Wouldn't require a CTTE resolution
4. Would continue to allow the Debian GNOME Team to manage their
metapackages based on what GNOME says is required and what the team
feel fits best into a standard GNOME desktop.
5. Would not put an implicit duty on the GNOME Team to come before the
CTTE every time they intend to change something in their metapackage
that might make someone annoyed.

The Technical Committee complaining about NetworkManager seems to the
GNOME Team to be a bit misplaced.
- Why don't they complain about how GNOME3 is significantly different
than what was shipped in previous Debian releases?
- Why don't they complain about epiphany or iceweasel being a depends
which affects far more people in a far more visible way? I mean, have
you looked at what the "gnome" package depends on? evolution,
gnome-games, gimp, inkscape, rhythmbox, transmission, etc? And "gnome"
depends on less stuff now than it did for squeeze.
- Why not a larger discussion about the role of depends in
metapackages? That discussion is obviously too late for Wheezy but it
probably should happen well before Jessie is relased.
- Shouldn't working and easy to use wireless (aka NetworkManager) be
considered part of the basic desktop infrastructure? And users who
don't like those decisions being made for them shouldn't use "gnome"?

Jeremy



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 25 Oct 2012 18:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 25 Oct 2012 18:12:03 GMT) Full text and rfc822 format available.

Message #449 received at 688772@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Jeremy Bicha <jbicha@ubuntu.com>, 688772@bugs.debian.org, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 25 Oct 2012 12:10:16 -0600
[Message part 1 (text/plain, inline)]
Jeremy Bicha <jbicha@ubuntu.com> writes:

> - Why don't they complain about how GNOME3 is significantly different
> than what was shipped in previous Debian releases?

It's not the role of the TC to "complain".  It's our role to resolve
issues that are brought to us for resolution.

> - Why don't they complain about epiphany or iceweasel being a depends
> which affects far more people in a far more visible way? I mean, have
> you looked at what the "gnome" package depends on? evolution,
> gnome-games, gimp, inkscape, rhythmbox, transmission, etc? And "gnome"
> depends on less stuff now than it did for squeeze.

Same as above.

> - Why not a larger discussion about the role of depends in
> metapackages? That discussion is obviously too late for Wheezy but it
> probably should happen well before Jessie is relased.

Actually, I think I *did* suggest that such a discussion would be
appropriate, but clearly this should not be allowed to delay wheezy.

> - Shouldn't working and easy to use wireless (aka NetworkManager) be
> considered part of the basic desktop infrastructure? 

Sure.  I'd like world peace, too, while we're at it!  ;-)

> And users who
> don't like those decisions being made for them shouldn't use "gnome"?

This is indeed one of the reasons that I personally do not use "gnome".

Bdale
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 25 Oct 2012 19:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 25 Oct 2012 19:54:03 GMT) Full text and rfc822 format available.

Message #454 received at 688772@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 688772@bugs.debian.org, Jeremy Bicha <jbicha@ubuntu.com>
Subject: Re: Bug#681834: Call for votes on network-manager, gnome
Date: Thu, 25 Oct 2012 21:52:00 +0200
Hi,

On Thu, 25 Oct 2012, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: Bug#681834: Call for votes on network-manager, gnome"):
> > Nobody responded to this but while discussing with the GNOME maintainers
> > I quickly got the answer. NM is a build-time dependency of GNOME Shell
> > but Debian has patched GNOME Shell to make it optional to allow
> > it to compile on kfreebsd:
> > http://patch-tracker.debian.org/patch/series/view/gnome-shell/3.4.2-2/10-make-NetworkManager-optional.patch
> 
> I see.  That would seem to imply that it's not possible to do a
> release build of gnome-shell on a system without n-m (which I guess
> would include many buildd chroots!)
> 
> I looked at the Build-Depends for gnome-shell in wheezy and it doesn't
> mention network-manager at all.  That patch seems to want to
> autodetect network-manager.

In the Build-Depends I see this "libnm-glib-dev (>= 0.9) [linux-any],
libnm-util-dev (>= 0.9) [linux-any]" and "nm" stands for Network Manager
here.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 25 Oct 2012 20:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 25 Oct 2012 20:51:04 GMT) Full text and rfc822 format available.

Message #459 received at 688772@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: Jeremy Bicha <jbicha@ubuntu.com>, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 25 Oct 2012 22:47:01 +0200
* Jeremy Bicha (jbicha@ubuntu.com) [121025 18:51]:
> On 25 October 2012 12:17, Don Armstrong <don@debian.org> wrote:
> > That said, if I'm wrong, and you believe that there is a compromise
> > which would resolve the concerns raised beyond those already presented
> > (status quo with/without release notes), now would be the time to
> > present it.
> 
> My proposal is to:
> 1. Add a paragraph to the Release Notes with the one line command
> people should use if they don't want NetworkManager running:
> "update-rc.d disable network-manager"
> 2. And cases where that doesn't work are RC.

How would that prevent startup of n-m during upgrades from stable to
next-stable?  (Which could already present issues, especially if the
system is remote managed)



Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 25 Oct 2012 22:30:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 25 Oct 2012 22:30:05 GMT) Full text and rfc822 format available.

Message #464 received at 688772@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Andreas Barth <aba@ayous.org>
Cc: Jeremy Bicha <jbicha@ubuntu.com>, 688772@bugs.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 26 Oct 2012 00:27:58 +0200
[Message part 1 (text/plain, inline)]
On 25.10.2012 22:47, Andreas Barth wrote:
> * Jeremy Bicha (jbicha@ubuntu.com) [121025 18:51]:
>> On 25 October 2012 12:17, Don Armstrong <don@debian.org> wrote:
>>> That said, if I'm wrong, and you believe that there is a compromise
>>> which would resolve the concerns raised beyond those already presented
>>> (status quo with/without release notes), now would be the time to
>>> present it.
>>
>> My proposal is to:
>> 1. Add a paragraph to the Release Notes with the one line command
>> people should use if they don't want NetworkManager running:
>> "update-rc.d disable network-manager"
>> 2. And cases where that doesn't work are RC.
> 
> How would that prevent startup of n-m during upgrades from stable to
> next-stable?  (Which could already present issues, especially if the
> system is remote managed)

I've been discussing with jordi today about this issue.

One idea that came up was to check wether wicd is in use (or for that
matter ifupdown), and then show a debconf prompt explaining the
situation, and letting the user chose if he wants to take over network
management by NetworkManager.
It would work similar to how we currently handle multiple installed
display managers, like gdm3 or kdm (btw, gdm3 is currently a hard
depends of gnome-core).
If the users choses no, we could disable the service via update-rc.d
disable, so the invoke-rc.d later on in postinst would not start NM.

This would also help in situations where users install both wicd and
network-manager by accident, which usually doesn't really work well
since e.g. both spawn their own instance of wpa_supplicant.

A more detailed reply will follow soon.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 26 Oct 2012 12:21:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 26 Oct 2012 12:21:07 GMT) Full text and rfc822 format available.

Message #469 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Michael Biebl <biebl@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 26 Oct 2012 08:19:46 -0400
[Message part 1 (text/plain, inline)]
On Thursday, October 25, 2012 18:27:58, Michael Biebl wrote:
> On 25.10.2012 22:47, Andreas Barth wrote:
> > * Jeremy Bicha (jbicha@ubuntu.com) [121025 18:51]:
> >> On 25 October 2012 12:17, Don Armstrong <don@debian.org> wrote:
> >>> That said, if I'm wrong, and you believe that there is a compromise
> >>> which would resolve the concerns raised beyond those already presented
> >>> (status quo with/without release notes), now would be the time to
> >>> present it.
> >> 
> >> My proposal is to:
> >> 1. Add a paragraph to the Release Notes with the one line command
> >> people should use if they don't want NetworkManager running:
> >> "update-rc.d disable network-manager"
> >> 2. And cases where that doesn't work are RC.
> > 
> > How would that prevent startup of n-m during upgrades from stable to
> > next-stable?  (Which could already present issues, especially if the
> > system is remote managed)
> 
> I've been discussing with jordi today about this issue.
>
> One idea that came up was to check wether wicd is in use (or for that
> matter ifupdown), and then show a debconf prompt explaining the
> situation, and letting the user chose if he wants to take over network
> management by NetworkManager.
> It would work similar to how we currently handle multiple installed
> display managers, like gdm3 or kdm (btw, gdm3 is currently a hard
> depends of gnome-core).
> If the users choses no, we could disable the service via update-rc.d
> disable, so the invoke-rc.d later on in postinst would not start NM.
> 
> This would also help in situations where users install both wicd and
> network-manager by accident, which usually doesn't really work well
> since e.g. both spawn their own instance of wpa_supplicant.
> 
> A more detailed reply will follow soon.

This is a good suggestion, and one which I think would work around all of the 
breakage concerns I raised on this issue.  Thank you for putting in the effort 
for coming up with this option.

A tweak I'd suggest considering would be to reverse the logic of the test of 
when to show the debconf prompt -- because there are several possible tools 
for setting up networking like iwconfig, manually using wpa_supplicant, 
commands in rc.local, etc, such that trying to test for all of the specific 
situations of when to show the option might be frustrating to track down 
competely.  What we /do/ know is that there are two known situations where the 
user does /not/ need to see the choice to disable N-M, which is

   A) when N-M is already installed and running, or
   B) when N-M is installed but disabled via update-rc.d

I think this effectively reduces down to checking if N-M is already installed 
and prompting if it's not.  Well, unless you also want to test if it's running 
to take into consideration the possibility that N-M could be locally installed 
outside of package management, in which also installing N-M as a package would 
be... weird.  ;-)

The last thing I'm wondering about are the concerns from the Gnome team about 
whether empathy or evolution would know if you're online -- which in this case 
means if they do if N-M is installed but not running.  If they do then this 
solution would have that as an advantage.  If it doesn't then (at least on the 
surface) this solution seems similar to N-M being a Recommends in the meta-
gnome package such that it doesn't have to be installed.  [I'm not bringing 
this up as an argument against choosing this solution because I think the 
solution would work, but rather I'm trying to objectively evaluate what the 
effect this solution would have and how it compares to other possibilities.]

Thanks again.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 26 Oct 2012 17:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 26 Oct 2012 17:03:03 GMT) Full text and rfc822 format available.

Message #474 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 26 Oct 2012 10:02:22 -0700
On Fri, 26 Oct 2012, Chris Knadle wrote:
> I think this effectively reduces down to checking if N-M is already
> installed and prompting if it's not.

That means that you would prompt on any new NM install, which means
yet another box that users have to click/press enter through. That's a
ton of additional work for users, with the added possibility of users
getting the option wrong and ending up with NM not handling their
networking for some obscure Debian-specific reason. It's not like the
set of configurations where NM probably shouldn't be run is that big.


Don Armstrong

-- 
The computer allows you to make mistakes faster than any other
invention, with the possible exception of handguns and tequila
 -- Mitch Ratcliffe

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 30 Oct 2012 21:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 30 Oct 2012 21:15:03 GMT) Full text and rfc822 format available.

Message #479 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 30 Oct 2012 14:12:04 -0700
On Fri, 26 Oct 2012, Michael Biebl wrote:
> I've been discussing with jordi today about this issue.

Thanks for working on this.

> One idea that came up was to check wether wicd is in use (or for
> that matter ifupdown), and then show a debconf prompt explaining the
> situation, and letting the user chose if he wants to take over
> network management by NetworkManager. It would work similar to how
> we currently handle multiple installed display managers, like gdm3
> or kdm (btw, gdm3 is currently a hard depends of gnome-core). If the
> users choses no, we could disable the service via update-rc.d
> disable, so the invoke-rc.d later on in postinst would not start NM.

I believe some solution along this line which mitigates breakage
caused by the co-installation of wicd and NM would go a long way to
resolve the technical concerns of having gnome depend on NM.[0]

I'm concerned that such a solution won't be ready, tested, and
accepted in time for wheezy, however. But I can certainly see
proposing an option to have an explicit sunset on the CTTE's
requirement for gnome to only recommend NM once this work is done.[1]

> This would also help in situations where users install both wicd and
> network-manager by accident, which usually doesn't really work well
> since e.g. both spawn their own instance of wpa_supplicant.

Right. It would be awesome to have some kind of coordination between
NM and wicd (and anything else which potentially configures the
network in a conflicting way) so that they both present a similar
dialog box if the other is installed.


Don Armstrong

0: Indeed, I would have much rather seen this than what I proposed
previously in B, but as it requires substantial work on both your and
the wicd maintainers' parts, it's not something that the CTTE can
require.

1: Even though I personally don't think it's the right approach for
gnome to Depend on NM, it would no longer cause the technical problems
which make such a Dependency problematic enough for the CTTE to take
action.
-- 
A kiss was mysterious and powerful, fragile and invincible. Like any
spark, a kiss might fizzle into nothing or consume an entire forest.
[...] A kiss could change the entire world.
  -- Scott Westerfeld _The Killing of Worlds_ p336

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 08 Nov 2012 00:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 08 Nov 2012 00:18:03 GMT) Full text and rfc822 format available.

Message #484 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 7 Nov 2012 16:14:25 -0800
[Message part 1 (text/plain, inline)]
On Tue, 30 Oct 2012, Don Armstrong wrote:
> On Fri, 26 Oct 2012, Michael Biebl wrote:
> > One idea that came up was to check wether wicd is in use (or for
> > that matter ifupdown), and then show a debconf prompt explaining
> > the situation, and letting the user chose if he wants to take over
> > network management by NetworkManager. It would work similar to how
> > we currently handle multiple installed display managers, like gdm3
> > or kdm (btw, gdm3 is currently a hard depends of gnome-core). If
> > the users choses no, we could disable the service via update-rc.d
> > disable, so the invoke-rc.d later on in postinst would not start
> > NM.
> 
> I believe some solution along this line which mitigates breakage
> caused by the co-installation of wicd and NM would go a long way to
> resolve the technical concerns of having gnome depend on NM.[0]
> 
> I'm concerned that such a solution won't be ready, tested, and
> accepted in time for wheezy, however. But I can certainly see
> proposing an option to have an explicit sunset on the CTTE's
> requirement for gnome to only recommend NM once this work is done.[1]

I've gone ahead and drafted a B option which does this (attached).
I've also made an explicit request for a release note documenting that
people using gnome should (re)consider using NM. [That still requires
someone to "do the work", of course.]

I'd like to get some more input on this, and then call for a vote
sometime this week if at all possible.


Don Armstrong

-- 
LEADERSHIP -- A form of self-preservation exhibited by people with
autodestructive imaginations in order to ensure that when it comes to
the crunch it'll be someone else's bones which go crack and not their
own. 
 -- The HipCrime Vocab by Chad C. Mulligan 
    (John Brunner _Stand On Zanzibar_ p256-7)

http://www.donarmstrong.com              http://rzlab.ucr.edu
[don_draft.txt (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 08 Nov 2012 07:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 08 Nov 2012 07:39:03 GMT) Full text and rfc822 format available.

Message #489 received at 688772@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Michael Biebl <biebl@debian.org>, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 8 Nov 2012 08:35:06 +0100
Hi,

On Fri, 26 Oct 2012, Michael Biebl wrote:
> This would also help in situations where users install both wicd and
> network-manager by accident, which usually doesn't really work well
> since e.g. both spawn their own instance of wpa_supplicant.
> 
> A more detailed reply will follow soon.

I haven't seen this more detailed reply, or did I miss something?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 08 Nov 2012 21:48:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 08 Nov 2012 21:48:06 GMT) Full text and rfc822 format available.

Message #494 received at 688772@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 8 Nov 2012 22:46:17 +0100
* Don Armstrong (don@debian.org) [121108 01:18]:
> Therefore
> 
> A 4. We overrule the decision of the meta-gnome maintainers to add a
> A    dependency from gnome to network-manager-gnome; this dependency
> A    should be removed for the release of wheezy.
> 
> B 4. We overrule the decision of the meta-gnome maintainers to add a
> B    dependency from gnome to network-manager-gnome; this dependency
> B    should be removed for the release of wheezy. After the release of
> B    wheezy, if in the opinion of the NM maintainer the concerns
> B    raised in §4 of the CTTE decision #681834 have been addressed
> B    through technical means, the meta-gnome maintainers may freely
> B    adjust the dependencies as usual.

I'm thinking whether it might be helpful to put a reference to the
discussion here, like "e.g. by preventing nm to start as discussed in
#688772".

Also, with my tech ctte member hat on, I don't think I mind to have
the technical fixes applied pre-wheezy (however it might be useful to
have someone additionally to the nm maintainer in the loop to avoid
further misunderstandings, at least pre-wheezy). (I however fear it is
too late, so I'm not sure we should put something in about the
pre-wheezy.)


Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 08 Nov 2012 22:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 08 Nov 2012 22:09:03 GMT) Full text and rfc822 format available.

Message #499 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Thu, 8 Nov 2012 14:05:04 -0800
On Thu, 08 Nov 2012, Andreas Barth wrote:
> I'm thinking whether it might be helpful to put a reference to the
> discussion here, like "e.g. by preventing nm to start as discussed
> in #688772".
> 
> Also, with my tech ctte member hat on, I don't think I mind to have
> the technical fixes applied pre-wheezy (however it might be useful to
> have someone additionally to the nm maintainer in the loop to avoid
> further misunderstandings, at least pre-wheezy). (I however fear it is
> too late, so I'm not sure we should put something in about the
> pre-wheezy.)

That makes sense. I've adjusted it as follows, putting the RMs in the
position of gatekeeper. I would be ok with changing that to a
delegated member of the CTTE or someone else if the RMs didn't want to
be the final gatekeepers here. (git 07402)

B 4. We overrule the decision of the meta-gnome maintainers to add a
B    dependency from gnome to network-manager-gnome; this dependency
B    should be [-removed for the release of wheezy. After the release of
B    wheezy, if-] {+removed. If+} in the opinion of the NM maintainer {+(and
B    before the release of wheezy the Release Managers)+} the concerns
B    raised in §4 of the CTTE decision #681834 have been addressed
B    through technical [-means,-] {+means (e.g. by preventing the starting of NM as
B    discussed in #688772),+} the meta-gnome maintainers may freely
B    adjust the dependencies as usual.


Don Armstrong

-- 
Taxes are not levied for the benefit of the taxed.
 -- Robert Heinlein _Time Enough For Love_ p250

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 09 Nov 2012 09:24:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Nov 2012 09:24:06 GMT) Full text and rfc822 format available.

Message #504 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 9 Nov 2012 09:22:10 +0000
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> That makes sense. I've adjusted it as follows, putting the RMs in the
> position of gatekeeper. I would be ok with changing that to a
> delegated member of the CTTE or someone else if the RMs didn't want to
> be the final gatekeepers here. (git 07402)

We should certainly ask the RMs first!  If I were them I wouldn't want
to be, for example, accused of being part of a crusade.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 09 Nov 2012 09:51:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Nov 2012 09:51:08 GMT) Full text and rfc822 format available.

Message #509 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 9 Nov 2012 09:46:31 +0000
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> B 4. We overrule the decision of the meta-gnome maintainers to add a
> B    dependency from gnome to network-manager-gnome; this dependency
> B    should be [-removed for the release of wheezy. After the release of
> B    wheezy, if-] {+removed. If+} in the opinion of the NM maintainer {+(and
> B    before the release of wheezy the Release Managers)+} the concerns
> B    raised in §4 of the CTTE decision #681834 have been addressed
> B    through technical [-means,-] {+means (e.g. by preventing the starting of NM as
> B    discussed in #688772),+} the meta-gnome maintainers may freely
> B    adjust the dependencies as usual.

Obviously we should have this on the ballot if other TC members want
it.

But I am opposed to it because:


Firstly, and most importantly:

There is no technical reason to prefer a situation where the user has
n-m installed but disabled to one where they don't have it installed.

There _are_ technical reasons why (on systems where n-m's operation
is not desired) not installing it is better.

This for me is the critical point.  Can _anyone_ provide a coherent
and fact-based explanation for why this is a good idea ?  (And I mean
why this is a _technically_ good idea.  "It might help placate the
maintainers" is not a technical reason.)

The biggest technical downside is that this approach doesn't solve the
upgrade problem without a good deal of complicated machinery to try to
determine whether the system should pretend that n-m isn't installed
(or annoying prompts, or something).


Secondly, there is a process/approval problem here for the post-wheezy
case.  I think this resolution text effectively neuters itself after
wheezy since AIUI the n-m maintainers naturally think that all the
concerns are _already_ satisfactorily addressed.  If the n-m
maintainers felt that the concerns of n-m sceptics _weren't_
satisfactorily addressed _already_ they would surely not be pushing
n-m so hard right now.

So this is likely to result in the n-m maintainers engaging in some
kind of make-work (which both they and n-m sceptics consider futile)
to try to comply with a ruling which they don't agree with but which
delegates part of the decision back to them.  And then, when the
make-work turns out not to satisfy, further escalation and bad
feeling.

If we are overruling the maintainer we should not ask them to be the
judge of whether their fix is sufficient.  We should either make the
requirements objective, or nominate someone else to make the decision.

Alternatively, if it's intended that after wheezy the maintainers will
do whatever they feel appropriate then the resolution should
explicitly limit the scope of the overruling to wheezy and have a new
advisory paragraph for the post-wheezy case.  (I mention this for
completeness; I wouldn't agree with that approach.)


Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 09 Nov 2012 11:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Nov 2012 11:30:03 GMT) Full text and rfc822 format available.

Message #514 received at 688772@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 688772@bugs.debian.org
Cc: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 9 Nov 2012 12:27:23 +0100
* Ian Jackson (ijackson@chiark.greenend.org.uk) [121109 10:51]:
> There is no technical reason to prefer a situation where the user has
> n-m installed but disabled to one where they don't have it installed.
> 
> There _are_ technical reasons why (on systems where n-m's operation
> is not desired) not installing it is better.

While I agree with you on the technical part, however, there is a
difference: We are not asked "what is the technical best solution",
but "please overrule the decision of the gnome maintainers". If it
would be the first question, I'd tend to agree with not setting a
depends. However, it isn't. And I don't think the situation with "nm
isn't start" is still so bad that it warrants an overruling of the
maintainers. (With my normal DD hat on, I think I'd prefer to not have
n-m installed via gnome, but well - that's not the question at hand.)


> The biggest technical downside is that this approach doesn't solve the
> upgrade problem without a good deal of complicated machinery to try to
> determine whether the system should pretend that n-m isn't installed
> (or annoying prompts, or something).

That has to be fixed, yes. It might be helpful to put a few more
things into the resolution to give examples what needs to be fixed.


> Secondly, there is a process/approval problem here for the post-wheezy
> case.

Same here - I'm happy for whatever useful process to be put into it. I
however think once a dist-upgrade installing n-m could be done without
it getting active without jumping through loops (or: disturbing
otherwise setup network interfaces) we shouldn't force the maintainers
to not set a depends.



Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 09 Nov 2012 18:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Nov 2012 18:12:03 GMT) Full text and rfc822 format available.

Message #519 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 9 Nov 2012 10:09:10 -0800
On Fri, 09 Nov 2012, Ian Jackson wrote:
> This for me is the critical point. Can _anyone_ provide a coherent
> and fact-based explanation for why this is a good idea ?

NM is apparently required for various parts of gnome to figure out
whether it is online or offline. It's also necessary for the network
configuration components to work properly inside of gnome.

There may be additional technical problems that not having NM causes
gnome, but they haven't been adequately communicated. [However,
Michael Biebl is planning on communicating them in an e-mail to us
shortly.]
 
> The biggest technical downside is that this approach doesn't solve
> the upgrade problem without a good deal of complicated machinery to
> try to determine whether the system should pretend that n-m isn't
> installed (or annoying prompts, or something).

This machinery should be in place even without the upgrade process
just to avoid breakage when multiple elements of the NM, wicd, and
conntrack set are installed.
 
> Secondly, there is a process/approval problem here for the
> post-wheezy case. I think this resolution text effectively neuters
> itself after wheezy since AIUI the n-m maintainers naturally think
> that all the concerns are _already_ satisfactorily addressed.

This is only the case if we are convinced the NM maintainer(s) are
acting in bad faith. While that's certainly a possibility, we
shouldn't assume it. Perhaps specifically spelling out what the
technical requirements are would be sufficient to mitigate the
potential for the appearance of bad faith. Such as:

1. NM must not break an existing working networking configuration.

2. In the event that a networking configuration manger which is unable
to cooperate with NM is previously installed, NM should default to
disabling itself. [With possibilities for debconf prompting at low
priority to change it, I suspect.]

> Alternatively, if it's intended that after wheezy the maintainers
> will do whatever they feel appropriate then the resolution should
> explicitly limit the scope of the overruling to wheezy and have a
> new advisory paragraph for the post-wheezy case. (I mention this for
> completeness; I wouldn't agree with that approach.)

I don't agree with this approach either, because the technical
concerns are the entire reason why we're here.


Don Armstrong

-- 
This can't be happening to me. I've got tenure.
 -- James Hynes _Publish and Perish_

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 09 Nov 2012 18:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Nov 2012 18:45:03 GMT) Full text and rfc822 format available.

Message #524 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 9 Nov 2012 18:41:08 +0000
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Fri, 09 Nov 2012, Ian Jackson wrote:
> > This for me is the critical point. Can _anyone_ provide a coherent
> > and fact-based explanation for why this is a good idea ?
> 
> NM is apparently required for various parts of gnome to figure out
> whether it is online or offline. It's also necessary for the network
> configuration components to work properly inside of gnome.

My understanding is that if you have n-m not installed, you get the
same or better experience than if you have n-m installed but not
running.

Of course if you are not using n-m to manage your network then the
network configuration components inside gnome are not going to work
properly.  That's part of the price you pay for not using n-m.  But
this is true whether n-m is not installed, or installed but disabled.

I'm sure somene will correct me if I'm wrong.


> > Secondly, there is a process/approval problem here for the
> > post-wheezy case. I think this resolution text effectively neuters
> > itself after wheezy since AIUI the n-m maintainers naturally think
> > that all the concerns are _already_ satisfactorily addressed.
> 
> This is only the case if we are convinced the NM maintainer(s) are
> acting in bad faith. While that's certainly a possibility, we
> shouldn't assume it.

I don't think that my complaint here involves assuming bad faith on
the part of the gnome maintainers.  It simply doesn't make any sense
to ask them to do further work to resolve these problems to their
satisfaction, when in their view insofar as there are problems they
are already satisfactorily resolved.

If I were in the position of the gnome maintainers here (ie if I were
the one being overruled) I would be making exactly the same point.

> Perhaps specifically spelling out what the
> technical requirements are would be sufficient to mitigate the
> potential for the appearance of bad faith. Such as:

I want to reiterate that I don't think this problem involves supposing
any bad faith.  It's that since we disagree with the maintainers about
the requirements and are overruling them, asking them to set the
requirements does not make sense and is inviting misunderstanding.

> 1. NM must not break an existing working networking configuration.

Is this possible ?  I mean, I worry that interpreted broadly ("_any_
existing ...") this would simply mean that n-m should never do
anything.

Perhaps a better approach would be this, post-wheezy:

   While n-m remains a Depends of gnome or gnome-core, any bug report
   from a user that installing n-m broke their system's networking is
   to be treated by the gnome and network-manager maintainers as a
   valid, release-critical, bug.

We should ask the n-m maintainer to comment on this proposal.  If they
think it's unworkable then that amounts to a statement that it will
not be possible to reliably identify, and fix, all such problems.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 09 Nov 2012 19:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Nov 2012 19:09:03 GMT) Full text and rfc822 format available.

Message #529 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Cc: Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 9 Nov 2012 11:07:08 -0800
On Fri, 09 Nov 2012, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > This is only the case if we are convinced the NM maintainer(s) are
> > acting in bad faith. While that's certainly a possibility, we
> > shouldn't assume it.
>
> If I were in the position of the gnome maintainers here (ie if I
> were the one being overruled) I would be making exactly the same
> point.

The NM maintainer(s) aren't the same as the set of gnome maintainers,
though. [Even though there is some overlap and certainly communication
between them.]

> > 1. NM must not break an existing working networking configuration.
> 
> Is this possible ? I mean, I worry that interpreted broadly ("_any_
> existing ...") this would simply mean that n-m should never do
> anything.
>
> Perhaps a better approach would be this, post-wheezy:
> 
>    While n-m remains a Depends of gnome or gnome-core, any bug report
>    from a user that installing n-m broke their system's networking is
>    to be treated by the gnome and network-manager maintainers as a
>    valid, release-critical, bug.
> 
> We should ask the n-m maintainer to comment on this proposal. If
> they think it's unworkable then that amounts to a statement that it
> will not be possible to reliably identify, and fix, all such
> problems.

Ok. I believe having Michael Biebl and/or the rest of the NM team
weigh in on this issue will be useful.


Don Armstrong

-- 
"For those who understand, no explanation is necessary.
 For those who do not, none is possible."

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 13 Nov 2012 11:06:12 GMT) Full text and rfc822 format available.

Message #532 received at 688772@bugs.debian.org (full text, mbox):

From: Jordi Mallach <jordi@debian.org>
To: debian-ctte@lists.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 13 Nov 2012 10:19:18 +0100
[Message part 1 (text/plain, inline)]
Hi,

The Debian GNOME team is well aware of the discussion regarding #688772, which
unfortunately went down an unconstructive path. As such we thought it best
to step back for a little bit to try and formulate our position more clearly
and see if we could find a constructive way to get out of this mess.
Luckily the last few mails on the thread by Don Armstrong and Michael Biebl
already showed there was some light at the end of the tunnel :)

First of all, we want to make clear that the position Joss has been defending
on this exhausting thread is shared by most, if not all, of the Debian GNOME
team members. In other words, we all consider NM an important and integral part
of the desktop system we're delivering, and its absence does degrade its
operation in such a way we find inacceptable.

It is worth to point out that GNOME 3 as we will get in wheezy is a big
departure from the GNOME 2 as delivered in lenny. Among other things GNOME now
strives for a tightly integrated desktop, with NM being a core part of this
desktop. In the opinion of the GNOME team the intended GNOME experience can
only be delivered when all these tightly integrated parts are used together.

Network manager is  not an arbitrary requirement, even if GNOME Shell can
currently run without it. NetworkManager allows GNOME to:
- access all present and commonly used networking technologies (VPN, Wireless,
  3G) via an integrated, very prominent icon in the main desktop bar.
- networking needs have changed over the past years and has become much more
  dynamic and diverse. Connecting to the internet via wireless, 3G or VPN
  should be painless and easy. It should work out of the box and require a
  minimum of fuss.
- only NetworkManager currently offers this kind of features, ifupdown is too
  static/cumbersome to setup, wicd is too limited in functionality.
- GNOME upstream developers embraced NetworkManager as an external dependency
  and seamlessly integrated them into various parts of the desktop.

better integration / software being network-aware
=================================================
- on/offline detection: GNOME relies on NetworkManager's D-Bus messages to
  establish if the system has a working network connection or not, and how to
  behave in either case.  Applications like Evolution or Empathy will only try
  to fetch mail if NM says there's an appropriate network link, avoiding errors
  like "Could not connect to IMAP server". Epiphany will enable offline mode
  automatically, etc.
- PackageKit will avoid costly downloads when you're on 3G setting up new
  connections is easy
- integration into gnome-control-center
- setting up a new wireless connection requires a single click via prominent
  integration into GNOME Shell

upgrade problem
===============
- NetworkManager was first introduced in lenny, the first release installing
  recommends by default.
- network-manager-gnome was added a Recommends to the "gnome" meta-package in
  lenny.
- misuse of Recommends was a widespread problem in lenny, so quite a few users
  disabled Recommends back then.
- NetworkManager 0.6 in lenny was very limited, e.g. only supported DHCP. It is
  not comparable with the version we ship in wheezy.

NetworkManager and static interface configurations
==================================================

Some of the concerns raised in the discussion revolve about the
possibility of NetworkManager starting in the middle of an upgrade and
taking over a statically configured interface in /etc/network/interfaces.
We don't think there's much discussion about that: if that happens, it's a
critical RC bug that needs to be fixed. The same already applies to
regressions network drivers in the kernel, libc6 or other basic core
components which could break a remote Debian dist-upgrade.

multiple connection managers problem
====================================

One of the real issues when NM is a Depend of the meta-packages is that it
violated the principle of "do no harm" when being installed on a system
which already has a connection manager (such as wicd or less commonly
connman). While this is not a problem specific to NM (installing wicd on
an NM system causes the same problem), the problem is of course triggered
by the Depend in the gnome meta package.

Solving this issue properly will not only make the biggest issues seen with
gnome depending on NM go away, but will also improve Debian as a whole, which
is of course always worthwhile.

The best solution we can currently propose for this issue is to add some
maintainer script logic to present a debconf prompt (similar to how we
currently manage multiple display managers like gdm and kdm which can be
installed at the same time). To avoid unnecessary debconf prompts, the
debconf prompt would only be shown if such a "conflict" situation is
detected.

Michael has done a proof of concept implementation [1] which is one step
in that direction, by simply having NM provide a prompt when it detects
that the wicd binary is installed. A more full implemenation would of
course require modifications to the wicd package (and connman) as well.

If the details of the technical implementation of this solution aren't
considered out of scope for this bug report and the CTTE, we are happy to
discuss a more detailed plan.

On behalf of the Debian GNOME team,
Jordi Mallach
Sjoerd Simons
Michael Biebl

[1] http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=shortlog;h=refs/heads/wip/debconf
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 13 Nov 2012 11:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 13 Nov 2012 11:18:03 GMT) Full text and rfc822 format available.

Message #537 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Jordi Mallach <jordi@debian.org>
Cc: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 13 Nov 2012 11:14:59 +0000
Jordi Mallach writes ("Re: Bug#688772: gnome Depends network-manager-gnome"):
> The Debian GNOME team is well aware of the discussion regarding
> #688772,

Thanks for your mail.  (I have bounced it to the bug report - all
discussions on TC issues should be sent to the bug, rather than
directly to the TC list.)

> multiple connection managers problem
> ====================================
> 
> One of the real issues when NM is a Depend of the meta-packages is that it
> violated the principle of "do no harm" when being installed on a system
> which already has a connection manager (such as wicd or less commonly
> connman). While this is not a problem specific to NM (installing wicd on
> an NM system causes the same problem), the problem is of course triggered
> by the Depend in the gnome meta package.

Right.  I think this is the key problem.

> Solving this issue properly will not only make the biggest issues seen with
> gnome depending on NM go away, but will also improve Debian as a whole, which
> is of course always worthwhile.
> 
> The best solution we can currently propose for this issue is to add some
> maintainer script logic to present a debconf prompt (similar to how we
> currently manage multiple display managers like gdm and kdm which can be
> installed at the same time). To avoid unnecessary debconf prompts, the
> debconf prompt would only be shown if such a "conflict" situation is
> detected.

I believe the difference between Depends and Recommends in gnome is
relevant only for existing systems which do not currently have n-m
installed.  Is that your understanding too ?  Such systems presumably
already have some other mechanism for configuring the network.

On such a system installing n-m and then detecting the conflict and
disabling n-m has some obvious technical disadvantages compared to
simply leaving n-m uninstalled: there is a need for additional
scripting, which may have bugs, and perhaps additional debconf
prompts.

Presumably you believe there are technical advantages of installing
n-m but disabling it, compared to simply leaving n-m uninstalled.  But
I'm afraid I still don't understand what they are.  Can you please
explain them to me ?

> Michael has done a proof of concept implementation [1] which is one step
> in that direction, by simply having NM provide a prompt when it detects
> that the wicd binary is installed. A more full implemenation would of
> course require modifications to the wicd package (and connman) as well.

I'm assuming that you would intended this for jessie, not wheezy ?

Thanks,
Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 13 Nov 2012 18:45:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 13 Nov 2012 18:45:08 GMT) Full text and rfc822 format available.

Message #542 received at 688772@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: Jordi Mallach <jordi@debian.org>
Cc: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 13 Nov 2012 19:40:11 +0100
Hi,

* Jordi Mallach (jordi@debian.org) [121113 10:29]:
> [...]

First of all, thanks for your mail. I think it shows a good direction
to move on (though I'm not convinced that not running n-m is more
appropriate than not installing it, but well, YMMV.)


> NetworkManager and static interface configurations
> ==================================================
> 
> Some of the concerns raised in the discussion revolve about the
> possibility of NetworkManager starting in the middle of an upgrade and
> taking over a statically configured interface in /etc/network/interfaces.
> We don't think there's much discussion about that: if that happens, it's a
> critical RC bug that needs to be fixed. The same already applies to
> regressions network drivers in the kernel, libc6 or other basic core
> components which could break a remote Debian dist-upgrade.

Good. I think I can remember that happening times ago, but if you are
convinced it doesn't happen anymore (and we all agree it would be RC),
that's fine then. (JFTR, many if not all of the features about n-m
being integrated into gnome wouldn't be relevant for remote systems.)



> If the details of the technical implementation of this solution aren't
> considered out of scope for this bug report and the CTTE, we are happy to
> discuss a more detailed plan.

I'm interessted in the details insofar as we need to be reasonably
sure the intended solution works. If there is appropriate buy-in from
the relevant maintainers, that would be enough.

Now for wheezy, what do you propose short-term? Otherwise, we might be
in a position where the only options are to demote the depends to
recommends, or to enforce the current n-m configuration - both choices
have consequences I won't like.


Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 13 Nov 2012 19:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Noel David Torres Taño <envite@rolamasao.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 13 Nov 2012 19:36:03 GMT) Full text and rfc822 format available.

Message #547 received at 688772@bugs.debian.org (full text, mbox):

From: Noel David Torres Taño <envite@rolamasao.org>
To: debian-ctte@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Tue, 13 Nov 2012 19:23:51 +0000
[Message part 1 (text/plain, inline)]
Hi all

I do not know if you remember I am one of the interested parties on this, 
since I raised #681834.

I'm very happy of reading such a comprehensive and rational statament from the 
Gnome maintainers. I really appreciate it.

Please note that I am a (part time) Gnome user and want to continue being so.

My main concern when raising #681834 is that NM breaks my desktop system, not  
by breaking its network, but but rendering some of its applications unusable. 
This seems not to have been addressed yet.

The example I put once and again is that when I use pidgin, if NM is installed 
(and since my network is configured statically in /e/n/i) pidgin thinks I have 
no working network connection (which I have) and refuses to connect, while 
with NM not installed pidgin works properly.

This is the reason for which I consciously decided to deinstall NM knowing 
that it breaks a Recommends. It was an explicit decision by me (the user), and 
having it overruled by the Debian Gnome team caused me some problems (yes, I 
do not track stable but unstable).

I'm happy with NM being installed by default (I want it on my next laptop, 
which will use Debian Gnome), but I also want my decision to deinstall it 
being respected.

More to-the-point comments below.

On Martes, 13 de noviembre de 2012 09:19:18 Jordi Mallach wrote:
> Hi,
> 
> The Debian GNOME team is well aware of the discussion regarding #688772,
> which unfortunately went down an unconstructive path. As such we thought
> it best to step back for a little bit to try and formulate our position
> more clearly and see if we could find a constructive way to get out of
> this mess. Luckily the last few mails on the thread by Don Armstrong and
> Michael Biebl already showed there was some light at the end of the tunnel
> :)
> 
> First of all, we want to make clear that the position Joss has been
> defending on this exhausting thread is shared by most, if not all, of the
> Debian GNOME team members. In other words, we all consider NM an important
> and integral part of the desktop system we're delivering, and its absence
> does degrade its operation in such a way we find inacceptable.

I am a Gnome user, and I find Gnome without NM beyond acceptable: it is 
perfectly usable. I'm using it to write this.
> 
> It is worth to point out that GNOME 3 as we will get in wheezy is a big
> departure from the GNOME 2 as delivered in lenny. Among other things GNOME
> now strives for a tightly integrated desktop, with NM being a core part of
> this desktop. In the opinion of the GNOME team the intended GNOME
> experience can only be delivered when all these tightly integrated parts
> are used together.

It should be up to the user to decide up to which completion point he desires 
an experience.
> 
> Network manager is  not an arbitrary requirement, even if GNOME Shell can
> currently run without it. NetworkManager allows GNOME to:
> - access all present and commonly used networking technologies (VPN,
> Wireless, 3G) via an integrated, very prominent icon in the main desktop
> bar. - networking needs have changed over the past years and has become
> much more dynamic and diverse. Connecting to the internet via wireless, 3G
> or VPN should be painless and easy. It should work out of the box and
> require a minimum of fuss.
> - only NetworkManager currently offers this kind of features, ifupdown is
> too static/cumbersome to setup, wicd is too limited in functionality. -
> GNOME upstream developers embraced NetworkManager as an external
> dependency and seamlessly integrated them into various parts of the
> desktop.

Some users desire precisaly this: static (thus, trustable) network 
configuration.
> 
> better integration / software being network-aware
> =================================================
> - on/offline detection: GNOME relies on NetworkManager's D-Bus messages to
>   establish if the system has a working network connection or not, and how
> to behave in either case.  Applications like Evolution or Empathy will
> only try to fetch mail if NM says there's an appropriate network link,
> avoiding errors like "Could not connect to IMAP server". Epiphany will
> enable offline mode automatically, etc.
> - PackageKit will avoid costly downloads when you're on 3G setting up new
>   connections is easy
> - integration into gnome-control-center
> - setting up a new wireless connection requires a single click via
> prominent integration into GNOME Shell

Precisely the point (within pidgin) that led me to remove NM.
> 
> upgrade problem
> ===============
> - NetworkManager was first introduced in lenny, the first release
> installing recommends by default.
> - network-manager-gnome was added a Recommends to the "gnome" meta-package
> in lenny.
> - misuse of Recommends was a widespread problem in lenny, so quite a few
> users disabled Recommends back then.
> - NetworkManager 0.6 in lenny was very limited, e.g. only supported DHCP.
> It is not comparable with the version we ship in wheezy.

Usage of Recommends for metapackages has been addressed in separated CTTE 
issue #681783
> 
> NetworkManager and static interface configurations
> ==================================================
> 
> Some of the concerns raised in the discussion revolve about the
> possibility of NetworkManager starting in the middle of an upgrade and
> taking over a statically configured interface in /etc/network/interfaces.
> We don't think there's much discussion about that: if that happens, it's a
> critical RC bug that needs to be fixed. The same already applies to
> regressions network drivers in the kernel, libc6 or other basic core
> components which could break a remote Debian dist-upgrade.

I fully agree. Also, I do not think this is an issue in current NM, unless NM 
configures an inactive connection and thus renders the computer either
a) reachable via a non-intended network, previously down
b) change its routing table

Please note that I do not know if NM modifies the default gateway if it finds 
and configures a previously unconfigured network card, but a) is a problem 
anyway.
> 
> multiple connection managers problem
> ====================================
> 
> One of the real issues when NM is a Depend of the meta-packages is that it
> violated the principle of "do no harm" when being installed on a system
> which already has a connection manager (such as wicd or less commonly
> connman). While this is not a problem specific to NM (installing wicd on
> an NM system causes the same problem), the problem is of course triggered
> by the Depend in the gnome meta package.
> 
> Solving this issue properly will not only make the biggest issues seen with
> gnome depending on NM go away, but will also improve Debian as a whole,
> which is of course always worthwhile.

I fully agree
> 
> The best solution we can currently propose for this issue is to add some
> maintainer script logic to present a debconf prompt (similar to how we
> currently manage multiple display managers like gdm and kdm which can be
> installed at the same time). To avoid unnecessary debconf prompts, the
> debconf prompt would only be shown if such a "conflict" situation is
> detected.

Correct. But this leaves unadressed the issue of explicit user decision to 
have NM uninstalled even knowing it is a Recommends.
> 
> Michael has done a proof of concept implementation [1] which is one step
> in that direction, by simply having NM provide a prompt when it detects
> that the wicd binary is installed. A more full implemenation would of
> course require modifications to the wicd package (and connman) as well.

Please think that there are users that want to stick with ifupdown/ifconfig 
only.
> 
> If the details of the technical implementation of this solution aren't
> considered out of scope for this bug report and the CTTE, we are happy to
> discuss a more detailed plan.
> 
> On behalf of the Debian GNOME team,
> Jordi Mallach
> Sjoerd Simons
> Michael Biebl
> 
> [1]
> http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=short
> log;h=refs/heads/wip/debconf

Again, I want to thank you three for this coherent text and your effort to 
settle this issue.

Regards

Noel Torres
er Envite

-------------------------
A: Because it breaks the logical flow of discussion.
Q: Why is top posting bad?
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 27 Nov 2012 00:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 27 Nov 2012 00:45:03 GMT) Full text and rfc822 format available.

Message #552 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Mon, 26 Nov 2012 16:42:45 -0800
I've readjusted option B yet again, by adding an additional paragraph
which takes into account Ian's and Tollef's concerns. (git 6e42994)

B 4. We overrule the decision of the meta-gnome maintainers to add a
B    dependency from gnome to network-manager-gnome; this dependency
B    should be removed. If in the opinion of the NM maintainer (and
B    before the release of wheezy the Release Managers) the concerns
B    raised in §4 of the CTTE decision #681834 have been addressed
B    through technical means (e.g. by preventing the starting of NM as
B    discussed in #688772), the meta-gnome maintainers may freely
B    adjust the dependencies as usual.
B    
B    Specifically, valid bugs where existing valid network
B    configurations are broken by the automatic, required installation
B    on system upgrade of packages not previously installed which
B    perform network configuration on should have severity serious.


Don Armstrong

-- 
"Do you need [...] [t]ools? Stuff?"
"Our opponent is an alien starship packed with atomic bombs. [...] We
have a protractor."
 -- Neal Stephenson _Anathem_ p320

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sun, 02 Dec 2012 19:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 02 Dec 2012 19:42:03 GMT) Full text and rfc822 format available.

Message #557 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Subject: Current options for resolving 688772 [Re: Bug#688772: gnome Depends network-manager-gnome]
Date: Sun, 2 Dec 2012 11:40:17 -0800
This is the current text of the options for #688772. I'd like to vote
on this before the 9th if at all possible. If anyone has any comments,
changes, or would like to propose different options, please do so now.

=== START ===

1. The TC notes the decision of the meta-gnome maintainers to
   implement the TC decision in #681834 by:
    (a) softening the dependency in the gnome-core metapackage
        from Depends to Recommends, as required
    (b) adding a new dependency in the gnome metapackage,
        as a Depends.  (In squeeze, this is where the dependency
        was, but it was a Recommends.)

2. Our intent, as stated in the rationale section of our previous
   decision (#681834, paras 3 and 5), is that squeeze users who have
   gnome installed but not network-manager do not find that
   network-manager becomes installed when they upgrade to wheezy.

3. A Recommends from gnome to network-manager-gnome would serve no
   purpose in wheezy as gnome Depends on gnome-core which already
   Recommends network-manager-gnome.

Therefore

A 4. We overrule the decision of the meta-gnome maintainers to add a
A    dependency from gnome to network-manager-gnome; this dependency
A    should be removed for the release of wheezy.

B 4. We overrule the decision of the meta-gnome maintainers to add a
B    dependency from gnome to network-manager-gnome; this dependency
B    should be removed. If in the opinion of the NM maintainer (and
B    before the release of wheezy the Release Managers) the concerns
B    raised in §4 of the CTTE decision #681834 have been addressed
B    through technical means (e.g. by preventing the starting of NM as
B    discussed in #688772), the meta-gnome maintainers may freely
B    adjust the dependencies as usual.
B    
B    Specifically, valid bugs where existing valid network
B    configurations are broken by the automatic, required installation
B    on system upgrade of packages not previously installed which
B    perform network configuration on should have severity serious.

5. We request that the Release Team unblock update(s) to meta-gnome so
   that our decisions may be implemented in wheezy.

6. We request that a release note is created explaining that gnome
   users who do not currently have NM installed consider installing
   it.

=== END ===


Don Armstrong

-- 
Every gun that is made, every warship launched, every rocket fired
signifies [...] a theft from those who hunger and are not fed, those
who are cold and are not clothed. This world in arms is not spending
money alone. It is spending the sweat of its laborers, the genius of
its scientists, the hopes of its children. [...] This is not a way of
life at all in any true sense. Under the cloud of threatening war, it
is humanity hanging from a cross of iron. [...] [I]s there no other
way the world may live?
 -- President Dwight D. Eisenhower, April 16, 1953

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sun, 02 Dec 2012 20:21:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 02 Dec 2012 20:21:08 GMT) Full text and rfc822 format available.

Message #562 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: Current options for resolving 688772 [Re: Bug#688772: gnome Depends network-manager-gnome]
Date: Sun, 02 Dec 2012 12:16:17 -0800
Don Armstrong <don@debian.org> writes:

> This is the current text of the options for #688772. I'd like to vote on
> this before the 9th if at all possible. If anyone has any comments,
> changes, or would like to propose different options, please do so now.

After considering this and following the discussion, I'm not willing to
vote for either A or B, and would end up voting further discussion.  I'd
like to add an option C, along the lines of:

4. After further discussion, we understand that reintroducing
   network-manager on upgrade was part of the intent, due to both
   substantial improvements in network-manager and tighter integration of
   network-manager with the GNOME desktop in wheezy.  Since the gnome
   metapackage has historically been more aggressive at pulling in
   additional packages, we believe the move of the dependency from
   gnome-core to gnome is an acceptable compromise that was not raised
   during the previous discussion.  Users who want to remove
   network-manager can still use the gnome-core metapackage to get the
   basic GNOME desktop functionality.

   We recommend that this upgrade behavior for users of the gnome
   metapackage be documented in the release notes.

This is not to say that I'm opposed to fixing network-manager to deal with
some of the other upgrade problems.  I'm all in favor!  But I'm not
comfortable with making inclusion of the dependency conditional on solving
the broader problem in the way described there.  If it happens in time for
the release, I'm all in favor, and it makes it an even better compromise,
but I think it would be acceptable to release without that fix and
document the issue in the release notes.

In other words, my *preferred* option is B with the fix to the
network-manager package, but B as phrased has consequences for not getting
that fix done in time that I'm not comfortable with.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sun, 02 Dec 2012 21:45:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 02 Dec 2012 21:45:07 GMT) Full text and rfc822 format available.

Message #567 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: Current options for resolving 688772 [Re: Bug#688772: gnome Depends network-manager-gnome]
Date: Sun, 2 Dec 2012 13:42:47 -0800
On Sun, 02 Dec 2012, Russ Allbery wrote:
> Don Armstrong <don@debian.org> writes:
> > This is the current text of the options for #688772. I'd like to vote on
> > this before the 9th if at all possible. If anyone has any comments,
> > changes, or would like to propose different options, please do so now.
> 
> After considering this and following the discussion, I'm not willing
> to vote for either A or B, and would end up voting further
> discussion. I'd like to add an option C, along the lines of:

[...]

Ok, so this option C would involve not overriding the maintainer,
coupled with requesting documentation in the release notes, and would
also supplant 5 and 6 in the A and B versions.
 
I've gone ahead and updated the current don_draft.txt with this text
as written with the other options.

> In other words, my *preferred* option is B with the fix to the
> network-manager package, but B as phrased has consequences for not
> getting that fix done in time that I'm not comfortable with.

I believe that the fixes outlined in option B are going to get
implemented regardless of how the CTTE rules; the primary goal of B is
to make the gnome dependency on NM conditional on those fixes being
implemented. [And if that's not clear from the text of B, that's
something that I would like to resolve.]


Don Armstrong

-- 
He was wrong. Nature abhors dimensional abnormalities, and seals them
neatly away so that they don't upset people. Nature, in fact, abhors a
lot of things, including vacuums, ships called the Marie Celeste, and
the chuck keys for electric drills.
 -- Terry Pratchet _Pyramids_ p166

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sun, 02 Dec 2012 21:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 02 Dec 2012 21:57:03 GMT) Full text and rfc822 format available.

Message #572 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: Current options for resolving 688772 [Re: Bug#688772: gnome Depends network-manager-gnome]
Date: Sun, 02 Dec 2012 13:54:08 -0800
Don Armstrong <don@debian.org> writes:

> Ok, so this option C would involve not overriding the maintainer,
> coupled with requesting documentation in the release notes, and would
> also supplant 5 and 6 in the A and B versions.

Ah, yes, indeed, it would.

> I've gone ahead and updated the current don_draft.txt with this text
> as written with the other options.

Thanks!

> I believe that the fixes outlined in option B are going to get
> implemented regardless of how the CTTE rules; the primary goal of B is
> to make the gnome dependency on NM conditional on those fixes being
> implemented. [And if that's not clear from the text of B, that's
> something that I would like to resolve.]

If that does happen, of course, I'm happy to support B.  I don't know how
much progress has already been made on that.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 13 Dec 2012 20:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 13 Dec 2012 20:09:03 GMT) Full text and rfc822 format available.

Message #577 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Subject: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]
Date: Thu, 13 Dec 2012 12:06:57 -0800
I'd like to call for votes to resolve #688772 with the following
options, with F as further discussion. Both options A and B require a
3:1 majority, as they overrule the gnome maintainers; Option C does
not.

=== START ===

1. The TC notes the decision of the meta-gnome maintainers to
   implement the TC decision in #681834 by:
    (a) softening the dependency in the gnome-core metapackage
        from Depends to Recommends, as required
    (b) adding a new dependency in the gnome metapackage,
        as a Depends.  (In squeeze, this is where the dependency
        was, but it was a Recommends.)

2. Our intent, as stated in the rationale section of our previous
   decision (#681834, paras 3 and 5), is that squeeze users who have
   gnome installed but not network-manager do not find that
   network-manager becomes installed when they upgrade to wheezy.

3. A Recommends from gnome to network-manager-gnome would serve no
   purpose in wheezy as gnome Depends on gnome-core which already
   Recommends network-manager-gnome.

Therefore

A 4. We overrule the decision of the meta-gnome maintainers to add a
A    dependency from gnome to network-manager-gnome; this dependency
A    should be removed for the release of wheezy.
A 
A 5. We request that the Release Team unblock update(s) to meta-gnome so
A    that our decisions may be implemented in wheezy.
A 
A 6. We request that a release note is created explaining that gnome
A    users who do not currently have NM installed consider installing
A    it.


B 4. We overrule the decision of the meta-gnome maintainers to add a
B    dependency from gnome to network-manager-gnome; this dependency
B    should be removed. If in the opinion of the NM maintainer (and
B    before the release of wheezy the Chair of the Technical Committee
B    or an individual delegated by the Chair in consultation with the
B    Release Team) the concerns raised in §4 of the CTTE decision
B    #681834 have been addressed through technical means (e.g. by
B    preventing the starting of NM as discussed in #688772), the
B    meta-gnome maintainers may freely adjust the dependencies as
B    usual.
B    
B    Specifically, valid bugs where existing valid network
B    configurations are broken by the automatic, required installation
B    on system upgrade of packages not previously installed which
B    perform network configuration on should have severity serious.
B
B 5. We request that the Release Team unblock update(s) to meta-gnome so
B    that our decisions may be implemented in wheezy.
B 
B 6. We request that a release note is created explaining that gnome
B    users who do not currently have NM installed consider installing
B    it.

C 4. After further discussion, we understand that reintroducing
C    network-manager on upgrade was part of the intent, due to both
C    substantial improvements in network-manager and tighter integration of
C    network-manager with the GNOME desktop in wheezy.  Since the gnome
C    metapackage has historically been more aggressive at pulling in
C    additional packages, we believe the move of the dependency from
C    gnome-core to gnome is an acceptable compromise that was not raised
C    during the previous discussion.  Users who want to remove
C    network-manager can still use the gnome-core metapackage to get the
C    basic GNOME desktop functionality.
C 
C    We recommend that this upgrade behavior for users of the gnome
C    metapackage be documented in the release notes.

=== STOP ===


Don Armstrong

-- 
2: There is no out. There is only in.
  -- "The Prisoner (2009 Miniseries)"

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 13 Dec 2012 21:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 13 Dec 2012 21:24:04 GMT) Full text and rfc822 format available.

Message #582 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]
Date: Thu, 13 Dec 2012 13:22:48 -0800
On Thu, 13 Dec 2012, Don Armstrong wrote:
> I'd like to call for votes to resolve #688772 with the following
> options, with F as further discussion. Both options A and B require a
> 3:1 majority, as they overrule the gnome maintainers; Option C does
> not.

I vote BACF.


Don Armstrong

-- 
"I was thinking seven figures," he said, "but I would have taken a
hundred grand. I'm not a greedy person." [All for a moldy bottle of
tropicana.]
 -- Sammi Hadzovic [in Andy Newman's 2003/02/14 NYT article.]
 http://www.nytimes.com/2003/02/14/nyregion/14EYEB.html

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Thu, 13 Dec 2012 21:30:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 13 Dec 2012 21:30:09 GMT) Full text and rfc822 format available.

Message #587 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]
Date: Thu, 13 Dec 2012 13:27:17 -0800
[Message part 1 (text/plain, inline)]
Don Armstrong <don@debian.org> writes:

> I'd like to call for votes to resolve #688772 with the following
> options, with F as further discussion. Both options A and B require a
> 3:1 majority, as they overrule the gnome maintainers; Option C does not.

I vote CBFA.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 08:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Dec 2012 08:21:06 GMT) Full text and rfc822 format available.

Message #592 received at 688772@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Noel David Torres Taño <envite@rolamasao.org>
Cc: debian-ctte@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 14 Dec 2012 00:18:31 -0800
[Message part 1 (text/plain, inline)]
Hi Noel,

On Tue, Nov 13, 2012 at 07:23:51PM +0000, Noel David Torres Taño wrote:

> My main concern when raising #681834 is that NM breaks my desktop system,
> not by breaking its network, but but rendering some of its applications
> unusable.  This seems not to have been addressed yet.

> The example I put once and again is that when I use pidgin, if NM is
> installed (and since my network is configured statically in /e/n/i) pidgin
> thinks I have no working network connection (which I have) and refuses to
> connect, while with NM not installed pidgin works properly.

I believe this is out of scope of the current question; but for the record,
I would consider that an obvious and release-critical bug in NM if having NM
installed but disabled in favor of static /etc/network/interfaces causes
applications to consider themselves "offline".  The correct default behavior
when NM is not in control of the network is to assume that the system is
*on*line.  (Furthermore, I think the whole idea of needing custom desktop
infrastructure to tell apps whether they're online or not is silly; you're
online if you have a default route.  Everything else - like deciding you
don't want to use your expensive 3G connection for certain kinds of data use
- is valuable, but it's icing; and it should never cause an app to fail to
use the perfectly good network just because this additional desktop service
is unavailable.)

I'm pretty sure even without talking to him that the NM maintainer would
agree with me that the following are requirements for NM's "are we online?"
API:

 - If NM is not installed, the app must assume you're online.
 - If NM is installed but disabled (not running), the app must assume you're
   online.
 - If NM is installed and running but knows that it's not managing one or
   more network connections (because these are configured in, e.g.,
   /etc/network/interfaces instead), NM must tell apps that they are online.
 - If NM is configured to control all interfaces it knows about on the
   system, only then is it allowed to tell apps if they are on or off line.

If any of this is controversial, I'm happy to discuss it further - but I
think this would be best done via a bug report against network-manager, not
via the technical committee.  Regardless, as failure to comply with any of
the above would be a plain - and plainly fixable - bug in NM and associated
libraries, I don't think that such a bug is a reason for me to vote against
a gnome dependency on NM.  Like many of the bugs that have been described in
this thread, any of the above are things that should be fixed for the good
of our users *regardless* of whether gnome depends on NM.

> This is the reason for which I consciously decided to deinstall NM knowing
> that it breaks a Recommends.  It was an explicit decision by me (the
> user), and having it overruled by the Debian Gnome team caused me some
> problems (yes, I do not track stable but unstable).

> I'm happy with NM being installed by default (I want it on my next laptop, 
> which will use Debian Gnome), but I also want my decision to deinstall it 
> being respected.

From my perspective, this is overspecifying the solution.  Being able to
arbitrarily uninstall a dependency of a package, regardless of which package
or why it's there, is not a requirement of Debian.  And indeed, if you
really want to countermand the maintainer regarding a package dependency,
there's always the 'equivs' tool for that.  The requirements that we
*should* have for the system, and that I think everyone can agree on, are:

 - Installing the gnome or the NM package must not cause the network to
   break on upgrade, even temporarily, under any circumstances.
 - Installing the gnome or the NM package must not cause any network
   configuration the user has specified to be lost.
 - Whenever it is possible to determine the user's preference, installing
   the gnome or the NM package must not cause settings in another
   configuration location (either /e/n/i or elsewhere) to be superseded by
   configuration in NM's own internal database, even if the configuration is
   functionally equivalent.
 - Installing the gnome or the NM package must not interfere with the
   functionality of other network configuration GUI tools in other desktop
   environments, because having gnome (or network-manager) installed is not
   an indication that the admin wants to *use* it.

The key point here is that all the things that are problematic about
network-manager taking over the network configuration when pulled in as a
dependency on gnome are *also problematic if they happen when installing
network-manager directly*.  The only difference is the number of users
affected in each case.

If the GNOME Team and NM maintainer can assure us that all of the above
requirements are met, and that any currently-undiscovered bugs with respect
to these requirements could be fixed in a reasonable time frame for the
wheezy release, then I have no reason at all to object to gnome depending on
network-manager.

If the GNOME Team and NM maintainer are *not* able to commit to fulfilling
these requirements when the NM package is installed, then dropping the gnome
dependency to avoid forcing network-manager onto users' systems on upgrade
is probably a suitable remedy for that.  But I am not convinced that this is
*presently* the case and that an override of the maintainers is necessary
to force this particular remedy which, in any event, would be an imperfect
solution for the user-affecting bugs.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 08:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Dec 2012 08:39:03 GMT) Full text and rfc822 format available.

Message #597 received at 688772@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]
Date: Fri, 14 Dec 2012 00:37:28 -0800
[Message part 1 (text/plain, inline)]
I vote BCFA.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

On Thu, Dec 13, 2012 at 12:06:57PM -0800, Don Armstrong wrote:
> I'd like to call for votes to resolve #688772 with the following
> options, with F as further discussion. Both options A and B require a
> 3:1 majority, as they overrule the gnome maintainers; Option C does
> not.

> === START ===
> 
> 1. The TC notes the decision of the meta-gnome maintainers to
>    implement the TC decision in #681834 by:
>     (a) softening the dependency in the gnome-core metapackage
>         from Depends to Recommends, as required
>     (b) adding a new dependency in the gnome metapackage,
>         as a Depends.  (In squeeze, this is where the dependency
>         was, but it was a Recommends.)
> 
> 2. Our intent, as stated in the rationale section of our previous
>    decision (#681834, paras 3 and 5), is that squeeze users who have
>    gnome installed but not network-manager do not find that
>    network-manager becomes installed when they upgrade to wheezy.
> 
> 3. A Recommends from gnome to network-manager-gnome would serve no
>    purpose in wheezy as gnome Depends on gnome-core which already
>    Recommends network-manager-gnome.
> 
> Therefore
> 
> A 4. We overrule the decision of the meta-gnome maintainers to add a
> A    dependency from gnome to network-manager-gnome; this dependency
> A    should be removed for the release of wheezy.
> A 
> A 5. We request that the Release Team unblock update(s) to meta-gnome so
> A    that our decisions may be implemented in wheezy.
> A 
> A 6. We request that a release note is created explaining that gnome
> A    users who do not currently have NM installed consider installing
> A    it.
> 
> 
> B 4. We overrule the decision of the meta-gnome maintainers to add a
> B    dependency from gnome to network-manager-gnome; this dependency
> B    should be removed. If in the opinion of the NM maintainer (and
> B    before the release of wheezy the Chair of the Technical Committee
> B    or an individual delegated by the Chair in consultation with the
> B    Release Team) the concerns raised in §4 of the CTTE decision
> B    #681834 have been addressed through technical means (e.g. by
> B    preventing the starting of NM as discussed in #688772), the
> B    meta-gnome maintainers may freely adjust the dependencies as
> B    usual.
> B    
> B    Specifically, valid bugs where existing valid network
> B    configurations are broken by the automatic, required installation
> B    on system upgrade of packages not previously installed which
> B    perform network configuration on should have severity serious.
> B
> B 5. We request that the Release Team unblock update(s) to meta-gnome so
> B    that our decisions may be implemented in wheezy.
> B 
> B 6. We request that a release note is created explaining that gnome
> B    users who do not currently have NM installed consider installing
> B    it.
> 
> C 4. After further discussion, we understand that reintroducing
> C    network-manager on upgrade was part of the intent, due to both
> C    substantial improvements in network-manager and tighter integration of
> C    network-manager with the GNOME desktop in wheezy.  Since the gnome
> C    metapackage has historically been more aggressive at pulling in
> C    additional packages, we believe the move of the dependency from
> C    gnome-core to gnome is an acceptable compromise that was not raised
> C    during the previous discussion.  Users who want to remove
> C    network-manager can still use the gnome-core metapackage to get the
> C    basic GNOME desktop functionality.
> C 
> C    We recommend that this upgrade behavior for users of the gnome
> C    metapackage be documented in the release notes.
> 
> === STOP ===
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 08:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Dec 2012 08:54:03 GMT) Full text and rfc822 format available.

Message #602 received at 688772@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: debian-ctte@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 14 Dec 2012 09:50:37 +0100
]] Steve Langasek 

>  - Installing the gnome or the NM package must not cause the network to
>    break on upgrade, even temporarily, under any circumstances.

Is this a requirement for other network-providing packages as well?  If
so, openvpn for instance is RC-buggy because upgrading it will restart
any configured VPNs.  We don't require other packages to continue to
work uninterrupted during upgrades, and while I can agree NM is in a bit
of special situation by virtue of controlling the network, I am not sure
being as strict as you are here is reasonable.

>  - Installing the gnome or the NM package must not cause any network
>    configuration the user has specified to be lost.

This is reasonable, and makes ifupdown RC-buggy, since rm-ing
/etc/network/interfaces and reinstalling the package will change the
network configuration (the file is recreated).  I've just filed a bug
about this.

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



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 11:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Dec 2012 11:30:03 GMT) Full text and rfc822 format available.

Message #607 received at 688772@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]
Date: Fri, 14 Dec 2012 11:26:56 +0000
Don Armstrong writes ("Bug#688772: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]"):
> I'd like to call for votes to resolve #688772 with the following
> options, with F as further discussion. Both options A and B require a
> 3:1 majority, as they overrule the gnome maintainers; Option C does
> not.

Thanks.  I vote:
  A B C F

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 13:00:03 GMT) Full text and rfc822 format available.

Message #610 received at 688772@bugs.debian.org (full text, mbox):

From: Philipp Kern <pkern@debian.org>
To: Noel David Torres Taño <envite@rolamasao.org>, debian-ctte@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 14 Dec 2012 13:35:49 +0100
[Message part 1 (text/plain, inline)]
On Fri, Dec 14, 2012 at 12:18:31AM -0800, Steve Langasek wrote:
> (Furthermore, I think the whole idea of needing custom desktop
> infrastructure to tell apps whether they're online or not is silly;
> you're online if you have a default route. [...]

I know that you put it in braces because it's not your main point. Still
I don't think this is true. Other proprietary (and some open) OSes now
have elaborate measurement facilities to check if they're online. They
detect captive portals and tell you to login, they detect if just IPv6
is broken, but IPv4 works, the other way around, they might even detect
if DNS64 and NAT64 are in use. (Coming from an IPv6 background.)

I don't want applications to be stuck connecting to stuff if they're not
really online. Obviously TCP will retry the handshake for some time
but it will still require manual action of reconnecting pidgin if
the network access is finally granted. On the other hand one could
argue that the network resources pidgin would need could already be
available when there's no default route.

So centralizing the knowledge what it takes for a network connection to
be considered up (for which n-m gives you basic means like requiring
IPv4 and/oror requiring IPv6 to be up on a given interface) makes a lot
of sense. And it could still be improved.

Kind regards
Philipp Kern
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 18:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Dec 2012 18:03:04 GMT) Full text and rfc822 format available.

Message #615 received at 688772@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 14 Dec 2012 10:00:33 -0800
Tollef Fog Heen <tfheen@err.no> writes:

> Is this a requirement for other network-providing packages as well?  If
> so, openvpn for instance is RC-buggy because upgrading it will restart
> any configured VPNs.  We don't require other packages to continue to
> work uninterrupted during upgrades,

I think we actually do require that in some cases.  OpenSSH, the X server,
and GDM come immediately to mind.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 19:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Dec 2012 19:21:03 GMT) Full text and rfc822 format available.

Message #620 received at 688772@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 688772@bugs.debian.org
Cc: 695906@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 14 Dec 2012 11:16:15 -0800
[Message part 1 (text/plain, inline)]
On Fri, Dec 14, 2012 at 09:50:37AM +0100, Tollef Fog Heen wrote:
> ]] Steve Langasek 

> >  - Installing the gnome or the NM package must not cause the network to
> >    break on upgrade, even temporarily, under any circumstances.

> Is this a requirement for other network-providing packages as well?  If
> so, openvpn for instance is RC-buggy because upgrading it will restart
> any configured VPNs.  We don't require other packages to continue to
> work uninterrupted during upgrades, and while I can agree NM is in a bit
> of special situation by virtue of controlling the network, I am not sure
> being as strict as you are here is reasonable.

Sorry, my wording was a bit sloppy there.  What I meant to say was, "an
upgrade that pulls in either gnome or network-manager as a new package must
not cause the network to break, even temporarily".  So on new installation
of the NM package, my expectation is that it will not tamper with the
current network state, because doing so may break the admin's remote
connection to the machine.

I think it's important that an upgrade of the NM package *also* not cause
the network to drop, but that's a slightly different point than the one I
was meaning to make.


> >  - Installing the gnome or the NM package must not cause any network
> >    configuration the user has specified to be lost.

> This is reasonable, and makes ifupdown RC-buggy, since rm-ing
> /etc/network/interfaces and reinstalling the package will change the
> network configuration (the file is recreated).  I've just filed a bug
> about this.

I think you're missing several steps in your proof that this is RC buggy. ;)
The policy requirement isn't that *filesystem* changes be preserved, it's
that *configuration* changes be preserved.  In what way does deleting
/etc/network/interfaces constitute a valid configuration that must be
preserved?  When ifupdown recreates the file, it populates it only with a
config for lo.  I don't think it's reasonable to claim that it's valid and
intentional to configure a system in such a way that it will fail to bring
up the loopback interface on boot.  In fact, booting the system without lo
breaks so many assumptions that Ubuntu, for example, *unconditionally*
brings up lo on boot, whether or not it's configured in
/etc/network/interfaces.  I consider restoring a stock /e/n/i on package
upgrade to be in the same category.

If the reason you raise this concern is because of my comment that NM should
always report the system "online" unless it controls all the network
interfaces, I was implicitly excluding lo from the reckoning.  First,
it's not relevant to whether the machine is online, and second, there's only
one valid state for this interface ("up") so there's no configuration to
fight over the management of.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 21:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Dec 2012 21:27:03 GMT) Full text and rfc822 format available.

Message #625 received at 688772@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: Steve Langasek <vorlon@debian.org>
Cc: 688772@bugs.debian.org, 695906@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 14 Dec 2012 22:23:58 +0100
]] Steve Langasek 

> On Fri, Dec 14, 2012 at 09:50:37AM +0100, Tollef Fog Heen wrote:
> > ]] Steve Langasek 
> 
> > >  - Installing the gnome or the NM package must not cause the network to
> > >    break on upgrade, even temporarily, under any circumstances.
> 
> > Is this a requirement for other network-providing packages as well?  If
> > so, openvpn for instance is RC-buggy because upgrading it will restart
> > any configured VPNs.  We don't require other packages to continue to
> > work uninterrupted during upgrades, and while I can agree NM is in a bit
> > of special situation by virtue of controlling the network, I am not sure
> > being as strict as you are here is reasonable.
> 
> Sorry, my wording was a bit sloppy there.  What I meant to say was, "an
> upgrade that pulls in either gnome or network-manager as a new package must
> not cause the network to break, even temporarily".  So on new installation
> of the NM package, my expectation is that it will not tamper with the
> current network state, because doing so may break the admin's remote
> connection to the machine.

Ok, fair enough.

> I think it's important that an upgrade of the NM package *also* not cause
> the network to drop, but that's a slightly different point than the one I
> was meaning to make.

My question then still stands: Do you consider NM in any way special
here or does the same requirement apply to other network-providing apps?

> > >  - Installing the gnome or the NM package must not cause any network
> > >    configuration the user has specified to be lost.
> 
> > This is reasonable, and makes ifupdown RC-buggy, since rm-ing
> > /etc/network/interfaces and reinstalling the package will change the
> > network configuration (the file is recreated).  I've just filed a bug
> > about this.
> 
> I think you're missing several steps in your proof that this is RC buggy. ;)

I had enough steps in there that one of the release managers agreed with
me.

> The policy requirement isn't that *filesystem* changes be preserved, it's
> that *configuration* changes be preserved.  In what way does deleting
> /etc/network/interfaces constitute a valid configuration that must be
> preserved?

The policy requirement is not that the configuration changes are
valid. It's not ok to replace a config file just because it has a syntax
error in it, is it?  Also, see below.

> When ifupdown recreates the file, it populates it only with a
> config for lo.  I don't think it's reasonable to claim that it's valid and
> intentional to configure a system in such a way that it will fail to bring
> up the loopback interface on boot.  In fact, booting the system without lo
> breaks so many assumptions that Ubuntu, for example, *unconditionally*
> brings up lo on boot, whether or not it's configured in
> /etc/network/interfaces.  I consider restoring a stock /e/n/i on package
> upgrade to be in the same category.

Putting «iface lo» into /etc/network/interfaces is not only a way to
ensure there is a loopback interface on boot. It's also a way for
ifupdown to claim to handle that interface (this is a natural
consequence of the CTTE ruling; that ifupdown is special and has
precedence and other tools should stay away from interfaces where there
is a ifupdown configuration for the interface), so if ifupdown does add
that configuration, there is no way for me to have ifupdown installed so
I can read the man page at the same time as letting other tools manage
lo.

I might also dislike the name «lo» for loopback and rename the lo
interface to something else, and let «lo» be the name of yet another
interface. It's a bit crazy, but not much cares about network interface
names apart from the network configuration tools, so this would actually
break a most unusual, but otherwise valid configuration of the network
stack.  ifupdown would break that configuration.

> If the reason you raise this concern is because of my comment that NM should
> always report the system "online" unless it controls all the network
> interfaces, I was implicitly excluding lo from the reckoning.  First,
> it's not relevant to whether the machine is online, and second, there's only
> one valid state for this interface ("up") so there's no configuration to
> fight over the management of.

Your mail triggered me to go look, but it wasn't otherwise directly
related, no.

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



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 23:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Dec 2012 23:06:03 GMT) Full text and rfc822 format available.

Message #630 received at 688772@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Tollef Fog Heen <tfheen@err.no>
Cc: 688772@bugs.debian.org, 695906@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 14 Dec 2012 15:02:14 -0800
[Message part 1 (text/plain, inline)]
On Fri, Dec 14, 2012 at 10:23:58PM +0100, Tollef Fog Heen wrote:

> > I think it's important that an upgrade of the NM package *also* not cause
> > the network to drop, but that's a slightly different point than the one I
> > was meaning to make.

> My question then still stands: Do you consider NM in any way special
> here or does the same requirement apply to other network-providing apps?

I think NM is quantitatively different from other network-providing
packages, but not qualitatively so, because NM purports to manage the
primary network connection.  If you're remotely connected to a machine over
openvpn, and you upgrade the openvpn package, and you are then surprised
that the connection drops in the middle while the openvpn server restarts,
well...  that's a bug, but I'm not sure why you as the admin weren't
prepared to deal with that.  OTOH, if you upgrade the quagga package and it
flushes your entire network's BGP table (to take a historical example),
that's a serious issue.

So NM is special in that it's important.  Other packages that provide
similar management of the primary network connection are similarly
important.

> > The policy requirement isn't that *filesystem* changes be preserved, it's
> > that *configuration* changes be preserved.  In what way does deleting
> > /etc/network/interfaces constitute a valid configuration that must be
> > preserved?

> The policy requirement is not that the configuration changes are
> valid.

The policy requirement specifically says that:

     Configuration file handling must conform to the following behavior:
        * local changes must be preserved during a package upgrade

You're right that validity is not mentioned.  But I consider this a very
broad gray area open to interpretation, and I think all of the following are
legitimate, non-buggy (and especially not RC-buggy) actions for a package to
take:

  - update a configuration file on upgrade to drop deprecated,
    user-specified configuration options that are no longer supported (and
    which may cause the package to stop working)
  - convert the configuration file on upgrade from one format to another,
    preserving any user changes to the configuration settings but not the
    text of the config file
  - modify a config file to recover from known software-induced damage, even
    though it is impossible to determine with certainty that a particular
    file was damaged by software vs. by explicit admin action
  - recreate a template config file on upgrade if missing, where the
    contents of that config file correspond to the default behavior of the
    software when not configured at all
  - fail to complete package configuration while the config file is invalid,
    requiring the admin to fix it manually.

I think recreating a stock non-conffile config file when it's been removed
is just one more point along this continuum.  You might consider it a bug to
recreate the file, but I see no basis for considering it a policy violation.

And by the way, if you're going to treat it as a serious bug, you'd better
get filing other bugs for consistency.  Just off the top of my head,
base-passwd has had the same handling of /etc/passwd for *years* without
anyone objecting.  To me, this is very clearly a matter of moving the goal
posts.

> It's not ok to replace a config file just because it has a syntax error in
> it, is it?  Also, see below.

Replace, no.  Repair, maybe.

> > When ifupdown recreates the file, it populates it only with a
> > config for lo.  I don't think it's reasonable to claim that it's valid and
> > intentional to configure a system in such a way that it will fail to bring
> > up the loopback interface on boot.  In fact, booting the system without lo
> > breaks so many assumptions that Ubuntu, for example, *unconditionally*
> > brings up lo on boot, whether or not it's configured in
> > /etc/network/interfaces.  I consider restoring a stock /e/n/i on package
> > upgrade to be in the same category.

> Putting «iface lo» into /etc/network/interfaces is not only a way to
> ensure there is a loopback interface on boot. It's also a way for
> ifupdown to claim to handle that interface (this is a natural
> consequence of the CTTE ruling; that ifupdown is special and has
> precedence and other tools should stay away from interfaces where there
> is a ifupdown configuration for the interface), so if ifupdown does add
> that configuration, there is no way for me to have ifupdown installed so
> I can read the man page at the same time as letting other tools manage
> lo.

I don't see where the previous TC ruling says that ifupdown is special. 
Rather, it says that upgrading gnome-core shouldn't cause network-manager to
clobber the user's network preferences on upgrade, /whichever/ tool they
were using to manage those.

That should be trivially easy in the case of lo.  If the /e/n/i entry for lo
is missing, or matches this:

  iface lo inet loopback

... it's fair game.  If it's something else, then /against all reason/, the
user has configured lo in a non-standard way, and NM should respect that.

So I don't think this bug in ifupdown in any way blocks NM from being able
to do the right thing.  If you disagree, let's explore this further.

> I might also dislike the name «lo» for loopback and rename the lo
> interface to something else, and let «lo» be the name of yet another
> interface. It's a bit crazy

I agree with the "crazy", but not with the qualifier ("a bit"), and
therefore don't find this at all persuasive.  Policy violations are
release-critical bugs not because we love rules in the abstract, but because
such bugs cause real problems for how packages interact with one another and
for how administrators interact with the system as a whole.  A *technical*
policy violation which has no practical impact on any users except those of
the mad scientist variety who go out of their way to violate assumptions
about the base system should not be a release-critical bug, or even be
flagged as a policy violation, IMHO.

> , but not much cares about network interface names apart from the network
> configuration tools, so this would actually break a most unusual, but
> otherwise valid configuration of the network stack.  ifupdown would break
> that configuration.

To be clear, the full scenario being described is:

 - the user has renamed the loopback interface in the kernel (presumably
   using a udev rule), and renamed another, real network interface 'lo'
 - the user has then configured these network interfaces using
   network-manager
 - the user has removed /etc/network/interfaces from the system instead of
   leaving an empty or commented-out file

Even setting aside the fact that taking a name from one network device and
giving it to another is largely full of kernel/udev race lulz, I don't see
any way that this scenario is something Debian should be concerned about
supporting.

Thanks,
-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 14 Dec 2012 23:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Dec 2012 23:30:03 GMT) Full text and rfc822 format available.

Message #635 received at 688772@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Philipp Kern <pkern@debian.org>
Cc: Noel David Torres Taño <envite@rolamasao.org>, debian-ctte@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Fri, 14 Dec 2012 15:27:33 -0800
[Message part 1 (text/plain, inline)]
On Fri, Dec 14, 2012 at 01:35:49PM +0100, Philipp Kern wrote:
> On Fri, Dec 14, 2012 at 12:18:31AM -0800, Steve Langasek wrote:
> > (Furthermore, I think the whole idea of needing custom desktop
> > infrastructure to tell apps whether they're online or not is silly;
> > you're online if you have a default route. [...]

> I know that you put it in braces because it's not your main point. Still
> I don't think this is true. Other proprietary (and some open) OSes now
> have elaborate measurement facilities to check if they're online. They
> detect captive portals and tell you to login, they detect if just IPv6
> is broken, but IPv4 works, the other way around, they might even detect
> if DNS64 and NAT64 are in use. (Coming from an IPv6 background.)

> I don't want applications to be stuck connecting to stuff if they're not
> really online. Obviously TCP will retry the handshake for some time
> but it will still require manual action of reconnecting pidgin if
> the network access is finally granted. On the other hand one could
> argue that the network resources pidgin would need could already be
> available when there's no default route.

> So centralizing the knowledge what it takes for a network connection to
> be considered up (for which n-m gives you basic means like requiring
> IPv4 and/oror requiring IPv6 to be up on a given interface) makes a lot
> of sense. And it could still be improved.

Fair point.  The main idea I was trying to express wasn't that having such a
higher-level network connectivity service was somehow redundant or useless,
but the importance of failing *open* when the service is absent or operating
with incomplete information.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 15 Dec 2012 07:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 15 Dec 2012 07:33:05 GMT) Full text and rfc822 format available.

Message #640 received at 688772@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: Steve Langasek <vorlon@debian.org>
Cc: 688772@bugs.debian.org, 695906@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Sat, 15 Dec 2012 08:30:25 +0100
]] Steve Langasek 

> And by the way, if you're going to treat it as a serious bug, you'd better
> get filing other bugs for consistency.  Just off the top of my head,
> base-passwd has had the same handling of /etc/passwd for *years* without
> anyone objecting.  To me, this is very clearly a matter of moving the goal
> posts.

I file those bugs whenever I see them and has been doing this for a
while.  See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558784 for
another example.

> > It's not ok to replace a config file just because it has a syntax error in
> > it, is it?  Also, see below.
> 
> Replace, no.  Repair, maybe.

I don't think it should do that, it should notify the admin.  Trying to
guess the intentions of admins is not particularly easy.

> > > When ifupdown recreates the file, it populates it only with a
> > > config for lo.  I don't think it's reasonable to claim that it's valid and
> > > intentional to configure a system in such a way that it will fail to bring
> > > up the loopback interface on boot.  In fact, booting the system without lo
> > > breaks so many assumptions that Ubuntu, for example, *unconditionally*
> > > brings up lo on boot, whether or not it's configured in
> > > /etc/network/interfaces.  I consider restoring a stock /e/n/i on package
> > > upgrade to be in the same category.
> 
> > Putting «iface lo» into /etc/network/interfaces is not only a way to
> > ensure there is a loopback interface on boot. It's also a way for
> > ifupdown to claim to handle that interface (this is a natural
> > consequence of the CTTE ruling; that ifupdown is special and has
> > precedence and other tools should stay away from interfaces where there
> > is a ifupdown configuration for the interface), so if ifupdown does add
> > that configuration, there is no way for me to have ifupdown installed so
> > I can read the man page at the same time as letting other tools manage
> > lo.
> 
> I don't see where the previous TC ruling says that ifupdown is special. 
> Rather, it says that upgrading gnome-core shouldn't cause network-manager to
> clobber the user's network preferences on upgrade, /whichever/ tool they
> were using to manage those.

I did explicitly say it was a natural consequence of the ruling, not
that the ruling itself said so.  The alternative is for the relation to
be symmetrical, so ifupdown should stay away from managing interfaces
where there exists a NM config for the interface without there existing
an explicit configuration for the ifupdown interface?  It's easy enough
to generate such a configuration by using mappings, for instance.

This becomes a nightmare once you drag wicd into this and all tools need
to know about what other tools might want to manage an interface.  I
think it's important that we end up with something that's actually
supportable, rather than something which might be formally better, but
in practice so complex it becomes brittle beyond repair.

> That should be trivially easy in the case of lo.  If the /e/n/i entry for lo
> is missing, or matches this:
> 
>   iface lo inet loopback
> 
> ... it's fair game.  If it's something else, then /against all reason/, the
> user has configured lo in a non-standard way, and NM should respect that.
> 
> So I don't think this bug in ifupdown in any way blocks NM from being able
> to do the right thing.  If you disagree, let's explore this further.

I don't think I've said it blocks NM from doing the right thing.  I've
said it's a bug in ifupdown.

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



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 18 Dec 2012 01:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 18 Dec 2012 01:09:03 GMT) Full text and rfc822 format available.

Message #645 received at 688772@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Don Armstrong <don@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]
Date: Mon, 17 Dec 2012 18:06:17 -0700
[Message part 1 (text/plain, inline)]
Don Armstrong <don@debian.org> writes:

> I'd like to call for votes to resolve #688772 

I vote CBAF.

Bdale
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 18 Dec 2012 17:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 18 Dec 2012 17:54:03 GMT) Full text and rfc822 format available.

Message #650 received at 688772@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@ayous.org>
To: 688772@bugs.debian.org
Subject: Re: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]
Date: Tue, 18 Dec 2012 18:50:39 +0100
* Don Armstrong (don@debian.org) [121213 20:07]:
> I'd like to call for votes to resolve #688772 with the following
> options, with F as further discussion. Both options A and B require a
> 3:1 majority, as they overrule the gnome maintainers; Option C does
> not.

I vote
BCAF


Andi



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 19 Dec 2012 11:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 19 Dec 2012 11:48:03 GMT) Full text and rfc822 format available.

Message #655 received at 688772@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Russ Allbery <rra@debian.org>, 688772@bugs.debian.org
Subject: Re: Bug#688772: gnome Depends network-manager-gnome
Date: Wed, 19 Dec 2012 11:44:45 +0000
On Fri, Dec 14, 2012 at 10:00:33AM -0800, Russ Allbery wrote:
> Tollef Fog Heen <tfheen@err.no> writes:
> > Is this a requirement for other network-providing packages as well?  If
> > so, openvpn for instance is RC-buggy because upgrading it will restart
> > any configured VPNs.  We don't require other packages to continue to
> > work uninterrupted during upgrades,
> 
> I think we actually do require that in some cases.  OpenSSH, the X server,
> and GDM come immediately to mind.

While nobody's ever told me that this is a requirement as such, I
consider it one on my own account as OpenSSH maintainer.  It's just so
common to perform upgrades over SSH that I'd consider it irresponsible
to break that.  (And fortunately the design of the OpenSSH server is
such that it tends to just work.)

For network-providing packages in general, I'd want to think about it
case by case, and I think it would depend on how common it is to perform
upgrades over the network interfaces they implement or support.  openvpn
is commonly used, for instance, by people working at home to access
their employer's network, and in that case an interruption during
upgrade is not so important.  If it's common to operate in reverse and
upgrade a system at the "client" end of an openvpn link, then that would
be a good argument for upgrading the severity of such a bug.

Some types of networking are just so rarely used as anything other than
a means of getting connectivity in network-poor locations that I would
have a very hard time arguing that their interruption during upgrades
could be release-critical.  For instance, if a 3G network interface went
down during upgrade, or the client end of an IP-over-DNS link, then
that's ungraceful and could be handled more smoothly, but I don't think
it's RC.

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 19 Dec 2012 12:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 19 Dec 2012 12:09:03 GMT) Full text and rfc822 format available.

Message #660 received at 688772@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]
Date: Wed, 19 Dec 2012 12:05:22 +0000
On Thu, Dec 13, 2012 at 12:06:57PM -0800, Don Armstrong wrote:
> I'd like to call for votes to resolve #688772 with the following
> options, with F as further discussion. Both options A and B require a
> 3:1 majority, as they overrule the gnome maintainers; Option C does
> not.

I vote BACF.

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Fri, 21 Dec 2012 00:06:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Dec 2012 00:06:06 GMT) Full text and rfc822 format available.

Message #665 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]
Date: Thu, 20 Dec 2012 16:02:43 -0800
Assuming I've done everything properly:

BACF don
CBFA rra
BCFA vorlon
ABCF ian
CBAF bdale
BCAF aba
BACF cjwatson

option A:F 5:2; does not beat majority requirements.
option B:F 7:0; beats majority requirements
option C:F 7:0; beats majority requirements

B:C 5:2
B:F 7:0
C:F 7:0

Option B is the winner.

Therefore the CTTE resolves:

=== START ===

1. The TC notes the decision of the meta-gnome maintainers to
   implement the TC decision in #681834 by:
    (a) softening the dependency in the gnome-core metapackage
        from Depends to Recommends, as required
    (b) adding a new dependency in the gnome metapackage,
        as a Depends.  (In squeeze, this is where the dependency
        was, but it was a Recommends.)

2. Our intent, as stated in the rationale section of our previous
   decision (#681834, paras 3 and 5), is that squeeze users who have
   gnome installed but not network-manager do not find that
   network-manager becomes installed when they upgrade to wheezy.

3. A Recommends from gnome to network-manager-gnome would serve no
   purpose in wheezy as gnome Depends on gnome-core which already
   Recommends network-manager-gnome.

Therefore

4. We overrule the decision of the meta-gnome maintainers to add a
   dependency from gnome to network-manager-gnome; this dependency
   should be removed. If in the opinion of the NM maintainer (and
   before the release of wheezy the Chair of the Technical Committee
   or an individual delegated by the Chair in consultation with the
   Release Team) the concerns raised in §4 of the CTTE decision
   #681834 have been addressed through technical means (e.g. by
   preventing the starting of NM as discussed in #688772), the
   meta-gnome maintainers may freely adjust the dependencies as
   usual.
   
   Specifically, valid bugs where existing valid network
   configurations are broken by the automatic, required installation
   on system upgrade of packages not previously installed which
   perform network configuration on should have severity serious.

5. We request that the Release Team unblock update(s) to meta-gnome so
   that our decisions may be implemented in wheezy.

6. We request that a release note is created explaining that gnome
   users who do not currently have NM installed consider installing
   it.

=== STOP ===

By the time you read this, I should have updated the decision file in
the git repository. Please feel free to make changes to that before I
send out the announcement today or tomorrow.

I will also file a new bug against the gnome meta package with the
resolution when I publish the announcement.


Don Armstrong

-- 
Something the junk advertisers don't seem to understand: we live in an
information super-saturated world. If I don't want to buy something,
no amount of shouting or propagandizing will budge me; all it will do
is get me annoyed. On the other hand, if I have a need for your
product, I can seek it out in an eyeblink.
 -- Charles Stross "Toast: A Con Report" in _Toast_ p136

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 26 Feb 2013 18:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 26 Feb 2013 18:33:03 GMT) Full text and rfc822 format available.

Message #670 received at 688772@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: Josselin Mouette <joss@debian.org>
Cc: debian-devel@lists.debian.org, 688772@bugs.debian.org
Subject: Re: [CTTE #688772] Dependency of meta-gnome on network-manager
Date: Tue, 26 Feb 2013 10:31:37 -0800
On Tue, 26 Feb 2013, Josselin Mouette wrote:
> Le lundi 25 février 2013 à 11:43 -0800, Don Armstrong a écrit :
> > 4. We overrule the decision of the meta-gnome maintainers to add a
> >    dependency from gnome to network-manager-gnome; this dependency
> >    should be removed. If in the opinion of the NM maintainer (and
> >    before the release of wheezy the Chair of the Technical Committee
> >    or an individual delegated by the Chair in consultation with the
> >    Release Team) the concerns raised in §4 of the CTTE decision
> >    #681834 have been addressed through technical means (e.g. by
> >    preventing the starting of NM as discussed in #688772), the
> >    meta-gnome maintainers may freely adjust the dependencies as
> >    usual.
> 
> Can we consider that the changes in NetworkManager 0.9.4.0-9 are OK on
> this matter?

I think those changes did most/all of the work to resolve the really
important issues from my perspective.[1] However, Bdale and the RMs
are the people who have to decide on this, so my opinion doesn't
really count for anything.

If anyone else has any comments on why the current version of NM
doesn't address the concerns in §4 of the CTTE decision, please raise
them to the bug.


Don Armstrong

1: In case it wasn't clear: thanks to you and Michael for taking the
concerns of the CTTE seriously and working to find a solution;
publishing the decision now instead of earlier was just because of a
lack of time on my part.
-- 
I've had so much good luck recently I was getting sated with it. It's
like sugar, good luck. At first it's very sweet, but after a while you
start to think: any more of this and I shall be sick.
 -- Adam Roberts _Yellow Blue Tibia_ p301

http://www.donarmstrong.com              http://rzlab.ucr.edu



Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Tue, 26 Feb 2013 23:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 26 Feb 2013 23:54:03 GMT) Full text and rfc822 format available.

Message #675 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Josselin Mouette <joss@debian.org>, debian-devel@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
Date: Tue, 26 Feb 2013 18:50:51 -0500
[Message part 1 (text/plain, inline)]
On Tuesday, February 26, 2013 13:31:37, Don Armstrong wrote:
> On Tue, 26 Feb 2013, Josselin Mouette wrote:
> > Le lundi 25 février 2013 à 11:43 -0800, Don Armstrong a écrit :
> > > 4. We overrule the decision of the meta-gnome maintainers to add a
> > > 
> > >    dependency from gnome to network-manager-gnome; this dependency
> > >    should be removed. If in the opinion of the NM maintainer (and
> > >    before the release of wheezy the Chair of the Technical Committee
> > >    or an individual delegated by the Chair in consultation with the
> > >    Release Team) the concerns raised in §4 of the CTTE decision
> > >    #681834 have been addressed through technical means (e.g. by
> > >    preventing the starting of NM as discussed in #688772), the
> > >    meta-gnome maintainers may freely adjust the dependencies as
> > >    usual.
> > 
> > Can we consider that the changes in NetworkManager 0.9.4.0-9 are OK on
> > this matter?
> 
> I think those changes did most/all of the work to resolve the really
> important issues from my perspective.[1] However, Bdale and the RMs
> are the people who have to decide on this, so my opinion doesn't
> really count for anything.
> 
> If anyone else has any comments on why the current version of NM
> doesn't address the concerns in §4 of the CTTE decision, please raise
> them to the bug.

Were the issues relating to wicd and network-manager intercting badly 
addressed somehow?  I know there was a plan [1] to fix this, but I didn't see 
the intended followup.  [There may have been unforseen difficulties with the 
proposed solution.]

Last I checked this as part of #688772, attempting to use wicd caused a 
counterintuitive error message of "Connection Failed: bad password" if 
network-manager was running.  I just tested this again on Sid, and this is 
still the case.  [I don't currently have the ability to test Wheezy for this.]

When this was brought up in the bug report, the response was "network-manager 
can be installed, then disabled", but how to do that wasn't documented 
anywhere in the network-manager package.  Instead the next suggestion was 
documenting this issue in the Wheey errata [2], but I don't see network-
manager or wicd mentioned there, nor mentioned in the Installation Guide [3] 
for Wheezy.

Suggestions?

[1]:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688772#464

[2]:  http://www.debian.org/devel/debian-installer/errata

[3]:  http://www.debian.org/releases/testing/amd64/install.txt.en

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 27 Feb 2013 11:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil McGovern <neilm@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 27 Feb 2013 11:12:06 GMT) Full text and rfc822 format available.

Message #680 received at 688772@bugs.debian.org (full text, mbox):

From: Neil McGovern <neilm@debian.org>
To: Chris.Knadle@coredump.us, 688772@bugs.debian.org
Cc: Josselin Mouette <joss@debian.org>, debian-devel@lists.debian.org
Subject: Re: Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
Date: Wed, 27 Feb 2013 10:58:03 +0000
[Message part 1 (text/plain, inline)]
On Tue, Feb 26, 2013 at 06:50:51PM -0500, Chris Knadle wrote:
> Instead the next suggestion was documenting this issue in the Wheey
> errata [2], but I don't see network- manager or wicd mentioned there,
> nor mentioned in the Installation Guide [3] for Wheezy.
> 

I'm guessing that's because no one has produced a patch, or stepped up
to help with the release notes (see
https://lists.debian.org/debian-devel-announce/2013/01/msg00005.html)

Neil
-- 
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 27 Feb 2013 12:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 27 Feb 2013 12:42:03 GMT) Full text and rfc822 format available.

Message #685 received at 688772@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Chris.Knadle@coredump.us, Neil McGovern <neilm@debian.org>
Cc: Josselin Mouette <joss@debian.org>, debian-devel@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
Date: Wed, 27 Feb 2013 13:39:44 +0100
[Message part 1 (text/plain, inline)]
On 27.02.2013 00:50, Chris Knadle wrote:
> When this was brought up in the bug report, the response was "network-manager 
> can be installed, then disabled", but how to do that wasn't documented 
> anywhere in the network-manager package.  Instead the next suggestion was 
> documenting this issue in the Wheey errata [2], but I don't see network-
> manager or wicd mentioned there, nor mentioned in the Installation Guide [3] 
> for Wheezy.
> 
> Suggestions?

I will try to add a section to README.Debian which should be re-usable
for the release notes / errata.

Neil, who should I contact getting those changes into the release notes?
If anyone is willing to review the text, even better.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 27 Feb 2013 12:45:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 27 Feb 2013 12:45:13 GMT) Full text and rfc822 format available.

Message #690 received at 688772@bugs.debian.org (full text, mbox):

From: Niels Thykier <niels@thykier.net>
Cc: debian-devel@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
Date: Wed, 27 Feb 2013 13:44:39 +0100
On 2013-02-27 13:39, Michael Biebl wrote:
> On 27.02.2013 00:50, Chris Knadle wrote:
>> When this was brought up in the bug report, the response was "network-manager 
>> can be installed, then disabled", but how to do that wasn't documented 
>> anywhere in the network-manager package.  Instead the next suggestion was 
>> documenting this issue in the Wheey errata [2], but I don't see network-
>> manager or wicd mentioned there, nor mentioned in the Installation Guide [3] 
>> for Wheezy.
>>
>> Suggestions?
> 
> I will try to add a section to README.Debian which should be re-usable
> for the release notes / errata.
> 
> Neil, who should I contact getting those changes into the release notes?
> If anyone is willing to review the text, even better.
> 
> Michael
> 

File a bug against "release-notes" should work[1]

~Niels

[1]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release-notes;dist=unstable





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 27 Feb 2013 13:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil McGovern <neilm@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 27 Feb 2013 13:00:03 GMT) Full text and rfc822 format available.

Message #695 received at 688772@bugs.debian.org (full text, mbox):

From: Neil McGovern <neilm@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: Chris.Knadle@coredump.us, Neil McGovern <neilm@debian.org>, Josselin Mouette <joss@debian.org>, debian-devel@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
Date: Wed, 27 Feb 2013 12:57:23 +0000
[Message part 1 (text/plain, inline)]
On Wed, Feb 27, 2013 at 01:39:44PM +0100, Michael Biebl wrote:
> On 27.02.2013 00:50, Chris Knadle wrote:
> > When this was brought up in the bug report, the response was "network-manager 
> > can be installed, then disabled", but how to do that wasn't documented 
> > anywhere in the network-manager package.  Instead the next suggestion was 
> > documenting this issue in the Wheey errata [2], but I don't see network-
> > manager or wicd mentioned there, nor mentioned in the Installation Guide [3] 
> > for Wheezy.
> > 
> > Suggestions?
> 
> I will try to add a section to README.Debian which should be re-usable
> for the release notes / errata.
> 
> Neil, who should I contact getting those changes into the release notes?
> If anyone is willing to review the text, even better.
> 

The release-notes pseudopackage, and the debian-doc mailing list are
good places to start.
http://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/
contains the actual source.

Neil
-- 
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 27 Feb 2013 20:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 27 Feb 2013 20:39:06 GMT) Full text and rfc822 format available.

Message #700 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: Michael Biebl <biebl@debian.org>
Cc: Neil McGovern <neilm@debian.org>, Josselin Mouette <joss@debian.org>, debian-devel@lists.debian.org, 688772@bugs.debian.org
Subject: Re: Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
Date: Wed, 27 Feb 2013 15:33:45 -0500
[Message part 1 (text/plain, inline)]
On Wednesday, February 27, 2013 07:39:44, Michael Biebl wrote:
> On 27.02.2013 00:50, Chris Knadle wrote:
> > When this was brought up in the bug report, the response was
> > "network-manager can be installed, then disabled", but how to do that
> > wasn't documented anywhere in the network-manager package.  Instead the
> > next suggestion was documenting this issue in the Wheey errata [2], but
> > I don't see network- manager or wicd mentioned there, nor mentioned in
> > the Installation Guide [3] for Wheezy.
> > 
> > Suggestions?
> 
> I will try to add a section to README.Debian which should be re-usable
> for the release notes / errata.

Thanks much.

> Neil, who should I contact getting those changes into the release notes?
> If anyone is willing to review the text, even better.

I'd certainly be willing to help with that.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Wed, 13 Mar 2013 05:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 13 Mar 2013 05:51:03 GMT) Full text and rfc822 format available.

Message #705 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: debian-ctte@lists.debian.org, Michael Biebl <biebl@debian.org>, 688772@bugs.debian.org
Cc: Josselin Mouette <joss@debian.org>, debian-devel@lists.debian.org
Subject: Re: Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
Date: Wed, 13 Mar 2013 01:39:55 -0400
[Message part 1 (text/plain, inline)]
On Wednesday, February 27, 2013 07:39:44, Michael Biebl wrote:
> On 27.02.2013 00:50, Chris Knadle wrote:
> > When this was brought up in the bug report, the response was
> > "network-manager can be installed, then disabled", but how to do that
> > wasn't documented anywhere in the network-manager package.  Instead the
> > next suggestion was documenting this issue in the Wheey errata [2], but
> > I don't see network- manager or wicd mentioned there, nor mentioned in
> > the Installation Guide [3] for Wheezy.
> > 
> > Suggestions?
> 
> I will try to add a section to README.Debian which should be re-usable
> for the release notes / errata.

It's been a couple of weeks, so I did some minimal testing and wrote up some 
initial text for this purpose based on the behavior I observed.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
[network-manager-bug#681834-and-bug#688772.txt (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#688772; Package tech-ctte. (Sat, 06 Apr 2013 17:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris.Knadle@coredump.us:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 06 Apr 2013 17:15:04 GMT) Full text and rfc822 format available.

Message #710 received at 688772@bugs.debian.org (full text, mbox):

From: Chris Knadle <Chris.Knadle@coredump.us>
To: 688772@bugs.debian.org
Subject: Re: Bug#688772: Dependency of meta-gnome on network-manager
Date: Sat, 6 Apr 2013 13:11:16 -0400
Patches to the release-notes document to discuss the symptoms and workaround 
for the conflict between NM and wicd-daemon are available in #704211.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us



Reply sent to Bdale Garbee <bdale@gag.com>:
You have taken responsibility. (Thu, 30 May 2013 17:21:05 GMT) Full text and rfc822 format available.

Notification sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Bug acknowledged by developer. (Thu, 30 May 2013 17:21:05 GMT) Full text and rfc822 format available.

Message #715 received at 688772-done@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: 688772-done@bugs.debian.org
Subject: finished
Date: Thu, 30 May 2013 11:09:48 -0600
[Message part 1 (text/plain, inline)]
With wheezy released and all agreed-upon actions apparently taken, I
consider this bug resolved.

Bdale
[Message part 2 (application/pgp-signature, inline)]

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 28 Jun 2013 07:39:28 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 20:04:30 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.