I'd like to officially contact all our teams to learn about potentialI don't think we do, I think it's all ad-hoc. There are some bug lists
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 orWe do not.
whatever
I have some specific questions to the Debian Python team. I'm really interested into individual answers from single contributors either hereYes.
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 itsNo idea if this question makes sense. I think most people just work on
members?
- 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<1
are working on your tasks in youre team? Does this fit the amount of
time you can really afford for this task?
- In the beginning of this year there was a change in the policy of DPT.It showed yet again that with any change, and equally lack of change, in
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.It's not transparent.
* What are your thoughts about the transition process?
* Can you identify some blockers?I have no idea.
* 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
- 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.)
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
Hi,Hi, could you please share the list of those? I have in mind six, mock,
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (3 / 13) |
Uptime: | 106:58:12 |
Calls: | 7,612 |
Calls today: | 3 |
Files: | 12,786 |
Messages: | 5,682,995 |
Posted today: | 2 |