Bug#934948: Unnecessary dependencies vs multiple binary packages

[Scott Kitterman]

Looking back at the original mail, it seems like the main complaint is that 
the two packages were treated differently.  The easiest resolution to that 
problem is to go ahead and remove node-autoprefixer.  That'll solve the 
inconsistency.

How small is too small is a judgement call may be the FTP team member 
reviewing the package.  Different people will not always make the same 
judgement.

Unless someone can figure out an actual resolvable controversy, I don't seen 
any point in bothering other FTP team members with this.  To the extent 
anything is being requested, it seems like it's infeasible (write down exact 
rules for what too small to split into multiple binaries would be and then 
have all FTP team members apply the standard perfectly).

Scott K

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Scott Kitterman]

On November 3, 2017 9:09:31 PM EDT, Sam Hartman  wrote:
>> "Steve" == Steve Langasek  writes:
>
>Steve> Hi Diane,
>Steve> On Thu, Nov 02, 2017 at 11:48:05AM -0700, Diane Trout wrote:
>>> I only just subscribed and only have read some of the discussion
>>> so this may be a bit off topic or already discussed.
>
>>> But I was wondering if the project has thought about explicitly
>>> encouraging mentoring in techniques for handling interpersonal
>>> conflict and helping members develop interpersonal skills?
>
>   >> I know there's active research into managing team conflict, and I
>   >> bet there are some Debian members who have been more effective at
>>> helping other team members that we might be able to learn from.
>
>   >> I know we have methods to share technical skills via policies and
>>> best practices, but how do we identify and share useful social
>>> techniques?
>
>>> For instance I think active listening is a useful technique when
>>> trying to develop a consensus about a topic.
>
>>> (e.g.
>http://ggia.berkeley.edu/practice/active_listening#data-tab-how
>>> )
>
>>> But I don't know how many others know about it and there would
>>> need to be some adjustment for a distributed team like Debian.
>
>Steve> Better skills for handling interpersonal conflict can never
>   Steve> be a bad thing.  However, the Technical Committee exists as a
>Steve> decision-making body of last resort, when consensus is not
>Steve> possible (because two parties have incompatible goals, or
>   Steve> because discussion is not converging on agreement fast enough
>Steve> to matter).
>
>I think that Debian does need a decision making body of last resort.
>I personally think these communication skills are critical for such a
>body.

One critical thing I think the TC misses is to consider if it's time to invoke 
last resort processes or not.  My impression is that if someone brings an issue 
to the TC, there's an assumption that the TC has to deal with it.

The last time I was involved with an issue brought to the TC, it had been 
brought after zero discussion between the person filing the bug and the 
relevant team.  Complaining to the TC about a bug that's been dormant for years 
only a few days after resurrecting discussion about it (AIUI) seems similarly 
aggressive.

Diving into issues in these kinds of circumstances turns the TC into nothing 
more than a stick to beat other developers with.  I think we need something 
like the TC, but I also think part of being the decider of last resort is 
sticking to the last resort part.

Scott K

P.S. Having been through a couple of TC issues that involved packages or teams 
relevant to me, I totally get orphaning a package.  I don't know what fraction 
of packages I maintain I care enough about to deal with a TC complaint over 
them, but I'm pretty sure it's way less than half.

Bug#573745: Packages to consider

[Scott Kitterman]

I would propose that the tech ctte not consider changing maintainership of 
python-defaults and python3-defaults.  They are both maintained by a team of 
three DDs and seem to be working reasonably well.  A number of changes for the 
better have been made in the last two years and these packages are essential 
to them.

There is agreement on a single helper package for Python 3 (dh_python3).  It 
is implemented in python3-defaults.  There is general (not 100%, but general) 
consensus on gradual migration to a single helper for Python (dh_python2).  
Both python-support and python-central are now classified as deprecated with 
the agreement of their maintainers.  dh_python2 is part of python-defaults.

As I read the tech ctte discussion, the goal of having reasonable team 
maintenance for python-defaults and python3-defaults has been met and further 
changes are not appropriate.

Scott K
P.S. Please cc me on related follow-ups as I'm not subscribed to the bug.

signature.asc
Description: This is a digitally signed message part.

Bug#573745: Things have changed significantly for the better

[Scott Kitterman]

Things are quite different now than they were 9 months ago when I got involved. 
 
They are significantly different now than when this bug was filed.

Other than the question of when to make the initial upload of a new version of 
the Python interpreter to Unstable, most of the issues at the core of this 
request have to do with maintenance of the core Python system in Debian and 
Python policy.  These are from python-defaults and python3-defaults.  Both of 
these packages are now maintained by three DDs in a public VCS.

I agree with the idea that maintenance of the interpreter packages should be 
broadened, but I think that the defaults packages which control 
default/supported versions and provide the Debian Python policy are the most 
important.

I believe it is fair to state that more has been done to improve the technical 
state of Python in Debian in the last 9 months than in the previous 4 years.

We are having a good discussion in the Debian Python community around what the 
Debian System for Python 3 will look like.  No one is imposing anything (look 
at the recent archives of debian-python for the discussion).

The history of Python in Debian is what it is, but I don't think that 
restructuring maintainership would solve any problems that we are actually 
having right now.

It seems to me that this request has evolved significantly.  Initially it was 
about broadening maintainership.  Now that this is happening, it seems to be 
just about getting doko fired.  I find that doko is perfectly willing to have 
reasonable discussions with people who are trying to work with him.  I don't 
find it a bit surprising that he doesn't place a priority on dealing with 
people who are not.  He's not always as responsive as I would like, but I'm 
not always as responsive as others would like either.  None of us has 
unlimited time.

As far as the Ubuntu versus Debian question, if you look at the python2.6 
history you will see that back in April doko switched back to having Debian 
uploads lead Ubuntu uploads and since then has uploaded python2.6 to Debian 9 
times.  Currently the package is maintained in Debian and then merged  with 
minor changes in Ubuntu.  This is another aspect of the original complaint 
that is, in my opinion, no longer valid (personally, I don't understand how 
one can simultaneously exult Debian as being more careful and having higher 
quality standards than Ubuntu and complain that everything that's in Ubuntu 
should also be in Debian at the same time, but regardless, it's OBE).

Scott K

P.S.  I am not subscribed to this bug, so if you want further comments from 
me, please cc me.


signature.asc
Description: This is a digitally signed message part.

Bug#573745: Things have changed significantly for the better

[Scott Kitterman]

On Monday, July 05, 2010 02:02:39 pm Clint Adams wrote:

 Why do you find this to be in any way a reasonable attitude to hold?

If people had asked to have me fired from a job I was doing (in Debian or 
elsewhere), you can be certain that sitting down and having a nice chat with 
them would be very low on my priority list.  I would focus my attention on 
people who were trying to work with me.  I believe that's human nature and it 
would be odd to expect anything else.

It would be different if I thought it was a situation where any compromise was 
possible.  I don't think it is in this case.  I may be wrong, but I don't see 
the requesters of this action being satisfied with any result where doko 
remains involved as a maintainer in Debian Python.

Scott K


signature.asc
Description: This is a digitally signed message part.

Re: Bug#573745: Things have changed significantly for the better

[Scott Kitterman]

On Monday, July 05, 2010 02:15:38 pm Sandro Tosi wrote:
 Hi Scott and others.
 
 On Mon, Jul 5, 2010 at 19:45, Scott Kitterman sc...@kitterman.com wrote:
  Things are quite different now than they were 9 months ago when I got
  involved. They are significantly different now than when this bug was
  filed.
  
  Other than the question of when to make the initial upload of a new
  version of the Python interpreter to Unstable, most of the issues at the
  core of this request have to do with maintenance of the core Python
  system in Debian and Python policy.  These are from python-defaults and
  python3-defaults.  Both of these packages are now maintained by three
  DDs in a public VCS.
  
  I agree with the idea that maintenance of the interpreter packages should
  be broadened, but I think that the defaults packages which control
  default/supported versions and provide the Debian Python policy are the
  most important.
 
 Indeed that changes a lot, and for the best, but we're not done yet, IMO.

Agreed.  As I said, I think maintenance of the interpreter packages should be 
broadened.  I don't see a problem with the level of maintenance they are 
getting right now, but for packages of this significance, having a single 
maintainer is not the best.

  I believe it is fair to state that more has been done to improve the
  technical state of Python in Debian in the last 9 months than in the
  previous 4 years.
 
 But it is also fair to state that this progress was possible mainly
 thanks to you, Piotr, and then to the debian-python community, and
 AFAICS in very minimal part (none?) from Matthias. Why is he still in
 a control position?

With respect to the defaults packages I don't think that is the case.  I agree 
maintainership of the interpreter packages should be broadened so that no one 
person can block things.

  We are having a good discussion in the Debian Python community around
  what the Debian System for Python 3 will look like.  No one is imposing
  anything (look at the recent archives of debian-python for the
  discussion).
 
 Sure, and doko took part in exactly zero discussions; is he sending
 his lieutenants in exploration and then have them report back to him
 and so decide what to do? /sarcasm Why is he still in a control
 position?

I'm not his lieutenant.  Who is in Uploaders versus Maintainers doesn't make a 
lot of difference.  If you'd be happier if we rearranged the names, I doubt it 
would be a problem.

  The history of Python in Debian is what it is, but I don't think that
  restructuring maintainership would solve any problems that we are
  actually having right now.
  
  It seems to me that this request has evolved significantly.  Initially it
  was about broadening maintainership.  Now that this is happening, it
  seems to be just about getting doko fired.
 
 Whatever the two, but I think that broadening the maintainership and
 keeps doko in, required in him to change his behavior; if that won't
 change, I don't know what other solutions there can be.

I would have expected you to be interested in communication with the set of 
maintainers.  I don't think you should really care among us which is the most 
communicative as long as the overall integration with the broader Debian 
Python community is good.

  I find that doko is perfectly willing to have
 
  reasonable discussions with people who are trying to work with him.  I
  don't find it a bit surprising that he doesn't place a priority on
  dealing with people who are not.
 
 Honestly? I think he is fine to have conversation with people that
 will obey to most of his will, and don't critics too much. When
 something differentiate from his thought he simply shut up, and
 continue on his way without listening. That Is The Problem. For
 example, and for the hundredth time, why he didn't write A SINGLE WORD
 here?

Don't assume that because I chose not to air disagreements in public, they 
don't happen.  You'd have to ask him why he hasn't commented here, I don't 
know.  I'm only commenting on this now because I was asked too.  I'd rather 
focus my limited time for Debian work on working on Python.

  He's not always as responsive as I would like, but I'm
 
  not always as responsive as others would like either.  None of us has
  unlimited time.
  
  As far as the Ubuntu versus Debian question, if you look at the python2.6
  history you will see that back in April doko switched back to having
  Debian uploads lead Ubuntu uploads and since then has uploaded python2.6
  to Debian 9 times.
  
  Currently the package is maintained in Debian and then merged  with
  minor changes in Ubuntu.  This is another aspect of the original
  complaint that is, in my opinion, no longer valid (personally, I don't
  understand how one can simultaneously exult Debian as being more careful
  and having higher quality standards than Ubuntu and complain that
  everything that's in Ubuntu should also be in Debian at the same time,
  but regardless

Bug#573745: Python Policy Update

[Scott Kitterman]

 Let us state it out loud: this was a huge achievement, and we're
 happy something has moved in the right direction; but please also note
 that the updated process was not lead by the current Python maintainer,
 but from (at that time) and external person, that only after his work
 gained the status of co-maintainer of python-defaults.

Since I'm that person, I'll comment on this.

First, I think it would have been silly to do a python-defaults upload just to 
add me to uploaders.  There was no point in uploading it until there was some 
worthwhile technical content to upload, so the entire business about being an 
external person is odd at best.  

Second, due to the unfortunate social history in Debian Python it was my 
belief then and now that the same policy update would have failed if Matthias 
were the lead for it.  It would be a mistake for anyone who didn't see all the 
various inputs to the update to make any assumptions about how much of the 
update was or was not influenced by any particular person.  

I know a lot of people don't like that much of the communication was in 
private, but I think it's better to have the update that we now have than to 
continue the previous gridlock.

With respect to:
 * There is no consensus on use of the XS-Python-Version header. The
Python maintainer promotes a current keyword, which several people
think has no semantical value.

This is resolved.  The current Python Policy says:
 The keyword current has been deprecated and used to mean that
 the package would only have to support a single version (even
 across default version changes).

It would be useful if the discussions about disagreements would focus on 
issues that have not already been resolved.

Scott K


signature.asc
Description: This is a digitally signed message part.