Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #15905 > unrolled thread

Contacting DPT

Back to article view | Back to linux.debian.maint.python

Contents

  Contacting DPT Andreas Tille <tille@debian.org> - 2024-06-06 17:50 +0200
    Re: Contacting DPT Andrey Rakhmatullin <wrar@debian.org> - 2024-06-06 18:50 +0200
    Re: Contacting DPT Scott Kitterman <debian@kitterman.com> - 2024-06-07 06:10 +0200
      Re: Contacting DPT Emmanuel Arias <eamanu@debian.org> - 2024-06-11 21:30 +0200
    Re: Contacting DPT Alexandre Detiste <alexandre.detiste@gmail.com> - 2024-06-14 18:50 +0200
      Re: Contacting DPT Emmanuel Arias <eamanu@debian.org> - 2024-06-20 07:00 +0200
        Re: Contacting DPT Alexandre Detiste <alexandre.detiste@gmail.com> - 2024-06-20 07:10 +0200
    Re: Contacting DPT Louis-Philippe Véronneau <pollo@debian.org> - 2024-06-17 08:10 +0200

#15905 — Contacting DPT

[Multipart message — attachments visible in raw view] — view raw

Hi,

I'd like to officially contact all our teams to learn about potential
issues that might affect your work.  I would love to learn how you
organise / share your workload.  If you do some regular meetings - be it
on IRC, video conference or whatever I'm interested in joining one of
your next meetings.  I included individuel Uploaders of python3-defaults
package into this contact.  I'm aware that you are not necessarily
identify yourself as DPT members but I think this package is related
and I would love to see you as well in the DebConf BoF (see below) and
if you could also answer my questions below.

Like previous DPLs, I'm open to any inquiries or requests for
assistance. I personally prefer public discussion whenever possible, as
they can benefit a wider audience. You can find a list of contact
options at the bottom of my page on people.d.o[1].

I prefer being offline when I'm away from my keyboard, so I don't carry
a phone. In urgent situations, I can provide the number of my dumb
phone, though it may not always be within reach. Feel free to ping me
via email if I don't respond promptly to ensure I address your concerns.

Please let me know whether I can do something for you.  I'm fine joining
your IRC channel if needed but please invite me in case I should be
informed about some urgent discussion there since I normally do not lurk
on this channel.

I'd also like to inform you that I've registered a BoF for DebConf24 in
Busan with the following description:

  This BoF is an attempt to gather as much as possible teams inside
  Debian to exchange experiences, discuss workflows inside teams, share
  their ways to attract newcomers etc.

  Each participant team should prepare a short description of their work
  and what team roles (“openings”) they have for new contributors. Even
  for delegated teams (membership is less fluid), it would be good to
  present the team, explain what it takes to be a team member, and what
  steps people usually go to end up being invited to participate. Some
  other teams can easily absorb contributions from salsa MRs, and at some
  point people get commit access. Anyway, the point is that we work on the
  idea that the pathway to become a team member becomes more clear from an
  outsider point-of-view.

I'm sure not everybody will be able to travel this distance but it would
be great if you would at least consider joining that BoF remotely.  I'll
care for a somehow TimeZone aware scheduling - if needed we'll organise
two BoFs to match all time zones.  I'm also aware that we have pretty
different teams and it might make sense to do some infrastructure
related BoF with your team and other teams that are caring for Debian
infrastructure.

I have some specific questions to the Debian Python team.  I'm really
interested into individual answers from single contributors either here
on this list or in private.

  - Do you feel good when doing your work in Debian Python team?
  - Do you consider the workload of your team equally shared amongst its
    members?
  - Do you have some strategy to gather new contributors for your team?
  - Can you give some individual estimation how many hours per week you
    are working on your tasks in youre team?  Does this fit the amount of
    time you can really afford for this task?
  - I guess you will have your regular DPT meeting at DebConf (which I
    intend to join).  What do you think about the general team meeting
    I registered.
  - In the beginning of this year there was a change in the policy of DPT.
    I'd like to hear your opinion about:
     * The process how it went (possibly with suggestions to do better)
     * The final result after a couple of months
    (I'm specifically interested also in the opinion of people who were
     not happy about the change.)
  - Since a long time we try to migrate from Python3.11 to Python3.12.
     * What are your thoughts about the transition process?
     * Can you identify some blockers?
     * Do you have some suggestions for enhancements of this process?
  - Can I do anything for you?


Kind regards and thanks a lot for your work
   Andreas.


[1] https://people.debian.org/~tille/

-- 
https://fam-tille.de

[toc] | [next] | [standalone]

#15906

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jun 06, 2024 at 05:40:15PM +0200, Andreas Tille wrote:
> I'd like to officially contact all our teams to learn about potential
> issues that might affect your work.  I would love to learn how you
> organise / share your workload.
I don't think we do, I think it's all ad-hoc. There are some bug lists
in the IRC channel topic.

> If you do some regular meetings - be it on IRC, video conference or
> whatever 
We do not.

> I have some specific questions to the Debian Python team.  I'm really
> interested into individual answers from single contributors either here
> on this list or in private.
> 
>   - Do you feel good when doing your work in Debian Python team?
Yes.

>   - Do you consider the workload of your team equally shared amongst its
>     members?
No idea if this question makes sense. I think most people just work on
their own packages.

>   - Do you have some strategy to gather new contributors for your team?
No.

>   - Can you give some individual estimation how many hours per week you
>     are working on your tasks in youre team?  Does this fit the amount of
>     time you can really afford for this task?
<1

>   - In the beginning of this year there was a change in the policy of DPT.
>     I'd like to hear your opinion about:
>      * The process how it went (possibly with suggestions to do better)
>      * The final result after a couple of months
>     (I'm specifically interested also in the opinion of people who were
>      not happy about the change.)
It showed yet again that with any change, and equally lack of change, in
Debian there is a possibility that some people will resign.

>   - Since a long time we try to migrate from Python3.11 to Python3.12.
>      * What are your thoughts about the transition process?
It's not transparent. 

>      * Can you identify some blockers?
I have no idea.
I know many RC bugs are open but I don't know if any of them are blockers
and not things to be removed from testing.

>      * Do you have some suggestions for enhancements of this process?
If DPT is expected to be involved besides looking at the RC bug list at
the IRC channel topic, I would like to know how.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#15907

[Multipart message — attachments visible in raw view] — view raw

On Thursday, June 6, 2024 11:40:15 AM EDT Andreas Tille wrote:
>   - In the beginning of this year there was a change in the policy of DPT.
>     I'd like to hear your opinion about:
>      * The process how it went (possibly with suggestions to do better)
>      * The final result after a couple of months
>     (I'm specifically interested also in the opinion of people who were
>      not happy about the change.)

Personally, I found the entire exercise quite disappointing.  I sensed little 
to no interest from members of the team in trying to understand other 
perspectives on the proposed policy change.  It seemed to me to be an exercise 
in individuals trying to get what they thought best for themselves with little 
interest in the consequences of winning the argument.

Myself, I would have preferred not to change, but I don't find the change 
itself a major issue either way.  I am mostly disheartened by the lack of 
interest in trying to find consensus in the team (note that this lack of 
interest was not exclusively from one side of the discussion or the other, I 
think it was both).

As far as I can tell, they most concrete result is some people left the team.  
Some packages got picked up by other people, some packages were removed from 
the team, some packages were orphaned, and some packages were removed from 
Debian as a result.  Any benefit is theoretical as far as I can tell.

I have reduced my participation in the team.  I have been working my way 
through packages to see if I was working on them because I want to or because 
I thought I ought to as a part of being a good team member.  I have removed 
myself from uploaders, transferred packages to other uploaders, and orphaned 
several packages in the latter case.

If someone thinks this change helped anything, I'd be curious to see the data 
on that supports it.  Maybe I just missed it.

Scott K

[toc] | [prev] | [next] | [standalone]

#15908

[Multipart message — attachments visible in raw view] — view raw

Hi all!

On Fri, Jun 07, 2024 at 12:08:46AM -0400, Scott Kitterman wrote:
> On Thursday, June 6, 2024 11:40:15 AM EDT Andreas Tille wrote:
> >   - In the beginning of this year there was a change in the policy of DPT.
> >     I'd like to hear your opinion about:
> >      * The process how it went (possibly with suggestions to do better)
> >      * The final result after a couple of months
> >     (I'm specifically interested also in the opinion of people who were
> >      not happy about the change.)
> 
> Personally, I found the entire exercise quite disappointing.  I sensed little 
> to no interest from members of the team in trying to understand other 
> perspectives on the proposed policy change.  It seemed to me to be an exercise 
> in individuals trying to get what they thought best for themselves with little 
> interest in the consequences of winning the argument.
> 
> Myself, I would have preferred not to change, but I don't find the change 
> itself a major issue either way.  I am mostly disheartened by the lack of 
> interest in trying to find consensus in the team (note that this lack of 
> interest was not exclusively from one side of the discussion or the other, I 
> think it was both).
> 
> As far as I can tell, they most concrete result is some people left the team.  
> Some packages got picked up by other people, some packages were removed from 
> the team, some packages were orphaned, and some packages were removed from 
> Debian as a result.  Any benefit is theoretical as far as I can tell.

I was one of the people that accept the policy changes. At the beginning
IMO there were some movements en the packages, there were volunteers
picking orphaned packages, people left the team  as you mentioned, but
the team is working as was working before the policy change. I'm not
sure if the policy change had the effect that we expected.
> 
> I have reduced my participation in the team.  I have been working my way 
> through packages to see if I was working on them because I want to or because 
> I thought I ought to as a part of being a good team member.  I have removed 
> myself from uploaders, transferred packages to other uploaders, and orphaned 
> several packages in the latter case.
> 
> If someone thinks this change helped anything, I'd be curious to see the data 
> on that supports it.  Maybe I just missed it.
> 
> Scott K



-- 
cheers,
        Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eamanu@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1                     
 ⠈⠳⣄

[toc] | [prev] | [next] | [standalone]

#15925

Hi,

Le mer. 12 juin 2024 à 16:22, Thomas Goirand <thomas@goirand.fr> a écrit :
> On 6/6/24 17:40, Andreas Tille wrote:
> >    - Do you consider the workload of your team equally shared amongst its
> >      members?
>
> The team probably lacks organization, and there's no clear enough
> strategy for end goals.
>
> I know we're moving toward getting rid of:
> - six
> - mock
> - nose

 and unittest2,
 and zombie-imp,
 and 2to3,
 and cython3-legacy
 and m2r
 and mistune0
 and ...

Even only listing all of these on wiki with
what they could be replaced with would be good starter.

We could rely on the standard transition tracker to see what remains:
   https://release.debian.org/transitions/
or having those get from FTP-Masters an "oldlibs" overide.

I've my own tracker but it's mostly a toy I build to see what could be
done with UDD
and playing around with matplotlib.

An optimal moment to check whether these old dependencies
can be removed seems to be when a new upstream is available.

(m = mock, n=nose, s=six)
$ cat snap
androguard                     m         (depends on Java stuff..)
backblaze-b2                   m n s   (huge)
elasticsearch-curator          m n   (depends on new spun out library too ITP)
fabric                           n               (I tried)
heudiconv                      m            (attempted uploaded to experimental)
mu-editor                      m             (discussion on mailing
list about packaging style went nowhere)
pagure                         m   s

Now I think I could sort this by upstream release date & make an RSS
out of it ;-)


> but is anyone doing any type of coordination for the work to be done ?

I guess people being members of several Teams could give precious help.
I don't see myself pledging to join Teams just to remove
a handful lines from d/control files, and then be gone forever.

> It's been a waaaaay too long.
Agree

Greetings

[toc] | [prev] | [next] | [standalone]

#15954

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jun 14, 2024 at 06:41:58PM +0200, Alexandre Detiste wrote:
> Hi,
> 
> Le mer. 12 juin 2024 à 16:22, Thomas Goirand <thomas@goirand.fr> a écrit :
> > On 6/6/24 17:40, Andreas Tille wrote:
> > >    - Do you consider the workload of your team equally shared amongst its
> > >      members?
> >
> > The team probably lacks organization, and there's no clear enough
> > strategy for end goals.
> >
> > I know we're moving toward getting rid of:
> > - six
> > - mock
> > - nose
> 
>  and unittest2,
>  and zombie-imp,
>  and 2to3,
>  and cython3-legacy
>  and m2r
>  and mistune0
>  and ...
> 
> Even only listing all of these on wiki with
> what they could be replaced with would be good starter.
Hi, could you please share the list of those? I have in mind six, mock,
nose unittest2, 2to3 and cython3-legacy. If the team are OK I can update
the wiki with this information.

Cheers,

> 
> We could rely on the standard transition tracker to see what remains:
>    https://release.debian.org/transitions/
> or having those get from FTP-Masters an "oldlibs" overide.
> 
> I've my own tracker but it's mostly a toy I build to see what could be
> done with UDD
> and playing around with matplotlib.
> 
> An optimal moment to check whether these old dependencies
> can be removed seems to be when a new upstream is available.
> 
> (m = mock, n=nose, s=six)
> $ cat snap
> androguard                     m         (depends on Java stuff..)
> backblaze-b2                   m n s   (huge)
> elasticsearch-curator          m n   (depends on new spun out library too ITP)
> fabric                           n               (I tried)
> heudiconv                      m            (attempted uploaded to experimental)
> mu-editor                      m             (discussion on mailing
> list about packaging style went nowhere)
> pagure                         m   s
> 
> Now I think I could sort this by upstream release date & make an RSS
> out of it ;-)
> 
> 
> > but is anyone doing any type of coordination for the work to be done ?
> 
> I guess people being members of several Teams could give precious help.
> I don't see myself pledging to join Teams just to remove
> a handful lines from d/control files, and then be gone forever.
> 
> > It's been a waaaaay too long.
> Agree
> 
> Greetings
> 

[toc] | [prev] | [next] | [standalone]

#15956

Hi,

Le jeu. 20 juin 2024 à 06:50, Emmanuel Arias <eamanu@debian.org> a écrit :
> On Fri, Jun 14, 2024 at 06:41:58PM +0200, Alexandre Detiste wrote:
> > Le mer. 12 juin 2024 à 16:22, Thomas Goirand <thomas@goirand.fr> a écrit :
> > > I know we're moving toward getting rid of:
> > > - six
> > > - mock
> > > - nose
> >
> >  and unittest2,
> >  and zombie-imp,
> >  and 2to3,
> >  and cython3-legacy
> >  and m2r
> >  and mistune0
> >  and ...
> >
> > Even only listing all of these on wiki with
> > what they could be replaced with would be good starter.
> Hi, could you please share the list of those? I have in mind six, mock,
> nose unittest2, 2to3 and cython3-legacy.
>
> Cheers,

https://wiki.debian.org/Python/Dead%20Batteries

> If the team are OK I can update the wiki with this information.

It's a wiki ... I think anybody can improve it without asking permission.

The mail software didn't like my last email
with a tiny, monochrome, graphviz rendering in attachment.

I haven't figured out how to include images on the wiki yet.

Here's an online rendering:

https://dreampuf.github.io/GraphvizOnline/?compressed=CYSw5gTghgDgFgAggUwLYHsBuUA2BnBAbwCgEE8QAPUhDAYwGsaA7dPZGgL3VQCMRkAfRCoYCANo4ovZDgC8AIm58BAWhEwFAXRowAngGYAjACYJddDnQQ5kZMmY6yOELxMAXdAYlSZ8hR5e2jR0eu5w6MwGgjjIYFChPtKyiqHhkQaqsfGhwWSoIHjuAK7MyAAMNKgmEAg0pSDu7shFJjRWjABmILE0oEXF7j14NO2ugd6qAHwI%2BsZtZP0lQ-gI0wgubp4GLGzIazPK-EIaIWERUTFxCXoHCEcCwqK77HebE1WFJWXld6zsVRqdwKAx%2BZDI7XQXR6%2B3W-w4AF8gA

[toc] | [prev] | [next] | [standalone]

#15945

On 2024-06-06 11 h 40 a.m., Andreas Tille wrote:
>    - Do you feel good when doing your work in Debian Python team?

Yes.

>    - Do you consider the workload of your team equally shared amongst its
>      members?

No, and that's perfectly OK? Some people have more time to give than others.

>    - Do you have some strategy to gather new contributors for your team?

Not really, but I feel that's generally true for Debian at large :) I 
think joining an active team is an easier way to start packaging though.

>    - I guess you will have your regular DPT meeting at DebConf (which I
>      intend to join).  What do you think about the general team meeting
>      I registered.

I think it's a great idea and I'll be more than happy to join. I've 
heard great things about what other teams have been doing in terms of 
workflow and practices and I'd like to learn more.

I feel it would be really positive if we could try to work towards a 
more standardised set of "team practices" in Debian, to make the general 
packaging experience less chaotic.

>    - In the beginning of this year there was a change in the policy of DPT.
>      I'd like to hear your opinion about:
>       * The process how it went (possibly with suggestions to do better)
>       * The final result after a couple of months

I'm sad that some people left, but then again, I don't think a solution 
that suited everyone was possible.

I feel the status quo created a lot of tensions (especially for some 
newcomers who made honest mistakes) and as such, I don't think we 
could've reached a consensus and believe a vote was necessary.

>    - Since a long time we try to migrate from Python3.11 to Python3.12.
>       * What are your thoughts about the transition process?
>       * Can you identify some blockers?
>       * Do you have some suggestions for enhancements of this process?

I've said it many times but I really dislike transitions that are near 
the release freeze. It forces us into a crunch and I don't think that's 
healthy.

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web