Hi Nilesh,
Am Tue, Mar 26, 2024 at 12:26:00AM +0530 schrieb Nilesh Patra:
> It is no secret that most (probably all?) teams (delegated and otherwise
> packaging/developer teams) in Debian struggle with limited
> developer time and almost everything in Debian needs help.
> In quite a few teams that I've seen and also been a part of, there
> are only 3-4 people sharing a bulk of workload, sometimes
> it is even worse and there are 1-person teams too -- teammetrics stats
> can shed some light on it[1].
Thanks for refering to teammetrics which is one of my pet projects on
one hand and an example for the problem on the other hand since I'm more
or less running it alone. In contrast to other more important 1-person
teams this is not a cruxial one, luckily. It also does not cut much
from my time since I don't to some development work in it - just keep up
and running what was done in a GSoC project.
> This imbalance can lead to exhaustion, burnouts, et. al. and having
> a low bus factor also poses an issue for stale packages/development
> in the corresponding teams when the people doing a lot of work
> there become busy with RL and can't dedicate much time.
I addressed this in paragraph "Building redundancy" of my platform (but
avoided the term "bus factor" using other known reasons for leaving the
project).
> Do you have any plans to address this or any strategies so the workload
> could be somewhat better managed making this sustainable?
I will try my best since I consider this a cruxial problem in Debian. I
personally see one tasks of the DPL to spot tasks in Debian that are not
sustainable in the sense you wrote and I'm happy about hints. My first
step would be to talk to those 1-person "teams". But the issue might be
complex and might be even caused by the volunteer based organisation of
Debian. Let me give two personal examples (none affecting really
critical things inside Debian).
Positive example: I'm extremely happy that the Debian Med team is
showing increased acticity by other team members after I nominated
myself for DPL. I consider this as great fruits of our cooperative work
to form a healthy team over 22 years and I'm really happy about this.
Regarding the 1-person teams I think step zero is that the single team
member admits that there is a problem. Example: Unfortunately in R pkg
team where I'm doing the vast amount of work this did not worked. My
mail where I admited to have no time[2] has lead to two further
confirmations of time constraints. But I think at least step zero is
done. (Advertising: Maintaining R packages is in most cases very easy.
The process to upgrade packages as well as to package dependencies is
de facto automated. If you are using R please join the team.)
In general I believe that a DPL is limited in effectiveness if people
don't to that step zero. It seems that within Debian, there are
individuals with exceptional technical skills who may also experience a
syndrome where they feel they are the sole individuals capable to do
certain tasks. This might make step one even harder: Document what you
are doing, seeking actively for more team members and teach them kindly.
This step is time-consuming, especially for individuals with significant
time constraints. Investing time without a clear vision of success poses
a challenge - ensuring that the new team member can effectively handle
the pending tasks while also committing to the role for a long time to
make it really sustainable.
I have no good ideas how to solve this dilemma inside our volunteer
organisation. I know that Freexian is paying people for LTS support.
This is nice. For the Etch release we had quite a discussion about
paying release managers. I know lots of pros and cons about paying
people from Debian funds. I think it is better if we could convince
companies to pay Debian developers and permit them to use their payed
time to spent on Debian tasks than paying single persons from Debian
funds. To give some example: The 32bit time_t 64bit transition is done
to support special hardware applications. Companies who are depending
from ARM 32bit support could hire people who care for ARM 32 ports
inside Debian. I consider this some win-win-situation.
It might be worth trying to browse the list "Who is using Debian"[3] to
explain those companies or the list of sponsors of DebConf, tell them
about issues we could fix if they would hire someone with the dedicated
job to work on this problem inside Debian.
BTW, I see jobs in Debian which are not tackled at all (=0-person
teams?). There could be somehow a team that works actively to speed up
Debian trends (thanks a lot to Lucas Nussbaum for maintaining this[4])
and work down the list of "code smells". I did so from time to time and
found:
1. Packages that show no visible sign of maintenance in need of
beeing salvaged[5]
2. Unattended but easy to fix bugs
3. Packages that could/should be probably be removed without harm
bu
