Bits from DPL

[Martin-Éric Racine]

(non-subscriber; please keep me in CC whenever reply to this)

Attracting newcomers
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my
apologies for this. However, I want to revisit the sole question raised,
which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in
the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining
up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first
place.
My personal impression is that we sometimes fail to convey that Debian
is not just a product to download for free but also a technical
challenge that warmly invites participation. Everyone who respects our
Code of Conduct will find that Debian is a highly diverse community,
where joining the project offers not only opportunities for technical
contributions but also meaningful social interactions that can make the
effort and time truly rewarding.
In several of my previous talks (you can find them on my talks
page[mt4]--just search for "team," and don't be deterred if you see
"Debian Med" in the title; it's simply an example), I emphasized that
the interaction between a mentor and a mentee often plays a far more
significant role than the documentation the mentee has to read. The key
to success has always been finding a way to spark the mentee's interest
in a specific topic that resonates with their own passions.
From personal experience, jumping through hoops to become a DD, or

even just a DM, in a situation where I only maintain a handful of
packages and randomly contribute patches to other packages (or
overhaul the packaging before handing the package over to its next
maintainer) simply hasn't been worth the troubles. The key problem
precisely is that free software development is presented as technical
challenges to overcome. As amazing as it might sound, some of us would
rather focus on using the software for daily tasks and only resort to
packaging or patching code because we have an immediate need to
address so that we can move on with our life, and we just happen to be
using Debian on our hardware.

Martin-Éric

[Jeremy Stanley]

Post by Martin-Éric Racine
(non-subscriber; please keep me in CC whenever reply to this)

Attracting newcomers

[...]

Post by Martin-Éric Racine
From personal experience, jumping through hoops to become a DD, or
even just a DM, in a situation where I only maintain a handful of
packages and randomly contribute patches to other packages (or
overhaul the packaging before handing the package over to its next
maintainer) simply hasn't been worth the troubles.

[...]

I'll just say you're not alone. I've been around the Debian
community since pre-Y2K and, if I'd cared, could probably have been
a DD rather easily when the requirements were little more than say
'hi' and have enough DD signatures on your key. I've been
maintaining packaged software in Debian, albeit minimally, through
an uploading sponsor for about two decades. These days I'm on the
board of directors for SPI, but I'm still not a DD (nor even a DM).

Would I bother to go through NM now if the process were more
simplified/streamlined? Maybe, but probably not. As you noted,
priorities matter and it's entirely possible to be involved in
Debian without that (depending on what exactly you want to do of
course). There's quite a lot that doesn't require upload permissions
in the archive, and also quite a lot of amazing people with upload
permissions who are happy to help on the occasions it's needed.

[nick black]

Post by Jeremy Stanley
Would I bother to go through NM now if the process were more
simplified/streamlined? Maybe, but probably not. As you noted,
priorities matter and it's entirely possible to be involved in
Debian without that (depending on what exactly you want to do of
course). There's quite a lot that doesn't require upload permissions

i became a DD in 2022, and thought it overall a low-effort
process (it wasn't fast by any means, and getting
sponsors/endorsers was a kinda unpleasant bit of mendicancy, but
humility is endless). the actual application was entirely
asynchronous, and just a matter of reading some document and man
pages and distilling answers. i urge anyone reading this not to
let the ~8 hours required keep them from applying.

Post by Jeremy Stanley
in the archive, and also quite a lot of amazing people with upload
permissions who are happy to help on the occasions it's needed.

the personal appeal of uploading privileges is the ability to
work without a dependency on others, but it sounds like that's
not a motivator for you.

i do think current statistics wouldn't seem to capture
contributors like you, despite your (perhaps indirect) impact
being DD-comparable. still, this can't scale freely without a
bottleneck at DDs.

[Martin-Éric Racine]

Post by Jeremy Stanley

Post by Martin-Éric Racine
(non-subscriber; please keep me in CC whenever reply to this)

Attracting newcomers

[...]

Post by Martin-Éric Racine
From personal experience, jumping through hoops to become a DD, or
even just a DM, in a situation where I only maintain a handful of
packages and randomly contribute patches to other packages (or
overhaul the packaging before handing the package over to its next
maintainer) simply hasn't been worth the troubles.

[...]
I'll just say you're not alone. I've been around the Debian
community since pre-Y2K and, if I'd cared, could probably have been
a DD rather easily when the requirements were little more than say
'hi' and have enough DD signatures on your key.

The days when having enough signatures on your key and knowing Elmo on
IRC. I remember.

Post by Jeremy Stanley
Would I bother to go through NM now if the process were more
simplified/streamlined? Maybe, but probably not. As you noted,
priorities matter and it's entirely possible to be involved in
Debian without that (depending on what exactly you want to do of
course). There's quite a lot that doesn't require upload permissions
in the archive, and also quite a lot of amazing people with upload
permissions who are happy to help on the occasions it's needed.

The fallacy is to assume that just because someone contributed a
patch, their next step is to quit their dayjob and become a full-time
contributor. I keep on thinking of Con Kolivas, who contributed a very
popular Linux kernel patch while working as a paramedic. He didn't
quit his dayjob. Worse, once it became clear that his immensely
popular patch didn't fit the server-centric focus that prevailed on
the LKML back then, he stepped back from software development
altogether. I did something similar with Debian. I still primarily use
Debian, I still maintain a decreasing number of packages but,
otherwise, I really don't have the patience for ever trying NM again
and, quite frankly, I purposely keep my distances from Debian politics
and simply shake my head in disgust whenever yet another inconsiderate
decision impacts the life of rank-and-file users.

Martin-Éric

[Andrey Rakhmatullin]

Post by Martin-Éric Racine

Post by Jeremy Stanley
Would I bother to go through NM now if the process were more
simplified/streamlined? Maybe, but probably not. As you noted,
priorities matter and it's entirely possible to be involved in
Debian without that (depending on what exactly you want to do of
course). There's quite a lot that doesn't require upload permissions
in the archive, and also quite a lot of amazing people with upload
permissions who are happy to help on the occasions it's needed.

The fallacy is to assume that just because someone contributed a
patch, their next step is to quit their dayjob and become a full-time
contributor.

I don't think "get upload rights to do the same thing but in an easier
way" is related to what you wrote.

Though I can see a point in this: if you can upload directly, we
implicitly assume you also have sufficient knowledge to upload a correct
thing, and that requires being uptodate on requirements and practices.
(This is not true for many DDs, unfortunately, but it's implicitly
assumed)

This also reminded me of another assumed thing: when someone is a sole
maintainer of some package, we assume that that person cares about that
package, expect certain commitment from that person and raise certain
barriers between the package and other people. At the same time, many
maintainers who in your words did not "quit their dayjob and become a
full-time contributor" touch the package less often than expected and may
even discard and forget it, without doing any official steps to record
that fact in the project. This is sometimes a problem.

[Andreas Tille]

Post by Andrey Rakhmatullin
raise certain
barriers between the package and other people.

The current barrier appears to be the ITS procedure[1], which I now
engage with nearly daily through the "Bug of the Day"[2] workflow.
Previously, the requirement to wait 21+10 days (ITS waiting period +
delayed upload) deterred me from using this procedure. This delay
necessitates revisiting the issue multiple times and managing related
calendar entries, which can be burdensome. However, in the context of
"Bug of the Day", the regularity of the work has made it practical to
develop a workflow that accommodates these requirements, so it's now
manageable.

In my experience, more than 50% of ITS requests receive no response from
maintainers at any stage of the salvaging process. As a result, we have
effectively raised barriers for cases where maintainers have stopped
caring about their packages and failed to communicate this before
stepping away.

I wonder if we should reconsider the default assumption of package
ownership. Instead, we could introduce a file, such as
debian/dont_touch_my_package (or a similarly named file), where
maintainers can document their reasons for discouraging others from
uploading the package. This file could include a timestamp, and we could
establish an agreed-upon timeframe for refreshing the statement to
ensure its continued validity.

We could introduce this change starting with Debian Policy version X.
Maintainers who adopt this policy version by updating the
Standards-Version in their packages would implicitly agree that, in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

Do you think this would lower the barrier between a package and other
people?

Kind regards
Andreas.

[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks

[Richard Lewis]

Post by Andreas Tille
I wonder if we should reconsider the default assumption of package
ownership.

(This is a reas objective, but) i wasnt sure how the following text would
achieve the above)

Post by Andreas Tille
Instead, we could introduce a file, such as
debian/dont_touch_my_package (or a similarly named file), where
maintainers can document their reasons for discouraging others from
uploading the package. This file could include a timestamp, and we could
establish an agreed-upon timeframe for refreshing the statement to
ensure its continued validity.
Do you think this would lower the barrier between a package and other
people?

(I dont see why it would be any different than today -- people who write
the file can still lose interest/time and you will stil have to manage
your calendar).

Isnt the issue that debian's whole processes assume a "heroic"
maintainer who does all the work alone. That has advantages, but also
disadvantages if the hero disappears.

Maybe start with: how does a company/other distros organise its coding
teams? are there perhaps some things debian could learn?

[Andrey Rakhmatullin]

Post by Andreas Tille
I wonder if we should reconsider the default assumption of package
ownership. Instead, we could introduce a file, such as
debian/dont_touch_my_package (or a similarly named file), where
maintainers can document their reasons for discouraging others from
uploading the package. This file could include a timestamp, and we could
establish an agreed-upon timeframe for refreshing the statement to
ensure its continued validity.
We could introduce this change starting with Debian Policy version X.
Maintainers who adopt this policy version by updating the
Standards-Version in their packages would implicitly agree that, in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.
Do you think this would lower the barrier between a package and other
people?

This sounds like a basis for an actual solution but I don't think it can
work by itself, unless the timeframe is something like "you cannot touch
this in the next 2 weeks" and it's possible to refresh it without an
upload.

[Matthias Urlichs]

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

I like this idea.

The next step: agree on a "standard" Debian workflow and allow
(encourage?) people to convert existing packages to it (assuming that
the don't touch tag file is absent) ?

--
-- regards
--
-- Matthias Urlichs

[Jonas Smedegaard]

Quoting Matthias Urlichs (2024-12-12 08:57:57)

Post by Matthias Urlichs

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

I like this idea.
The next step: agree on a "standard" Debian workflow and allow
(encourage?) people to convert existing packages to it (assuming that
the don't touch tag file is absent) ?

Uhm, maybe that is implied by "next step", but just to be clear:

The proposal was to switch anyone-can-upload from opt-in to opt-out,
right?

Currently we have opt-in of anyone-can-upload for packages in the
collaborative debian section of salsa, but that does not imply that
anyone can do major restructuring of a package, which changes to
packaging workflow is.

Whichever step includes the new more aggressive attitude of permitting
major changes to a package without collaboration (or phrased nicer: with
only a system-wide "collaboration" of a standardization regime), please
state such evelation explicitly, so that when discussing we all agree on
what we are in fact discussing.

- Jonas

[Andrey Rakhmatullin]

Post by Jonas Smedegaard

Post by Matthias Urlichs

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

I like this idea.
The next step: agree on a "standard" Debian workflow and allow
(encourage?) people to convert existing packages to it (assuming that
the don't touch tag file is absent) ?

The proposal was to switch anyone-can-upload from opt-in to opt-out,
right?
Currently we have opt-in of anyone-can-upload for packages in the
collaborative debian section of salsa

(Which, to my knowledge, is not codified anywhere except some wiki page,
so it looks debatable to me how true is this)

[Holger Levsen]

Post by Matthias Urlichs

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

I like this idea.

so you like reality. good.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Reporter: You're the first person ever to win two Olympic tennis gold medals.
That's an extraordinary feat, isn't it?
Andy Murray: I think Venus and Serena have won about four each.

[Matthias Urlichs]

Post by Holger Levsen

Post by Matthias Urlichs

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

I like this idea.

so you like reality. good.

Did you ever see a bug (or require a feature), fix/add it, upload to
unstable, and immediately got reverted because the maintainer basically
didn't like it? (Assume for the sake of discussion that the issue in
question is older than a month or so, and has not gotten any feedback on
the bug tracker.)

No?

Lucky you, then.

--
-- regards
--
-- Matthias Urlichs

[Jonas Smedegaard]

Hi Matthias,

Quoting Matthias Urlichs (2024-12-15 06:33:35)

Post by Matthias Urlichs

Post by Holger Levsen

Post by Matthias Urlichs

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

I like this idea.

so you like reality. good.

Did you ever see a bug (or require a feature), fix/add it, upload to
unstable, and immediately got reverted because the maintainer basically
didn't like it? (Assume for the sake of discussion that the issue in
question is older than a month or so, and has not gotten any feedback on
the bug tracker.)

If you mean making an NMU that I felt so confident about that I released
it *without* prior warning in a bugreport - e.g. because I interpreted
older conversations in a bugreport as being in support of my (surprise)
move? Yes, I have experienced that, and after dusting off my immediate
reaction of self-rightousness, I felt foolish that I hadn't spent just a
minimal time probing ahead, instead of assuming that silence was in
indication of negligence.

If you mean first informing, then issuing an NMU, and then getting
reversal, then I cannot remember such incident - do you call that luck?
Do you mean to imply that overly silent maintainers are generally
non-cooperative, or what are you trying to say with your remark - which
I have trouble reading other than snarky (and I apologize ahead for
that, which in good faith gotta be a misreading).

- Jonas

[Sean Whitton]

Hello,

Post by Matthias Urlichs

in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

I like this idea.
The next step: agree on a "standard" Debian workflow and allow (encourage?)
people to convert existing packages to it (assuming that the don't touch tag
file is absent) ?

Let's discuss just one of these two highly controversial changes at
once.

[Gioele Barabucci]

Post by Andreas Tille
We could introduce this change starting with Debian Policy version X.
Maintainers who adopt this policy version by updating the
Standards-Version in their packages would implicitly agree that, in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.

Hi,

an alternative that I was thinking of, is making this "everybody is
onboard" policy more explicit by having a special email to use for the
Maintainer field. For example:

Maintainer: Debian community <debian-***@lists.debian.org>

The stewards of the package could be listed as Uploaders, as it
currently happens with team-maintained packages.

Lintian would then raise an error (not overridable for uploads) if the
Maintainer field is not set to a @{lists,tracker}.debian.org email AND
debian/dont_touch_my_package is not present with some text in it.

This would mimic what some maintainers are already doing today:
orphaning a package (i.e., setting its Maintainer address to
***@qa.debian.org), moving themselves to the Uploaders field and
then carrying on maintaining the package as part of the "QA Team"
(everybody is part of the QA Team...).

Regards,

[Soren Stoutner]

Attracting newcomers
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my
apologies for this. However, I want to revisit the sole question raised,
which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in
the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining
up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first
place.

I think one of the best things we could do to attract new contributors, and to
encourage those who are currently Sponsored Maintainers to become Debian
Maintainers, and those who are current Debian Maintainers to become Debian
Developers would be to create an official DPL Mentors Delegation. This would
build on the excellent work Phil Wyett is currently doing as the unofficial
Mentors Triage.

Too many contributors prepare a Debian package, submit it to Mentors, and then
never have it reviewed and sponsored by a Debian Developer. This can be
highly demotivating for the contributor. I think that having a team of Debian
Developers dedicated to reviewing every package submitted to Mentors would do
more to encourage more contributions to Debian, and more people becoming
Debian Maintainers and Debian Developers, than anything else I could name.

In my own case, I was lucky enough that my first contribution to Mentors caught
the eye of a Debian Developer who responded in a timely fashion and mentored
me through the process of getting the package into shape for sponsorship. At
the time, I assumed such a response was common for every submission. It was
only later that I discovered that my experience was the exception.

Shortly after becoming a Debian Developer, I tried to make a contribution to
Guix. With each submission, there was a long delay without any response.
Each person who did eventually respond suggested some change, which was
quickly made. However, the person making the suggestion then didn’t respond,
and much time passed before a different person responded with a different
suggestion. Eventually, I just gave up and the submission was never merged.

Unfortunately, I think that many contributor’s experiences with Debian are
closer to what I experienced with Guix than what I experienced with Debian.
If we can change that, I think we would see an influx of contributions to the
project.

[Antonio Russo]

Post by Soren Stoutner
Unfortunately, I think that many contributor’s experiences with Debian are
closer to what I experienced with Guix than what I experienced with Debian.
If we can change that, I think we would see an influx of contributions to the
project.

As a contributor who would like to contribute more, I can second (third?)
this. I am continually coming across minor-to-major problem which I
eventually resolve for myself. In the past, the difficulty of even getting
bug reports with patches that resolve issues to be looked at, much less
merged really wore on me.

My personal journey has been to establish pipelines to rebuild packages with
those fixes in them for myself and my family members. After getting those
issues diagnosed (a strict requirement), my top priority is now to maintain
those pipelines. From a "boundary setting" perspective, I limit my time
trying to communicate those fixes, either to Debian or further upstream.

Moreover, I'm increasingly of the opinion that fixes should only be presented
when they are both absolutely perfect for myself and from a software
engineering perspective, since it seems that even minor details will be
criticized, if the issues are even responded to at all. If projects don't
seem receptive, I often de-prioritize sending patches to them. Debian falls
into that category.

This means that some issues go years (and counting) without those fixes
merged. And my personal drive to get them merged is near-zero at this point,
since it doesn't really even benefit me personally.

I understand everyone is busy (as I am, too). But seeing contributions go
unacknowledged demoralizes people a lot.

Perhaps teams could start looking at human-contributed MRs and patch-tagged
bug reports that have been untouched for more than (say) 6 months? I haven't
mustered the care to try to send another RFS in over a year, but looking
at debian-mentors triage work recently, it seems like things might be
better.

Antonio

[Andreas Tille]

Post by Soren Stoutner
I think one of the best things we could do to attract new contributors, and to
encourage those who are currently Sponsored Maintainers to become Debian
Maintainers, and those who are current Debian Maintainers to become Debian
Developers would be to create an official DPL Mentors Delegation. This would
build on the excellent work Phil Wyett is currently doing as the unofficial
Mentors Triage.

Speaking both with and without my DPL hat, I don't think a delegation is
necessary. Instead, I would prefer to establish a way to direct sponsees
to the appropriate team for their package. From my experience, the teams
I work with are quite effective at sponsoring packages that fit their
scope and are maintained within the team's Git repository. I believe
that ensuring a package fits properly into a team is a key prerequisite
for a good sponsor-sponsee relationship.

When I was regularly monitoring ITPs, I noticed that newcomers often
struggle to "find friends" (i.e., sponsors). In my opinion, what we need
is someone to guide sponsees to the appropriate team, Salsa group, or
similar space. This role doesn't require a delegation since it doesn't
involve authority, but rather a deep understanding of Debian's structure
and workflows.

The downside of easing sponsorship without requiring team integration is
that we currently have a significant number of packages maintained by
individuals without a @debian.org address, many of which are slowly
bit-rotting. It's possible that these maintainers were unable to find
sponsors for subsequent uploads. However, the fact that I've filed
numerous ITS bugs for such packages without receiving any response
suggests that many maintainers have simply lost interest. I strongly
support simplifying the process to gain better oversight and control of
these packages, which is currently hindered by our strict interpretation
of package maintainer ownership.

Post by Soren Stoutner
Too many contributors prepare a Debian package, submit it to Mentors, and then
never have it reviewed and sponsored by a Debian Developer. This can be
highly demotivating for the contributor.

100% agreed.

Post by Soren Stoutner
I think that having a team of Debian
Developers dedicated to reviewing every package submitted to Mentors would do
more to encourage more contributions to Debian, and more people becoming
Debian Maintainers and Debian Developers, than anything else I could name.

As always: We need volunteers to do this and I agree that this would be
helpful.

Kind regards
Andreas.

[Soren Stoutner]

Post by Andreas Tille

Post by Soren Stoutner
I think one of the best things we could do to attract new contributors,

and

Post by Andreas Tille

Post by Soren Stoutner
to encourage those who are currently Sponsored Maintainers to become

Debian

Post by Andreas Tille

Post by Soren Stoutner
Maintainers, and those who are current Debian Maintainers to become Debian
Developers would be to create an official DPL Mentors Delegation. This
would build on the excellent work Phil Wyett is currently doing as the
unofficial Mentors Triage.

Speaking both with and without my DPL hat, I don't think a delegation is
necessary. Instead, I would prefer to establish a way to direct sponsees
to the appropriate team for their package. From my experience, the teams
I work with are quite effective at sponsoring packages that fit their
scope and are maintained within the team's Git repository. I believe
that ensuring a package fits properly into a team is a key prerequisite
for a good sponsor-sponsee relationship.
When I was regularly monitoring ITPs, I noticed that newcomers often
struggle to "find friends" (i.e., sponsors). In my opinion, what we need
is someone to guide sponsees to the appropriate team, Salsa group, or
similar space. This role doesn't require a delegation since it doesn't
involve authority, but rather a deep understanding of Debian's structure
and workflows.

I have directed several RFS (Request For Sponsor) towards appropriate teams,
when then exist. However, my personal experience is that the majority of RFS
that come into Debian Mentors do not fit neatly into any existing team.

[Andrey Rakhmatullin]

Post by Soren Stoutner
I have directed several RFS (Request For Sponsor) towards appropriate teams,
when then exist. However, my personal experience is that the majority of RFS
that come into Debian Mentors do not fit neatly into any existing team.

Yeah. We have a lot of leaf applications and so on that can't have a team.

[Andreas Tille]

Post by Andrey Rakhmatullin

Post by Soren Stoutner
I have directed several RFS (Request For Sponsor) towards appropriate teams,
when then exist. However, my personal experience is that the majority of RFS
that come into Debian Mentors do not fit neatly into any existing team.

Yeah. We have a lot of leaf applications and so on that can't have a team.

To be precise, we have both: packages that may not fit neatly into any
team, and many packages that align perfectly with existing teams, such
as the scientific team, games team, multimedia team, phototools team,
and others. I've moved many packages to these teams. Additionally, the
software in question is written in a specific programming language,
making it easier to find maintainers fluent in that language within the
dedicated language team. These maintainers can help with issues, or,
even better, the newcomer may contribute to resolving problems within
the language-specific team. I don't want to suggest that current team
members are eager for more work, but the potential for new, active team
members might be compelling enough to take on the responsibility of
sponsoring.

Kind regards
Andreas.

[Xiyue Deng]

Post by Andreas Tille

Post by Andrey Rakhmatullin

Post by Soren Stoutner
I have directed several RFS (Request For Sponsor) towards appropriate teams,
when then exist. However, my personal experience is that the majority of RFS
that come into Debian Mentors do not fit neatly into any existing team.

Yeah. We have a lot of leaf applications and so on that can't have a team.

To be precise, we have both: packages that may not fit neatly into any
team, and many packages that align perfectly with existing teams, such
as the scientific team, games team, multimedia team, phototools team,
and others. I've moved many packages to these teams. Additionally, the
software in question is written in a specific programming language,
making it easier to find maintainers fluent in that language within the
dedicated language team. These maintainers can help with issues, or,
even better, the newcomer may contribute to resolving problems within
the language-specific team. I don't want to suggest that current team
members are eager for more work, but the potential for new, active team
members might be compelling enough to take on the responsibility of
sponsoring.
Kind regards
Andreas.
--
https://fam-tille.de

Having a team to maintain a group of related packages is supposed to
improve velocity and usually works well. However there is a chance that
a team may be understuffed, both temporarily and gradually. I have
recently become a DM, so technically if my RFS bugs have been sponsored
I can work autonomously on those packages. Unfortunately my RFS bug
list is still growing[1] as my team becomes relatively less active
recently. I totally understand as this is voluntary work and people
have their lives to attend to (I do), and I am grateful for all comments
and sponsoring from my team. On the other hand, seeing my packages
being removed from mentors.d.n because of no sponsorship after 20 weeks
is also discouraging.

It would be great to have a group of DDs that are willing to regularly
check for RFS bugs / mentors.d.n and offer sponsorship, even for team
maintained packages. Some teams also maintain a team policy either on
wiki[2] or in a document in team repo, which can be a good guideline for
outside sponsors.

Just my 2 cents.

P.S. I would also like to take this chance to appreciate Phil Wyett's
automatic RFS checking that adds "confirmed" tag to RFS bugs that passed
the checks, which helps ensure a minimum quality of a prepared package
ready for sponsorship that can reduce the review rounds and potentially
save some time for potential sponsors.

[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sponsorship-requests&submitter=manphiz%40gmail.com
[2] https://wiki.debian.org/Teams/DebianEmacsenTeam

[Leandro Cunha]

Hi,

Post by Xiyue Deng
P.S. I would also like to take this chance to appreciate Phil Wyett's
automatic RFS checking that adds "confirmed" tag to RFS bugs that passed
the checks, which helps ensure a minimum quality of a prepared package
ready for sponsorship that can reduce the review rounds and potentially
save some time for potential sponsors.
[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sponsorship-requests&submitter=manphiz%40gmail.com
[2] https://wiki.debian.org/Teams/DebianEmacsenTeam
--
Regards,
Xiyue Deng

Look, he really deserves to become a Debian Developer, from what I see
he has been contributing to Debian for a while and now he is doing
this work and he has got 3 advocates. It would be very fair and I
agree with you.

https://lists.debian.org/debian-newmaint/2024/12/msg00006.html

[Phil Wyett]

Post by Leandro Cunha
Hi,

Post by Xiyue Deng
P.S. I would also like to take this chance to appreciate Phil Wyett's
automatic RFS checking that adds "confirmed" tag to RFS bugs that passed
the checks, which helps ensure a minimum quality of a prepared package
ready for sponsorship that can reduce the review rounds and potentially
save some time for potential sponsors.
[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sponsorship-requests&submitter=manphiz%40gmail.com
[2] https://wiki.debian.org/Teams/DebianEmacsenTeam
--
Regards,
Xiyue Deng

Look, he really deserves to become a Debian Developer, from what I see
he has been contributing to Debian for a while and now he is doing
this work and he has got 3 advocates. It would be very fair and I
agree with you.
https://lists.debian.org/debian-newmaint/2024/12/msg00006.html

Leandro,

Thank you for your support, but I would prefer to leave my DD application out of this discussion. Whatever happens
regarding that process it will not affect my contribution.

I hope to see some mentors contribution from yourself again in the near future. :-)

Regards

Phil
--
Donations...

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Liberapay: https://liberapay.com/kathenas

--

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Wiki: https://wiki.kathenas.org

Instagram: https://instagram.com/kathenasorg

Threads: https://www.threads.net/@kathenasorg

--

[Leandro Cunha]

Hi,

Post by Phil Wyett

Post by Leandro Cunha
Hi,

Post by Xiyue Deng
P.S. I would also like to take this chance to appreciate Phil Wyett's
automatic RFS checking that adds "confirmed" tag to RFS bugs that passed
the checks, which helps ensure a minimum quality of a prepared package
ready for sponsorship that can reduce the review rounds and potentially
save some time for potential sponsors.
[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sponsorship-requests&submitter=manphiz%40gmail.com
[2] https://wiki.debian.org/Teams/DebianEmacsenTeam
--
Regards,
Xiyue Deng

Look, he really deserves to become a Debian Developer, from what I see
he has been contributing to Debian for a while and now he is doing
this work and he has got 3 advocates. It would be very fair and I
agree with you.
https://lists.debian.org/debian-newmaint/2024/12/msg00006.html

Leandro,
Thank you for your support, but I would prefer to leave my DD application out of this discussion. Whatever happens
regarding that process it will not affect my contribution.
I hope to see some mentors contribution from yourself again in the near future. :-)

I'm just saying that I agree with him, and also taking the opportunity
to wish Phil Wyett good luck, and that more contributions from me
should appear soon.

I follow this list and the mentors, so it's not necessary to enter my
email and when reply with the list's email I should already receive it
here. No need to enter my email address.

I am also grateful for the reviews that were carried out by the Debian
Mentors list. I have already learned and continue to learn a lot
there. :)


--
Cheers,
Leandro Cunha

[Phil Wyett]

Post by Xiyue Deng

Post by Andreas Tille

Post by Andrey Rakhmatullin

Post by Soren Stoutner
I have directed several RFS (Request For Sponsor) towards appropriate teams,
when then exist. However, my personal experience is that the majority of RFS
that come into Debian Mentors do not fit neatly into any existing team.

Yeah. We have a lot of leaf applications and so on that can't have a team.

To be precise, we have both: packages that may not fit neatly into any
team, and many packages that align perfectly with existing teams, such
as the scientific team, games team, multimedia team, phototools team,
and others. I've moved many packages to these teams. Additionally, the
software in question is written in a specific programming language,
making it easier to find maintainers fluent in that language within the
dedicated language team. These maintainers can help with issues, or,
even better, the newcomer may contribute to resolving problems within
the language-specific team. I don't want to suggest that current team
members are eager for more work, but the potential for new, active team
members might be compelling enough to take on the responsibility of
sponsoring.
Kind regards
Andreas.
--
https://fam-tille.de

Having a team to maintain a group of related packages is supposed to
improve velocity and usually works well. However there is a chance that
a team may be understuffed, both temporarily and gradually. I have
recently become a DM, so technically if my RFS bugs have been sponsored
I can work autonomously on those packages. Unfortunately my RFS bug
list is still growing[1] as my team becomes relatively less active
recently. I totally understand as this is voluntary work and people
have their lives to attend to (I do), and I am grateful for all comments
and sponsoring from my team. On the other hand, seeing my packages
being removed from mentors.d.n because of no sponsorship after 20 weeks
is also discouraging.
It would be great to have a group of DDs that are willing to regularly
check for RFS bugs / mentors.d.n and offer sponsorship, even for team
maintained packages. Some teams also maintain a team policy either on
wiki[2] or in a document in team repo, which can be a good guideline for
outside sponsors.
Just my 2 cents.
P.S. I would also like to take this chance to appreciate Phil Wyett's
automatic RFS checking that adds "confirmed" tag to RFS bugs that passed
the checks, which helps ensure a minimum quality of a prepared package
ready for sponsorship that can reduce the review rounds and potentially
save some time for potential sponsors.
[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sponsorship-requests&submitter=manphiz%40gmail.com
[2] https://wiki.debian.org/Teams/DebianEmacsenTeam

Xiyue,

Many thanks for the kind words.

I agree a Mentors Group of DD's would be great. We must find motivated individuals and this is the age old struggle
for volunteer projects like Debian. I am hoping that contributors like yourself that have in real terms felt the
benefits of mentors become DM's and DD's then allocate some of your contribution time to mentors on a weekly or
monthly basis. This in turn I would hope over time add more contributors of all levels and we can maintain an active
group connected to teams etc. that would serve Debian well. Ever hopeful. :-)

Regards

Phil
--
Donations...

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Liberapay: https://liberapay.com/kathenas

--

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Wiki: https://wiki.kathenas.org

Instagram: https://instagram.com/kathenasorg

Threads: https://www.threads.net/@kathenasorg

--

[Andrey Rakhmatullin]

Post by Xiyue Deng
It would be great to have a group of DDs that are willing to regularly
check for RFS bugs / mentors.d.n and offer sponsorship

Sure. This is true since the beginning of the RFS process, and as nothing
stops people from doing this, but based on my observations such a group
was never larger than 1-3 people, just knowing that this is a good idea is
not enough.

[Sam Hartman]

Post by Xiyue Deng
It would be great to have a group of DDs that are willing to
regularly check for RFS bugs / mentors.d.n and offer sponsorship

Andrey> Sure. This is true since the beginning of the RFS process,
Andrey> and as nothing stops people from doing this, but based on my
Andrey> observations such a group was never larger than 1-3 people,
Andrey> just knowing that this is a good idea is not enough.

Perhaps sharing reasons why people don't do this would help us
understand what a change might look like.

For myself, my reasons for not being involved in RFS have varied across
my Debian Journey.

1) Right now, I am behind on Debian work I have committed to, and I'd
rather get that done than work on picking up new obligations.

2) Sponsoring a package if you do it right is a lot of work. If it is
going through new, it's really important that you review all the
copyright and license statements and make a determination about whether
it fits the DFSG. I firmly believe that work needs to be done by a DD
and should never be outsourced to someone who hasn't been trusted to do
that work by the project.
I hate doing that. tooling has made it easier over the years.

3) I think it is important to grab a pristine copy of the upstream
3) I think it's important to make sure that all changes are documented.
If not in Debian, that means going back to the upstream, grabbing
pristine upstream sources and diffing what is proposed at the upstream
source for Debian against those. If it is already in Debian, it means
effectively doing a debdiff between the version already in Debian and
the version proposed. The tooling for all that isn't great, and used to
be really bad.

4) At least back in the day there was an expectation that if you
sponsored a package you would test it. So it would involve learning how
to use the software and then testing to make sure it worked. Perhaps we
care about this less today.

5) At least back in the day there was an expectation that if you
sponsored an upload you would be available to sponsor any fixes to bugs
introduced in the upload.
For me, promising future availability was a big ask.

6) I felt there was an obligation to work with the person you were
sponsoring to get the package into shape. Sometimes that was a long
process. If they didn't have good email turn-around time I got into the
situation above where I had inadvertantly made a longer term commitment
than I was ready for.

There are many points in my Debian journey where if I could have made a
2-3 hour commitment to sponsoring packages without taking on future
responsibilities at future times, I would have been willing to do so.
(Not today unfortunately).
As I understand it there never has been (and is not today) a responsible
way to sponsor without at least taking on some chance of future
commitments.

[Andrey Rakhmatullin]

Post by Sam Hartman

Post by Xiyue Deng
It would be great to have a group of DDs that are willing to
regularly check for RFS bugs / mentors.d.n and offer sponsorship

Andrey> Sure. This is true since the beginning of the RFS process,
Andrey> and as nothing stops people from doing this, but based on my
Andrey> observations such a group was never larger than 1-3 people,
Andrey> just knowing that this is a good idea is not enough.
Perhaps sharing reasons why people don't do this would help us
understand what a change might look like.

Most of mine you already summarized below: even a package with perfect
debian/ requires quite a lot of effort and more mental work than e.g.
updating your own package so that you know what are you uploading; and
uploading once means the maintainer will likely ask you for other uploads
in the future and while that's totally correct from all points of view
it's additional potential burden (especially as I failed to review private
sponsorship requests in a reasonable time multiple times in the past).

[Phil Wyett]

Post by Andrey Rakhmatullin

Post by Sam Hartman

Post by Xiyue Deng
It would be great to have a group of DDs that are willing to
regularly check for RFS bugs / mentors.d.n and offer sponsorship

Andrey> Sure. This is true since the beginning of the RFS process,
Andrey> and as nothing stops people from doing this, but based on my
Andrey> observations such a group was never larger than 1-3 people,
Andrey> just knowing that this is a good idea is not enough.
Perhaps sharing reasons why people don't do this would help us
understand what a change might look like.

Most of mine you already summarized below: even a package with perfect
debian/ requires quite a lot of effort and more mental work than e.g.
updating your own package so that you know what are you uploading; and
uploading once means the maintainer will likely ask you for other uploads
in the future and while that's totally correct from all points of view
it's additional potential burden (especially as I failed to review private
sponsorship requests in a reasonable time multiple times in the past).

Morning Andrey,

You have been and are one of the guiding lights of Debian Mentors and other
areas of Debian. The time and effort you have devoted to the project should be
acknowledged and celebrated.

Your contribution in so many areas of Debian as a DD, you are always going to
eventually be spreading yourself too thin. We all sometimes miss things, not
follow up things and prove we are human.

I appreciate your work and the help you have given me. Thanks.

Regards

Phil
--
Donations...

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Liberapay: https://liberapay.com/kathenas

--

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Wiki: https://wiki.kathenas.org

Instagram: https://instagram.com/kathenasorg

Threads: https://www.threads.net/@kathenasorg

--

[Xiyue Deng]

Hi Sam,

Post by Sam Hartman

Post by Xiyue Deng
It would be great to have a group of DDs that are willing to
regularly check for RFS bugs / mentors.d.n and offer sponsorship

Andrey> Sure. This is true since the beginning of the RFS process,
Andrey> and as nothing stops people from doing this, but based on my
Andrey> observations such a group was never larger than 1-3 people,
Andrey> just knowing that this is a good idea is not enough.
Perhaps sharing reasons why people don't do this would help us
understand what a change might look like.
For myself, my reasons for not being involved in RFS have varied across
my Debian Journey.
1) Right now, I am behind on Debian work I have committed to, and I'd
rather get that done than work on picking up new obligations.
2) Sponsoring a package if you do it right is a lot of work. If it is
going through new, it's really important that you review all the
copyright and license statements and make a determination about whether
it fits the DFSG. I firmly believe that work needs to be done by a DD
and should never be outsourced to someone who hasn't been trusted to do
that work by the project.
I hate doing that. tooling has made it easier over the years.
3) I think it is important to grab a pristine copy of the upstream
3) I think it's important to make sure that all changes are documented.
If not in Debian, that means going back to the upstream, grabbing
pristine upstream sources and diffing what is proposed at the upstream
source for Debian against those. If it is already in Debian, it means
effectively doing a debdiff between the version already in Debian and
the version proposed. The tooling for all that isn't great, and used to
be really bad.
4) At least back in the day there was an expectation that if you
sponsored a package you would test it. So it would involve learning how
to use the software and then testing to make sure it worked. Perhaps we
care about this less today.
5) At least back in the day there was an expectation that if you
sponsored an upload you would be available to sponsor any fixes to bugs
introduced in the upload.
For me, promising future availability was a big ask.
6) I felt there was an obligation to work with the person you were
sponsoring to get the package into shape. Sometimes that was a long
process. If they didn't have good email turn-around time I got into the
situation above where I had inadvertantly made a longer term commitment
than I was ready for.
There are many points in my Debian journey where if I could have made a
2-3 hour commitment to sponsoring packages without taking on future
responsibilities at future times, I would have been willing to do so.
(Not today unfortunately).
As I understand it there never has been (and is not today) a responsible
way to sponsor without at least taking on some chance of future
commitments.

These are valid concerns. I think the tooling from Phil should help
with your point 2 and 3. For 4-6, I personally never expect the same DD
would provide long-term support after sponsoring. Maybe making that
clear on the Debian wiki[1] would help with aligning the expectations.

[1] https://wiki.debian.org/DebianMentorsFaq

[Mechtilde Stehmann]

Hello Phil,

Post by Xiyue Deng
Hi Sam,

As a none DD I do basic build testing and validation of packages and their
files in-order to bring them up to a minimum standard for a DD to then look at.
This is to encourage Debian Developers to review and sponsor packages in
mentors. A mentors package submission at the stage tagged 'confirmed' on the
RFS bug means it is decent shape and be less of a strain on a DD's time.
I use the sbuild using unshare[1] setup which can also run lintian, piuparts
and autopkgtest test when configured.

Can you provide a documentation of your configuration to do it.

I want to incluce it into the documentation at

salsa.debian.org/ddp-team/dpb.

I want to integrate it into the workflow described there.

Thank xou in advance

Regards

--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F

[Xiyue Deng]

Hi Phil,

[..snip..]
Morning Xiyue and all,
Xiyue mentions tooling after Sam raised an issue.
Xiyue, Many thanks for entering this conversation as I feel you are an ideal
person (through our many interactions) to detail/discuss what you feel mentors
is, is not, what is expected of the submitter and the reviewer; and what
mentors should be.
As a none DD I do basic build testing and validation of packages and their
files in-order to bring them up to a minimum standard for a DD to then look at.
This is to encourage Debian Developers to review and sponsor packages in
mentors. A mentors package submission at the stage tagged 'confirmed' on the
RFS bug means it is decent shape and be less of a strain on a DD's time.
I use the sbuild using unshare[1] setup which can also run lintian, piuparts
and autopkgtest test when configured.
pbuilder I have historically used in the same minimal build VM sbuild for build
after successful build tests.
We use 'licenserecon' command 'lrc' to do validation checking of 'd/copyright'.
This tool is new and improving. Manual checking are also used.
I do not use scripts or have it automated. I do these tests manually across two
laptops for each package I review. Automation and documentation is on the to-do
list.
My work on mentors is with primarily already available Debian tools and Visual
Studio Code. The key thing is the time I am fortunate to be able to give to
Debian due to my circumstances.
An expectation that once a DD does an upload for you, they are obligated to do
them for you from that point on I have seen in and around mentors. Unless a DD
specifically makes a commitment to a package, I believe that all package
uploads by a a DD are a one shot and there should be no expectation a DD will
be available to do it in the future. All submitters I feel should file an RFS
and an available DD can be canvassed for or waited for.
[1] https://wiki.debian.org/sbuild#Setup

Thanks for explaining your workflow in detail! I didn't realize this
also involves manual work, and my kudos for working on so many RFS bugs
nonetheless!

I think Phil's checking work provides many good feedback on many obvious
packaging issues, and once an RFS bug is confirmed, the package will be
in a sufficiently good shape for sponsoring. Any further issue may
require more domain knowledge and may be beyond the scope of automated
tools.

I'm really looking forward to see Phil continuing on automating and
documenting these tools. Once that happens, I wonder whether there
would be interest in making Phil's work a service on mentors.d.n or BTS
(like ***@d.o)? I think it would be a great addition to complement
local Lintian runs and Salsa CI.

Regard
Phil
--
Donations...
Buy Me A Coffee: https://buymeacoffee.com/kathenasorg
Liberapay: https://liberapay.com/kathenas
--
"I play the game for the game’s own sake"
Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans
--
Internet Relay Chat (IRC): kathenas
Matrix: #kathenas:matrix.org
Website: https://kathenas.org
Wiki: https://wiki.kathenas.org
Instagram: https://instagram.com/kathenasorg
--

[Sean Whitton]

Hello,

Post by Xiyue Deng
These are valid concerns. I think the tooling from Phil should help
with your point 2 and 3. For 4-6, I personally never expect the same DD
would provide long-term support after sponsoring. Maybe making that
clear on the Debian wiki[1] would help with aligning the expectations.
[1] https://wiki.debian.org/DebianMentorsFaq

Huh. This has always been my expectation. The sponsee is committing to
maintaining it through the end of the next stable release (as any
package maintainer does) and the DD is committing to reviewing and
sponsoring the uploads so it's actually possible for them to do that.

Of course, it's best effort as ever with volunteers, but that's not
nothing.

Teams are a bit different, I guess. But, for example when I said on
emacs-devel today that I could sponsor that C library you might be able
to help upload, I meant that it would be on a continuing basis.

It doesn't seem good for Debian, or the sponsee, for the DD to sponsor
it through NEW and then leave the sponsee in limbo.

[Xiyue Deng]

Hi Sean,

Post by Sean Whitton
Hello,

Post by Xiyue Deng
These are valid concerns. I think the tooling from Phil should help
with your point 2 and 3. For 4-6, I personally never expect the same DD
would provide long-term support after sponsoring. Maybe making that
clear on the Debian wiki[1] would help with aligning the expectations.
[1] https://wiki.debian.org/DebianMentorsFaq

Huh. This has always been my expectation. The sponsee is committing to
maintaining it through the end of the next stable release (as any
package maintainer does) and the DD is committing to reviewing and
sponsoring the uploads so it's actually possible for them to do that.
Of course, it's best effort as ever with volunteers, but that's not
nothing.

Thanks for your input! For sure if what-you-suggest happens on a
regular basis it would be great. I am just hoping to let perspective DD
sponsors have less concerns that we as sponsees don't necessarily want
to take even more of their previous free time for granted. I think for
general questions we can ask on debian-***@l.d.o or #debian-***@OFTC
(or the corresponding debian-mentors places) instead of relying on a
dedicated sponsor so as to lower their burden. All that is to make
perspective DD sponsors have less concerns to start reviewing and
sponsoring. As your said, "it's best effort as ever with volunteers."

Post by Sean Whitton
Teams are a bit different, I guess. But, for example when I said on
emacs-devel today that I could sponsor that C library you might be able
to help upload, I meant that it would be on a continuing basis.

Thanks for your support!

Post by Sean Whitton
It doesn't seem good for Debian, or the sponsee, for the DD to sponsor
it through NEW and then leave the sponsee in limbo.

Ack. I would also hope for the best.

Post by Sean Whitton
--
Sean Whitton

[Sam Hartman]

Xiyue> Thanks for your input! For sure if what-you-suggest happens
Xiyue> on a regular basis it would be great. I am just hoping to
Xiyue> let perspective DD sponsors have less concerns that we as
Xiyue> sponsees don't necessarily want to take even more of their
Xiyue> previous free time for granted.
I think we've uncovered a significant disconnect here, and I think
it would be well worth our time to explore this.
I'm not worried about a sponsees taking up my time.
I'm worried about the quality of the resulting Debian.

There's a presumption among older DDs that it's better not to have a
package in a release than to have a bad version (or a
even-older-than-stable-would-imply version) in a release.

If you buy into that, it's better for a package to get stuck before it
goes through new until the maintainer finds a consistent sponsor.
If the maintainer is not going to regularly be able to get their changes
sponsored, we'd rather not have it in Debian.

But from the sponsees's standpoint, if they get it in, they can start
getting feedback.
They are encouraged to contribute.
And perhaps the change will be small enough that even if the original
sponsor is not available someone else is.


I think it's worth digging into this area and asking questions like:

* Is Debian better off by making it easier to sponsor because that makes
it easier for Debian to grow?

* Should we have some way to remove packages (from releases if not
unstable) if they are not getting changes sponsored? How would we do
something like that without creating underground sponsorship requests?

--Sam

[Andreas Tille]

Post by Sean Whitton
It doesn't seem good for Debian, or the sponsee, for the DD to sponsor
it through NEW and then leave the sponsee in limbo.

Definitely. Finding a sponsor for the first upload but not for the
subsequent source-only upload might be something that does not sound
very probable but might happen. Not finding someone who might care
sponsoring a potential bug fix release is also something unfortunate.
I would at least expect the dedication of a team the sponsor belongs
to for at least a release time span.

Kind regards
Andreas.

[Simon Josefsson]

Post by Andreas Tille

Post by Soren Stoutner
I think one of the best things we could do to attract new contributors,

and

Post by Andreas Tille

Post by Soren Stoutner
to encourage those who are currently Sponsored Maintainers to become

Debian

Post by Andreas Tille

Post by Soren Stoutner
Maintainers, and those who are current Debian Maintainers to become Debian
Developers would be to create an official DPL Mentors Delegation. This
would build on the excellent work Phil Wyett is currently doing as the
unofficial Mentors Triage.

Speaking both with and without my DPL hat, I don't think a delegation is
necessary. Instead, I would prefer to establish a way to direct sponsees
to the appropriate team for their package. From my experience, the teams
I work with are quite effective at sponsoring packages that fit their
scope and are maintained within the team's Git repository. I believe
that ensuring a package fits properly into a team is a key prerequisite
for a good sponsor-sponsee relationship.
When I was regularly monitoring ITPs, I noticed that newcomers often
struggle to "find friends" (i.e., sponsors). In my opinion, what we need
is someone to guide sponsees to the appropriate team, Salsa group, or
similar space. This role doesn't require a delegation since it doesn't
involve authority, but rather a deep understanding of Debian's structure
and workflows.

I have directed several RFS (Request For Sponsor) towards appropriate teams,
when then exist. However, my personal experience is that the majority of RFS
that come into Debian Mentors do not fit neatly into any existing team.

I suspect the RFS process would be more successful in finding a sponsor
if the requests went to debian-devel rather than another opt-in mailing
list. I rarely go looking for more work to do by viewing

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;dist=unstable

so I would never find a RFS unless someone ping'ed a packaging group
that I'm part of to help. The noise level of debian-devel would go up,
but if we collectively find RFS being ignored a serious problem, then
maybe making noise about a serious problem is a good idea.

FWIW, I took a look at the RFS list now for writing this e-mail and
found "libunistring" which is an important library that I know
relatively well, and build-depend on for libidn2, and would be happy to
review and help work on it. Hopefully I'll manage to review and upload
it. So this being brought up on debian-devel did nudge me into looking
for things to help with.

/Simon

[Andrey Rakhmatullin]

Post by Simon Josefsson
I suspect the RFS process would be more successful in finding a sponsor
if the requests went to debian-devel rather than another opt-in mailing
list. I rarely go looking for more work to do by viewing
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;dist=unstable
so I would never find a RFS unless someone ping'ed a packaging group
that I'm part of to help.

Do you think people who aren't interested in reviewing or sponsoring
random packages and so don't go to the link you provided will sometimes
sponsor some package they noticed on d-devel@? Or how should this change
increase the sponsorship rate?

Post by Simon Josefsson
The noise level of debian-devel would go up, but if we collectively find
RFS being ignored a serious problem, then maybe making noise about a
serious problem is a good idea.

Not sure if this is correct reasoning. We, the project, likely find RFS
being ignored a serious problem, but Constitution 2.1.1 doesn't leave us
with many tools to solve it. OTOH if some DD personally finds this a
serious problem and wants to solve it they should go to the BTS link you
provided and do reviews/sponsoring (though if you want to do the former
without the latter consider
https://lists.debian.org/debian-mentors/2024/07/msg00164.html). This may
also be useful experience for learning more about the problem and its
causes.

[Simon Josefsson]

Post by Andrey Rakhmatullin

Post by Simon Josefsson
I suspect the RFS process would be more successful in finding a sponsor
if the requests went to debian-devel rather than another opt-in mailing
list. I rarely go looking for more work to do by viewing
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;dist=unstable
so I would never find a RFS unless someone ping'ed a packaging group
that I'm part of to help.

Do you think people who aren't interested in reviewing or sponsoring
random packages and so don't go to the link you provided will sometimes
increase the sponsorship rate?

This is anedoctal, but in the last month pinging debian-devel (as in
this thread) or debian-go led to me uploading the following RFS's:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087286
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086872
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087604
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087183

I would not have gone looking for these RFS's without those ping's,
since I'm not interested in RFS's as a general way to find new things to
work on. But after seeing the ping's I decided to help on packages that
happened to be some that I had some familiarity with already. So at
least for these packages, ping's did increase the sponsorship rate.

/Simon

[Andreas Tille]

Post by Simon Josefsson
But after seeing the ping's I decided to help on packages that
happened to be some that I had some familiarity with already. So at

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Post by Simon Josefsson
least for these packages, ping's did increase the sponsorship rate.

That's exactly my point and I wished we could do this less randomly.

Kind regards
Andreas.

[rhys]

Post by Andreas Tille
When I was regularly monitoring ITPs, I noticed that newcomers often
struggle to "find friends" (i.e., sponsors). In my opinion, what we need
is someone to guide sponsees to the appropriate team, Salsa group, or
similar space. This role doesn't require a delegation since it doesn't
involve authority, but rather a deep understanding of Debian's structure
and workflows.

Is this sort of thing documented anywhere?

It's not the sort of thing that needs to be strictly updated like a man page or other technical document. It just needs to be a couple of pages that describe the "general" (big picture structure an workflows) to get that established as a reference and then some of the "specifics" for at least the larger teams who have workflows more complex than "apt info package | grep -i maintain".

Not only would it help outsiders and newbies get a feel for how things work, but it would create visibility among the existing teams and allow them to compare and contrast their workflows (with some mentions of "different != bad").

"Best effort" solutions are often quite effective where "people problems" are concerned.

--J

[Andreas Tille]

Hi,

Post by rhys

Post by Andreas Tille
When I was regularly monitoring ITPs, I noticed that newcomers often
struggle to "find friends" (i.e., sponsors). In my opinion, what we need
is someone to guide sponsees to the appropriate team, Salsa group, or
similar space. This role doesn't require a delegation since it doesn't
involve authority, but rather a deep understanding of Debian's structure
and workflows.

Is this sort of thing documented anywhere?

I wouldn't call this a "good documentation" but this page might be a
sensible start:

https://wiki.debian.org/Teams/

Post by rhys
It's not the sort of thing that needs to be strictly updated like a man page or other technical document. It just needs to be a couple of pages that describe the "general" (big picture structure an workflows) to get that established as a reference and then some of the "specifics" for at least the larger teams who have workflows more complex than "apt info package | grep -i maintain".
Not only would it help outsiders and newbies get a feel for how things work, but it would create visibility among the existing teams and allow them to compare and contrast their workflows (with some mentions of "different != bad").

IMHO the most natural thing to seek for friends is looking for packages
with functionality covering a similar use case or written in the same
programming language. Than you do

apt showsrc similar_package(s) | grep ^Maintainer

and if you are lucky you have found some friends.

Kind regards
Andreas.

[Ahmad Khalifa]

Post by Andreas Tille

Post by rhys
It's not the sort of thing that needs to be strictly updated like a man page or other technical document. It just needs to be a couple of pages that describe the "general" (big picture structure an workflows) to get that established as a reference and then some of the "specifics" for at least the larger teams who have workflows more complex than "apt info package | grep -i maintain".
Not only would it help outsiders and newbies get a feel for how things work, but it would create visibility among the existing teams and allow them to compare and contrast their workflows (with some mentions of "different != bad").

IMHO the most natural thing to seek for friends is looking for packages
with functionality covering a similar use case or written in the same
programming language. Than you do
apt showsrc similar_package(s) | grep ^Maintainer
and if you are lucky you have found some friends.

As an outsider trying to help, the natural thing I looked at was the RFH
process to dip my toes into things.
But only 56 packages have RFH bugs and they're usually not very clear on
what help they need. And most of those were requested >1 year ago.
No one needed help in 2024 or it was answered and closed quickly.

Perhaps encouraging overwhelmed maintainers to delegate more with RFH or
even RFH before orphaning. Maybe that could bring more people in?

And side note, there is almost a document or example for everything I
needed to get me to the RFS stage, I was pretty happy with all of it.

[Sean Whitton]

Hello,

Post by Ahmad Khalifa
As an outsider trying to help, the natural thing I looked at was the RFH
process to dip my toes into things.
But only 56 packages have RFH bugs and they're usually not very clear on what
help they need. And most of those were requested >1 year ago.

They are usually still valid. I have one from last year and I would
still like help.

[Ahmad Khalifa]

Post by Sean Whitton

Post by Ahmad Khalifa
As an outsider trying to help, the natural thing I looked at was the RFH
process to dip my toes into things.
But only 56 packages have RFH bugs and they're usually not very clear on what
help they need. And most of those were requested >1 year ago.

They are usually still valid. I have one from last year and I would
still like help.

I'm sure they are. My experience was looking at one of the big packages
at the top, it only had 2 bugs and but both were fixed and not tagged.
To an outsider it may look like everything is done.

Then I looked at imagemagick's d/ source and then closed the browser tab
(too advanced :)

[Richard Lewis]

Post by Soren Stoutner

Attracting newcomers
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my
apologies for this. However, I want to revisit the sole question raised,
which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in
the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining
up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first
place.

I think one of the best things we could do to attract new contributors, and to
encourage those who are currently Sponsored Maintainers to become Debian
Maintainers, and those who are current Debian Maintainers to become Debian
Developers would be to create an official DPL Mentors Delegation.

I dont disagree with anything you wrote, but i think people are looking
at "Needs a DD to make the process work" and assuming that the only
solution is to increase the number of DDs. But the process itself can
also be changed.

at least some of the feedback so far is that people want to contribute
without having to be a DD

[Soren Stoutner]

Post by Richard Lewis

Post by Soren Stoutner

Attracting newcomers
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my
apologies for this. However, I want to revisit the sole question raised,
which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in
the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining
up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first
place.

I think one of the best things we could do to attract new contributors,

and

Post by Richard Lewis

Post by Soren Stoutner
to encourage those who are currently Sponsored Maintainers to become

Debian

Post by Richard Lewis

Post by Soren Stoutner
Maintainers, and those who are current Debian Maintainers to become Debian
Developers would be to create an official DPL Mentors Delegation.

I dont disagree with anything you wrote, but i think people are looking
at "Needs a DD to make the process work" and assuming that the only
solution is to increase the number of DDs. But the process itself can
also be changed.
at least some of the feedback so far is that people want to contribute
without having to be a DD

That is true. Not everyone who wants to contribute to Debian would like to
become a Debian Maintainer or a Debian Developer. And we want to make sure
that we always have a welcoming environment for such contributions.

But my personal experience working with people making contributions to Debian
Mentors is that more than half of them do have interest in becoming a Debian
Maintainer or a Debian Developer, but are stymied in the process along the
way. When thinking about increasing the number of Debian Developers, I
consider these people to be the low-hanging fruit. They have already
expressed a desire to contribute to Debian. They have already put forth
enough effort to do some level of packaging and upload it to
mentors.debian.net. They often need some further technical guidance (I
certainly did). But it would take a lot less effort to get them over the hump
than it would to start fresh with someone who has no exposure to Debian, which
is where it seems that the majority of our recruitment efforts focus.

[Robert Chéramy]

Note - This email was originally send directly to Andreas Tille, as my
MUA ignored his "Mail-Followup-To: header".
Andreas asked me to answer to debian-***@lists.debian.org. Please note
that I have not subscribed to debian-devel and do not plan to subscribe
at the moment. If you want me to read your answer or to clarify a point,
please take me on Cc:.


Hi Andreas,

I'm not sure if you are looking for feedback on attracting newcomers. I
was tempted to answer the last "Bits from the DPL", and as the topic
comes up again in this new "Bits from the DPL", so here you are. If you
are not looking for feedback - just ignore this email, I won't be
offended 😉

I am not a Debian developer, but tried twice to package software into
debian.
I've already done some debian packaging as a developer
(https://metadata.ftp-master.debian.org/changelogs//main/i/ipfm/ipfm_0.11.5-4.3_changelog)
and I would  describe my debian skills as an admin/user as quite good. I
have been using Debian as my primary desktop and for servers for about
25 years. I'm not an English native speaker, and I hope my email is
clear enough and not too hard to read.

My last attempt was about two years ago. I wanted to package gns3 and
relevant tools. Here is my experience.


1) Documentation
There was a lot of reading involved (no problem here - it is great to
have a detailed documentation) but it was very confusing that there were
different guides addressing the same things:

Debian Developper's Reference
   - https://www.debian.org/doc/manuals/developers-reference/index.en.html
   - More the organizational aspects - OK, no problem here.

Then three different guides which cover more or less the same topics and
reference to each other and are/were partially outdated:
- Debian New Maintainer's Guide
https://www.debian.org/doc/manuals/maint-guide/index.en.html
- Guide for Debian Maintainers
https://www.debian.org/doc/manuals/debmake-doc/index.en.html
- Debian Policy Manual https://www.debian.org/doc/debian-policy/

This is not good. Debian packaging is quite overwhelming and difficult
to learn for a newcomer, in particular when he wants to build a package
from scratch (which may not the best way to start). Having three
different Manuals do not help. At least the "Debian New Maintainer's
Guide" should completely be removed from debian.org.


2) What should I read first if I want to make a new package?

When I read https://www.debian.org/devel/join/index.en.html, I miss a
link to the Debian Developper's Reference and the Guide for Debian
Maintainers or the Debian Policy Manual.

I read that I should subscribe to a lot of mailing lists, work on
work-needing packages, do secondary tasks (docs, website, translation,
QA), but nothing about how I can start the rough path to make a debian
package.

Even in https://www.debian.org/devel/join/newmaint , I do not find a
link to a documentation on how to make a package.

Sure, I will finally land on on of the three documents above. With some
bad luck, I will land on the (old) "Debian New Maintainer's Guide".



3) Salsa
It is not clear to me if salsa is exclusive for DD or open to anyone.
https://www.debian.org/devel/join/newmaint.en.html states "prospective
Debian Developers" should create an account.

My understanding is that salsa should be open for everyone, like in
github. If I have a problem with a debian package, I would like to fork
it on salsa, patch it an submit a PR. I don't have to be a debian
developper for this and it could be a great entry point for potential
developers.

It probably is. Just write it explicitly on:
- https://www.debian.org/devel/join/newmaint
- https://wiki.debian.org/Salsa
- https://www.debian.org/doc/manuals/debmake-doc/ch10.en.html#salsa-repo



4) Localization on www.debian.org
I live in Germany, and was born in France, so my language preference in
firefox is de > fr > en.
When I visit debian.org, I get it in German. So far, so good.
When working in an English context, I prefer using the document in
English (for example in order to write this email).
I choose "English" at the bottom of debian.org and get the page in
English. So far, so good

When I click on most of the links, I get the generic URL and not the
localized one (index.en.html). So I'm back to German and have to choose
English manually or in some docs (developers-reference / debian-policy)
I must click on a link, manually replace ".de." into ".en." in the URL,
and click on the home of the document). This is very annoying and make
the process of learning how to package harder than it could be.

Sure, I could read it in German, change my browser preferences or use
Chrome with English preferences. It's just one more challenge in the way.



With these difficulties plus the constant need of prioritizing my time,
I ended in installing gns3 with `pip install` and pushing my next time
trying to package something for debian (doing the things right) in some
future day. I probably did not tried hard enough, or the challenges
along the way were too big for the effort I was ready to invest in it at
the time. I work on other open source projects where the entry barrier
was lower.

Debian is still a matter of the heart to me, and it was important enough
to me to take the time to write this email even if I don't know if it
will land in your trash 😉. I will probably try the process again in a
few years. In the meantime, I hope that my feedback can help Debian to
somehow flatten the path for new developers.


Keep on the good work!


Robert

Attracting newcomers
--------------------
In my own talk[mt3], I regret not leaving enough time for questions--my
apologies for this. However, I want to revisit the sole question raised,
which essentially asked: Is the documentation for newcomers sufficient
to attract new contributors? My immediate response was that this
question is best directed to new contributors themselves, as they are in
the best position to identify gaps and suggest improvements that could
make the documentation more helpful.
That said, I'm personally convinced that our challenges extend beyond
just documentation. I don't get the impression that newcomers are lining
up to join Debian only to be deterred by inadequate documentation. The
issue might be more about fostering interest and engagement in the first
place.
My personal impression is that we sometimes fail to convey that Debian
is not just a product to download for free but also a technical
challenge that warmly invites participation. Everyone who respects our
Code of Conduct will find that Debian is a highly diverse community,
where joining the project offers not only opportunities for technical
contributions but also meaningful social interactions that can make the
effort and time truly rewarding.
In several of my previous talks (you can find them on my talks
page[mt4]--just search for "team," and don't be deterred if you see
"Debian Med" in the title; it's simply an example), I emphasized that
the interaction between a mentor and a mentee often plays a far more
significant role than the documentation the mentee has to read. The key
to success has always been finding a way to spark the mentee's interest
in a specific topic that resonates with their own passions.
Bug of the Day
--------------
In my presentation[mt3], I provided a brief overview of the Bug of the
Day initiative, which was launched with the aim of demonstrating how to
fix bugs as an entry point for learning about packaging. While the
current level of interest from newcomers seems limited, the initiative
has brought several additional benefits.
I must admit that I'm learning quite a bit about Debian myself. I often
compare it to exploring a house's cellar with a flashlight--you uncover
everything from hidden marvels to things you might prefer to discard.
I've also come across traces of incredibly diligent people who have
invested their spare time polishing these hidden treasures (what we call
NMUs). The janitor, a service in Salsa that automatically updates
packages, fits perfectly into this cellar metaphor, symbolizing the
ongoing care and maintenance that keep everything in order. I hadn't
realized the immense amount of silent work being done behind the
scenes--thank you all so much for your invaluable QA efforts.

[Andrey Rakhmatullin]

Post by Robert Chéramy
1) Documentation
There was a lot of reading involved (no problem here - it is great to have a
detailed documentation) but it was very confusing that there were different
Debian Developper's Reference
   - https://www.debian.org/doc/manuals/developers-reference/index.en.html
   - More the organizational aspects - OK, no problem here.
Then three different guides which cover more or less the same topics and
- Debian New Maintainer's Guide
https://www.debian.org/doc/manuals/maint-guide/index.en.html
- Guide for Debian Maintainers
https://www.debian.org/doc/manuals/debmake-doc/index.en.html
- Debian Policy Manual https://www.debian.org/doc/debian-policy/

There is a big dfference between the Policy and any other guide. The
Policy is not a guide but a normative document.
As for maint-guide and debmake-doc, there are indeed several big problems
around them. An IMO neither are enough to learn basic packaging.

Post by Robert Chéramy
2) What should I read first if I want to make a new package?
When I read https://www.debian.org/devel/join/index.en.html

This link is not among answers to this question. This is the reason for
the confusion you describe below.
The correct answer to this question is
https://mentors.debian.net/intro-maintainers/

Post by Robert Chéramy
, I miss a link
to the Debian Developper's Reference and the Guide for Debian Maintainers or
the Debian Policy Manual.
I read that I should subscribe to a lot of mailing lists, work on
work-needing packages, do secondary tasks (docs, website, translation, QA),
but nothing about how I can start the rough path to make a debian package.
Even in https://www.debian.org/devel/join/newmaint , I do not find a link to
a documentation on how to make a package.
Sure, I will finally land on on of the three documents above. With some bad
luck, I will land on the (old) "Debian New Maintainer's Guide".
3) Salsa
It is not clear to me if salsa is exclusive for DD or open to anyone.
https://www.debian.org/devel/join/newmaint.en.html states "prospective
Debian Developers" should create an account.

This, again, is a wrong doc and it provided you a wrong perspective.

Post by Robert Chéramy
My understanding is that salsa should be open for everyone, like in github.

It is.

Post by Robert Chéramy
If I have a problem with a debian package, I would like to fork it on salsa,
patch it an submit a PR.

Sometimes you can, sometimes you cannot, and this is cannot be fixed at
the current state of the project.
So we cannot document that you always can.

Post by Robert Chéramy
4) Localization on www.debian.org
I live in Germany, and was born in France, so my language preference in
firefox is de > fr > en.
When I visit debian.org, I get it in German. So far, so good.
When working in an English context, I prefer using the document in English
(for example in order to write this email).
I choose "English" at the bottom of debian.org and get the page in English.
So far, so good
When I click on most of the links, I get the generic URL and not the
localized one (index.en.html). So I'm back to German and have to choose
English manually or in some docs (developers-reference / debian-policy) I
must click on a link, manually replace ".de." into ".en." in the URL, and
click on the home of the document). This is very annoying and make the
process of learning how to package harder than it could be.
Sure, I could read it in German, change my browser preferences or use Chrome
with English preferences. It's just one more challenge in the way.

Yes. I gave up on this years ago. Apparently it works as intended.

Post by Robert Chéramy
With these difficulties plus the constant need of prioritizing my time, I
ended in installing gns3 with `pip install` and pushing my next time trying
to package something for debian (doing the things right) in some future day.

Makes total sense.

Post by Robert Chéramy
I probably did not tried hard enough, or the challenges along the way were
too big for the effort I was ready to invest in it at the time. I work on
other open source projects where the entry barrier was lower.

Yeah.

[Soren Stoutner]

Robert,

I appreciate your addition to the discussion.

Post by Robert Chéramy
1) Documentation
There was a lot of reading involved (no problem here - it is great to
have a detailed documentation) but it was very confusing that there were

In my initial email I didn’t address the topic of documentation, but it is an
important aspect that deserves consideration.

My personal experience in beginning to contribute to Debian involved me
reading over the documentation for a period of three months before beginning
to do any work on a package. I found the documentation to be suboptimal for
two main reasons.

1. There is currently no canonical packaging workflow in Debian I didn’t even
realize how much of a problem this was at the beginning, because I assumed
that of course there was only one workflow that was being described to me in
the documentation. It is only a slight exaggeration to say that the existing
documentation could be summarized as follows: “There are seventeen different
ways to create a Debian package. We are only going to consider fifteen of them
here. Every one is different. You should just use the one that works best for
your situation. We can’t be bothered to explain to you how you can tell which
one will be best for your situation, but you will know it when you see it.
Also, most of these workflows are incompatible with each other, and everyone
who uses any workflow besides the one I like is an idiot. Also, I can’t be
bothered to explain all the intermediary steps or any corner cases, but you’ll
figure them out as your go.”

I have written in other venues about the need for Debian to pick one canonical
workflow. This workflow could then be documented in detail, including corner
cases, and presented in a step-by-step guide that doesn’t assume any previous
knowledge about Debian. There are several people diligently working on trying
to get Debian to consolidate on one (or a few) accepted workflows, but the
resistance from some developers who have their other favorite workflows is
intense. In my personal opinion, for the good of the project and the need to
attract far greater than 1,000 active Debian Developers, we need to overcome
our personal workflow opinions and consolidate on one choice, even if we
consider choice to be technically inferior to our preferred option.

2. A vast amount of the step-by-step documentation written for beginners
regarding how to package for the first time is subtly outdated in ways that
become very confusing to beginners. Usually, at the time the documentation
was written, it was correct. But things change quickly in Debian, and often
nobody revisits and updates these howto guides.

I think that if we want to get serious about ever attracting a large number of
new Debian Developers, we need a team of people (probably, again, a DPL
delegation) who has authority and focus to produce the canonical documentation
for packaging for beginners. That documentation would need to be constantly
updated to be accurate, should be easily discoverable on Debian Mentors,
should consist of a single howto document that steps through everything from
beginning to end (with references to things like Debian Policy), and should
focus on one canonical workflow (meaning that, if we can’t as a project agree
on a workflow as described in point 1 above, the new packager documentation
should pick one anyway and say, “This is the one true workflow that all new
contributors should use to learn how to package for Debian”).

It probably goes without saying that both of the points I have made above will
be unpopular with certain circles, particularly the link between picking a
canonical workflow and making it easier to attract new Debian contributors.
But I don’t see anything else that will move the needle. I have been paying
fairly close attention to Debian for the past 25 years, and I am not aware of
the active Debian Developers ever being much higher than 1,000 people.
Despite the discussion about attracting more contributors being a perennial
part of almost every DPL platform, we don’t seem to be able to change the
status quo. My sense is that to really accomplish what Debian wants to
accomplish, we need something more like 10,000 active Debian Developers. If
we ever want to get there, we need to so something that goes beyond all the
things we have previously tried. And as far as I can tell, having a really
good onboarding process that doesn’t depend on having real-life contact with a
Debian Developer is something that has never been tried.

[Mechtilde Stehmann]

Hello Soren,

Post by Soren Stoutner
Robert,
I appreciate your addition to the discussion.

Post by Robert Chéramy
1) Documentation

<snip />

Post by Soren Stoutner
2. A vast amount of the step-by-step documentation written for beginners
regarding how to package for the first time is subtly outdated in ways that
become very confusing to beginners. Usually, at the time the documentation
was written, it was correct. But things change quickly in Debian, and often
nobody revisits and updates these howto guides.

I had the same problems as my start becoming a Maintainer.

I started with an very small new package and tried to understand the
steps I have to do. Then I started to write a Script to do the packaging
in the same way every time.

then I did it with some more packages. Also the discussions "how can I
start? etc. get me to write down all steps. And the script increases.

Also the description increases.You can find it at salsa.debian.org. it
is work in progress. This is no additional documentation. It tries to
collect the information from different documents, which exists. It
describes, why it is necessary to do something.

My experience is. it is not easy to describe packaging for newcomer.
Every newcomer has different questions and different problems with
starting packaging.

So we should encourage everyone to ask and contact people in a team, in
a local or language group or the persons who sign the key.

Kind regards

--
Mechtilde Stehmann

## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F

[Pirate Praveen]

https://debconf24.debconf.org/talks/74-attracting-and-retaining-new-contributors-insights-from-brazil/
https://lwn.net/Articles/987548/
https://news.ycombinator.com/item?id=41599327
I think people interested on the subject can get some insights from the above (comments from people not involved in the project; yes, we, people already involved in the project, can be very biased). Also ignore some stupid comments, expected in those public discussions.
And yes, this is something that Debian as whole needs to do better.

I want to comment about registering on wiki.debian.org and salsa.debian.org specifically.

Can we setup a system for adding to allow list by DD signed emails (like how debian.net DNS changes are done)? Possibly for IP address allow list too.

This would help a lot during events or for local groups where getting a wiki account takes sending an email and waiting.

Now that I think about this idea, this would also help for salsa accounts. It takes many days to get a salsa account after an event and I usually have to ask them to use another git hosting service till that happens.

A DD validating email address and IP address can address the spam concern. This will expand people who can authorize new accounts hugely. Also reduce load on current admins and wait time for new contributors.

[Antonio Terceiro]

Post by Pirate Praveen

https://debconf24.debconf.org/talks/74-attracting-and-retaining-new-contributors-insights-from-brazil/
https://lwn.net/Articles/987548/
https://news.ycombinator.com/item?id=41599327
I think people interested on the subject can get some insights from the above (comments from people not involved in the project; yes, we, people already involved in the project, can be very biased). Also ignore some stupid comments, expected in those public discussions.
And yes, this is something that Debian as whole needs to do better.

I want to comment about registering on wiki.debian.org and
salsa.debian.org specifically.
Can we setup a system for adding to allow list by DD signed emails
(like how debian.net DNS changes are done)? Possibly for IP address
allow list too.
This would help a lot during events or for local groups where getting
a wiki account takes sending an email and waiting.
Now that I think about this idea, this would also help for salsa
accounts. It takes many days to get a salsa account after an event and
I usually have to ask them to use another git hosting service till
that happens.
A DD validating email address and IP address can address the spam
concern. This will expand people who can authorize new accounts
hugely. Also reduce load on current admins and wait time for new
contributors.

[salsa admin hat on]

Yes, this is a good idea and I already thought about having a
distributed approval of accounts. The only missing detail (!) is the
code to make it happen.

Another thing that can be done in the interim, is arranging a schedule
beforehand. You get all your new contributions to register "at once",
you get me/some admin a list or usernames, and we get those new users
approved in a batch before the next day, or later in the same day
depending on timezones etc.

[Andreas Tille]

Hi,

Post by Soren Stoutner
Robert,

Thanks a lot to Robert to ask here on the list and sorry for my delayed
answer. I had to catch up with real life but since the question was
originally to me in person I feel the need to finally get involved into
the thread. I lot of very good answers were given. My specific thanks
goes to Mechtilde who wrote (another) nice documentation as well as
Debian Brasil members who cared a lot to the Brasilian community which
is objectively reflected in the number of Brasilians contributing to
Debian.

Post by Soren Stoutner
I appreciate your addition to the discussion.

+1

I will not comment on the other answers since I felt these are quite
complete in itself. I'd like to add some remark to Soren's mail.

Post by Soren Stoutner
1. ...
“There are seventeen different
ways to create a Debian package. We are only going to consider fifteen of them
here. Every one is different. You should just use the one that works best for
your situation. We can’t be bothered to explain to you how you can tell which
one will be best for your situation, but you will know it when you see it.
Also, most of these workflows are incompatible with each other, and everyone
who uses any workflow besides the one I like is an idiot. Also, I can’t be
bothered to explain all the intermediary steps or any corner cases, but you’ll
figure them out as your go.”

I agree that this can be confusing for newcomers. However, as mentioned
in follow-up discussions, there are valid reasons for *some* differences
in workflows. The challenge is even more complex because it's not just
about workflows--it's a matrix of "workflows × toolsets."

Post by Soren Stoutner
I have written in other venues about the need for Debian to pick one canonical
workflow. This workflow could then be documented in detail, including corner
cases, and presented in a step-by-step guide that doesn’t assume any previous
knowledge about Debian. There are several people diligently working on trying
to get Debian to consolidate on one (or a few) accepted workflows, but the
resistance from some developers who have their other favorite workflows is
intense. In my personal opinion, for the good of the project and the need to
attract far greater than 1,000 active Debian Developers, we need to overcome
our personal workflow opinions and consolidate on one choice, even if we
consider choice to be technically inferior to our preferred option.

I appreciate your vision of an ideal world and share it, though I
recognize it's unattainable. While some barriers are insurmountable,
others might be overcome. I've chosen to focus on the latter, even
though it greatly exceeds my available spare time. To give some
examples: I'm working on trying to get rid of dh-buildinfo, replace
cdbs by dh, convert d/copyright to machine readable DEP-5 format etc.
basically following the Debian Trends (https://trends.debian.net/)

Post by Soren Stoutner
2. A vast amount of the step-by-step documentation written for beginners
regarding how to package for the first time is subtly outdated in ways that
become very confusing to beginners. Usually, at the time the documentation
was written, it was correct. But things change quickly in Debian, and often
nobody revisits and updates these howto guides.
I think that if we want to get serious about ever attracting a large number of
new Debian Developers, we need a team of people (probably, again, a DPL
delegation) ...

My response is similar to the suggestion of a DPL delegation for
mentors: I don't believe a delegation would help in finding people to do
the work. The issue, in my view, is that we are all volunteers, choosing
tasks we enjoy in our spare time. For me, that's fixing bugs, packaging,
and even teaching packaging. Writing good documentation doesn't excite
me as much, so I don't focus on it. Perhaps the criticism of
insufficient documentation reflects a shortage of volunteers who
genuinely enjoy and excel at this important task.

As for what a DPL could do: I could theoretically fund someone to write
and maintain good documentation. But no, I'd rather not open that can of
worms here. Instead, I'd prefer to encourage people like Mechthilde to
continue their excellent work and help promote it. As always in Debian:
if you see an important task that needs doing, take the initiative and
do it. Running around explaining to volunteers that work is left undone
doesn't solve the problem.

Kind regards
Andreas.

[Pirate Praveen]

Post by Robert Chéramy
2) What should I read first if I want to make a new package?

I usually suggest a step by step guide to people who are new, in this I suggest building existing packages from source and updating existing packages before creating a new package from scratch.

Also starting with JavaScript packages makes a lot of automations to make things easier for new people. Once they pick basics of packaging with js, they can start with other packages easily.

https://wiki.debian.org/Packaging/Learn

[Soren Stoutner]

Post by Pirate Praveen

Post by Robert Chéramy
2) What should I read first if I want to make a new package?

I usually suggest a step by step guide to people who are new, in this I
suggest building existing packages from source and updating existing

packages

Post by Pirate Praveen
before creating a new package from scratch.
Also starting with JavaScript packages makes a lot of automations to make
things easier for new people. Once they pick basics of packaging with js,
they can start with other packages easily.
https://wiki.debian.org/Packaging/Learn

That’s a really nice resource. I am surprised I haven’t seen it before.

[Gard Spreemann]

Since several people seem to be sharing their experiences with
(undesirable) challenges in becoming a DD, I thought I'd add a point
that seemingly hasn't been covered yet:

The BTS is core to Debian. It is e-mail based. While I personally think
e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes – as much as 10 or 15 – for
replies to simple operations. Not only because being assigned a bug
number is actually necessary in order to move on with some processes
like initial packaging, but also because of the mental toll that comes
from not knowing that a past operation successfully completed, and
worrying that I'd have to return to it.

Admittedly, I still feel like that at times, some six years later (a DD
for four).

I suspect that this highly asynchronous nature of the BTS significantly
puts off new contributors.

This is not meant as an argument against e-mail based systems (although
I do suspect that that is also a hindrance to some new
contributors). Nor is it meant to suggest that we need to embrace
instant gratification. We certainly should not – but it is not
unreasonable to expect to be able to see a syntax error in bug report
modification without waiting ten minutes.

Just my 0.1 monetary units.


Best,
Gard

[Andrey Rakhmatullin]

Post by Gard Spreemann
Since several people seem to be sharing their experiences with
(undesirable) challenges in becoming a DD, I thought I'd add a point
The BTS is core to Debian. It is e-mail based. While I personally think
e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes – as much as 10 or 15 – for
replies to simple operations.

TBH there is a difference between "email based and asynchronous" and
"needs at least 10 minutes to process a request". It seems to be a problem
specific to the BTS.

[Gard Spreemann]

Post by Andrey Rakhmatullin

Post by Gard Spreemann
Since several people seem to be sharing their experiences with
(undesirable) challenges in becoming a DD, I thought I'd add a point
The BTS is core to Debian. It is e-mail based. While I personally think
e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes – as much as 10 or 15 – for
replies to simple operations.

TBH there is a difference between "email based and asynchronous" and
"needs at least 10 minutes to process a request". It seems to be a problem
specific to the BTS.

Absolutely. I of course also don't know whether it's just my e-mails
taking 10 minutes to reach the BTS, but I would suspect that a lot of
improvements can be had in the system's response time.


Best,
Gard

[Alexandre Detiste]

Hi,

Here's the default crontabs for debbugs.
There do exists an handfull of other instances of debbugs, some might
deviate from default settings.

Greetings

/usr/lib/debbugs/processall >/dev/null
7,22,37,52 * * * *

https://bugs.debian.org/debbugs-source/debian/debian/crontab

Post by Gard Spreemann
Absolutely. I of course also don't know whether it's just my e-mails
taking 10 minutes to reach the BTS, but I would suspect that a lot of
improvements can be had in the system's response time.
Best,
Gard

[Andrey Rakhmatullin]

Post by Alexandre Detiste
Here's the default crontabs for debbugs.
There do exists an handfull of other instances of debbugs, some might deviate from default settings.
Greetings 
/usr/lib/debbugs/processall >/dev/null
7,22,37,52 * * * * 
https://bugs.debian.org/debbugs-source/debian/debian/crontab

I am sincerely shocked by the default setting of doing a processing every
15 minutes by default

Yeah, I feel like it's more rare.

[Matthias Urlichs]

It's fine we are doing batch processing instead of instant reactive processing

Yeah, but the batch delay time should still be zero, at least if the
system is not busy.

Kernel 2.6.13 introduced the "inotify" system call. There's the
"inoticoming" package that can start the batch job(s) as soon as a new
file shows up.

Heck, the Linux::Inotify2 Perl module has been around almost as long:
you could simply make these jobs long-running and tell them to wait for
new files to show up, which might actually decrease system load.

I'd do this myself —  this looks like an easily fixable paper cut — but
somebody with (a) less than 15 years of not writing any Perl code, and
preferably (b) some non-zero experience with our bug tracker, would make
more sense.

--
-- regards
--
-- Matthias Urlichs

[Sean Whitton]

Hello,

Post by Andrey Rakhmatullin

Post by Gard Spreemann
Since several people seem to be sharing their experiences with
(undesirable) challenges in becoming a DD, I thought I'd add a point
The BTS is core to Debian. It is e-mail based. While I personally think
e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes – as much as 10 or 15 – for
replies to simple operations.

TBH there is a difference between "email based and asynchronous" and
"needs at least 10 minutes to process a request". It seems to be a problem
specific to the BTS.

The GNU instance of debbugs, which I interact with regularly, is like
lightning compared to ours, and it does help.

[Marc Haber]

Post by Gard Spreemann
The BTS is core to Debian.

And it is one of the best Bugtrackers I have ever encountered. It
could be faster, yes, but its features trump the waiting time by far.

Greetings
Marc

[Gard Spreemann]

Post by Marc Haber

Post by Gard Spreemann
The BTS is core to Debian.

And it is one of the best Bugtrackers I have ever encountered.

I agree.

Post by Marc Haber
It could be faster, yes, but its features trump the waiting time by
far.

Without knowing anything about the internal workings of the BTS: It
seems we could have a lot more responsiveness without giving up any of
those features.


Best,
Gard

[Charles Plessy]

Post by Gard Spreemann
The BTS is core to Debian. It is e-mail based. While I personally think
e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes – as much as 10 or 15 – for
replies to simple operations. Not only because being assigned a bug
number is actually necessary in order to move on with some processes
like initial packaging, but also because of the mental toll that comes
from not knowing that a past operation successfully completed, and
worrying that I'd have to return to it.

Thanks Gard for your comment. I would like to add that it is not just a
problem to newcomers. The time I can give to Debian is often 1 hour at
most per day, and waiting times being 25% of my time budget can
obviously ruin the day. And the lack of the confidence in the system
can not be solved entierly by knowledge, skill or experience, because
the core of the problem is that every year it is less guarateed that an
email is really being delivered after being sent.


Have a nice day,

Charles

[Pirate Praveen]

Post by Charles Plessy

Post by Gard Spreemann
The BTS is core to Debian. It is e-mail based. While I personally think
e-mail-based workflows can be quite nice, the BTS' asynchronous nature
did cause me a lot of extra pointless work when I was an outsider
attempting to learn the ropes. Being not 100% confident with the system,
I way too often found myself waiting minutes – as much as 10 or 15 – for
replies to simple operations. Not only because being assigned a bug
number is actually necessary in order to move on with some processes
like initial packaging, but also because of the mental toll that comes
from not knowing that a past operation successfully completed, and
worrying that I'd have to return to it.

Thanks Gard for your comment. I would like to add that it is not just a
problem to newcomers. The time I can give to Debian is often 1 hour at
most per day, and waiting times being 25% of my time budget can
obviously ruin the day. And the lack of the confidence in the system
can not be solved entierly by knowledge, skill or experience, because
the core of the problem is that every year it is less guarateed that an
email is really being delivered after being sent.

I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.

Kind of like a mailing list web interface (hyperkitty in mailman) that
allows sending mails from a browser after authenticating.

Say reportbug.debian.org which has a login with salsa button (and create
a local user), then shows the report bug interface on ui, when
submitting it will send mail from the same server and any reply will be
forwarded to the email address in salsa account.

Additional bug interactions would be a plus, but having to figure out
the initial bug report template or configuring smtp smarthost is a pain
(it is not impossible but most other Free Software projects don't need
such a setup).

Additional interactions via email is much easier as it does not involve
manually creating a pseudo header (which don't work with html
formatting, the default for most clients) or configuring an mta on your
laptop.

If reportbug can open your already configure email client (like
thunderbird) that already helps a lot.

These extra hurdles are specific to our email based work flow and I
don't think it adds much value.

[Marc Haber]

On Wed, 11 Dec 2024 17:04:52 +0530, Pirate Praveen

Post by Pirate Praveen
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.

Is it not already the case that you can use reportbug without
e-mail-client or local server installed?

Post by Pirate Praveen
Kind of like a mailing list web interface (hyperkitty in mailman) that
allows sending mails from a browser after authenticating.
Say reportbug.debian.org which has a login with salsa button (and create
a local user), then shows the report bug interface on ui, when
submitting it will send mail from the same server and any reply will be
forwarded to the email address in salsa account.

How would the local data be collected and included?

People who can install and use an app on their mobile can also use
reportbug.

Greetings
Marc

[Pirate Praveen]

Post by Marc Haber
On Wed, 11 Dec 2024 17:04:52 +0530, Pirate Praveen

Post by Pirate Praveen
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.

Is it not already the case that you can use reportbug without
e-mail-client or local server installed?

You have to quit reportbug and copy paste the text file to an email
client. I use it sometimes, but not friendly.

Post by Marc Haber

Post by Pirate Praveen
Kind of like a mailing list web interface (hyperkitty in mailman) that
allows sending mails from a browser after authenticating.
Say reportbug.debian.org which has a login with salsa button (and create
a local user), then shows the report bug interface on ui, when
submitting it will send mail from the same server and any reply will be
forwarded to the email address in salsa account.

How would the local data be collected and included?

We can ask them to run a command and copy paste the output.

Post by Marc Haber
People who can install and use an app on their mobile can also use
reportbug.

As I said, it is not impossible, but a painful process. I use reportbug
only when I have to generate a template for rm requests, otherwise I
always write an email. We should avoid asking new people to run through
hoops when possible. With enough practice, anyone could jump through a
hoop as well.

Initial days of the project, email was the primary communication for all
the people and these things (configuring email) were taken for granted.
But now email is not a primary communication tool for so many people.

I'm not suggesting we remove email interface, just adding other options
for people who don't find email as their default communication tool.

Post by Marc Haber
Greetings
Marc

[Charles Plessy]

As I said, it is not impossible, but a painful process. I use reportbug only
when I have to generate a template for rm requests, otherwise I always write
an email. We should avoid asking new people to run through hoops when
possible. With enough practice, anyone could jump through a hoop as well.

Last time I had to write a removal request I asked ChatGPT and it worked
well!

[Holger Levsen]

Post by Charles Plessy
Last time I had to write a removal request I asked ChatGPT and it worked
well!

is this debian-devel@ or -curiosa@? (&scnr)

that said, I do realize that the verb "to google" slowly is becoming "to
ask $chatgpt" or rather, that also google is a frontend to a huge statistical
database...

more seriously, once you learn something which you think should be better
documented, please consider contributing to some of the various documentations
for Debian.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

„AufklÀrung ist der Ausgang des Menschen aus seiner selbstverschuldeten
UnmÃŒndigkeit.“

[Jonas Smedegaard]

Quoting Holger Levsen (2024-12-11 15:29:08)

Post by Holger Levsen

Post by Charles Plessy
Last time I had to write a removal request I asked ChatGPT and it worked
well!

that said, I do realize that the verb "to google" slowly is becoming "to
ask $chatgpt" or rather, that also google is a frontend to a huge statistical
database...
more seriously, once you learn something which you think should be better
documented, please consider contributing to some of the various documentations
for Debian.

...to help mortals stay independent of Computer-Articulated Inferences
(CIAs), and at the same time help train those same CIAs thanks to our
devotion to transparency and free-for-all-even-non-mortals.

- Jonas

[Charles Plessy]

Post by Charles Plessy
Last time I had to write a removal request I asked ChatGPT and it worked
well!

Hi Holger and everybody,

it is a thread on debian-devel@ about how to attract newcomers, and what
I was trying to hint at in a clumsy way (sorry!) is that more and more
people in the pool of potential newcomers will have the use of LLMs part
of their routine and reflexes.

I think that we need to make ourselves ready for that generation and
here are a couple of thoughts about this:

- as of todays LLMs are also used to solve social problems. Think
about the joke of an office worker that uses a LLM to turn bullet
points in a nice report, sends it to boss, who uses a LLM to turn the
report to bullet points because no time. When people start to do so
in Debian, let's make sure we do not fingerpoint them but fix our
process instead. In case of the removal requests, it could be for
instance to provide a remote access to dak so that a developers with
an appropriate authentication system can remove their packages by
themselves.

I hear… « where is the patch? » but… do I have the skills to write it
alone?

- at work, not using LLMs to write code is like refusing to wear shoes
at the Olympics because Greeks did not and saying that shoes pollute
and the run is no less fun when everybody agreed to be bare feet.
True, but people taking this stance do not stay in competition. But
in Debian we have a problem: current commercial LLMs are
copyright-laundering machines and we do not want to use them to
develop our code. To attract newcomers I do not see any other option
than participating in the creation of Free LLMs that produce code
that we can use under the main copyright pardigms of the Free
software (GPL and MIT). The cheapest way is to clearly express a
desire for it to happen, and then of course, we can go futher
by relaying fundraising calls, participating to the costs,
publicising some of the unique features of our software archive such
as machine-readable copyright documentaiton listing GPL-compatible
source files that can be used to train a GPL LLM, etc.

I will not argue that this email really belongs do debian-devel@; the
whole discussion is rather more for debian-project@, but hopping beween
lists is confusing… for humans readers and for AI summarisers!

Have a nice day,

Charles

[Sean Whitton]

Hello,

Post by Charles Plessy
- at work, not using LLMs to write code is like refusing to wear shoes
at the Olympics because Greeks did not and saying that shoes pollute
and the run is no less fun when everybody agreed to be bare feet.
True, but people taking this stance do not stay in competition.

Really? It's already this bad, in some places?

You work in academia right? Maybe it's less bad in software shops.

[Andrey Rakhmatullin]

Post by Marc Haber

Post by Pirate Praveen
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.

Is it not already the case that you can use reportbug without
e-mail-client or local server installed?

You have to quit reportbug and copy paste the text file to an email client.
I use it sometimes, but not friendly.

reportbug can talk SMTP directly, is that not enough for you?

[Pirate Praveen]

Post by Andrey Rakhmatullin

Post by Marc Haber

Post by Pirate Praveen
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.

Is it not already the case that you can use reportbug without
e-mail-client or local server installed?

You have to quit reportbug and copy paste the text file to an email client.
I use it sometimes, but not friendly.

reportbug can talk SMTP directly, is that not enough for you?

without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?

[s***@free.fr]

Post by Pirate Praveen

Post by Andrey Rakhmatullin
reportbug can talk SMTP directly, is that not enough for you?

without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?

It does, and that works for me (though maybe not from some places that
block some traffic).

`reportbug.debian.org` is hardcoded as the SMTP host to use when no
other SMTP host is configured.

Cheers,

[Pirate Praveen]

Post by s***@free.fr

Post by Pirate Praveen

Post by Andrey Rakhmatullin
reportbug can talk SMTP directly, is that not enough for you?

without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?

It does, and that works for me (though maybe not from some places that
block some traffic).
`reportbug.debian.org` is hardcoded as the SMTP host to use when no
other SMTP host is configured.

Thanks, in that case, it is my mistake. I was always thinking it needs
an mta configured, may be this was a recent addition. Not sure if it was
there from the beginning.

[Sune Vuorela]

Post by Pirate Praveen
Thanks, in that case, it is my mistake. I was always thinking it needs
an mta configured, may be this was a recent addition. Not sure if it was
there from the beginning.

It has been by default using the submission port for default for ages,
though not from the beginning.

If we consider it a recent addition, then it also isn't long ago I was
at my first debconf ('07)

/Sune

[Pirate Praveen]

Post by s***@free.fr

Post by Pirate Praveen

reportbug can talk SMTP directly, is that not enough for you?

without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?

It does, and that works for me (though maybe not from some places
that block some traffic).

Well, "some places" includes basically all home users, at least in
Sweden where I live. This is not about ISPs blocking "some traffic",
they only block outgoing smtp traffic on default ports. The reasons are
obvious.
That is, it's often a pain to set up outgoing SMTP. As a user you do it
for your MTA since you just have to. But a CLI tool to report Debian
bugs? Will not be configured by any newcomer if you ask me.

Many firewalls (for example in offices) also block almost every port
other than 80 or 443. So it'd still be valuable to have a web based
reportbug interface.

[s***@free.fr]

Post by Pirate Praveen
Many firewalls (for example in offices) also block almost every port
other than 80 or 443. So it'd still be valuable to have a web based
reportbug interface.

Well, usually they just block everything including ports 80 and 443,
often one has to use some invasive proxy setup that may well require you
to give up on any privacy and will occasionally block random URLs
without even returning appropriate HTTP status codes. Which is why
building things offline is also appreciated in some corporate places.

But yes, there is possibly something to be done with a dedicated URI
scheme that would be pre-registered with desktop environnements or
packaged browsers and that would make it possible for a web app to lauch
reportbug and get the data from it.

Cheers,

[Philipp Kern]

I would like to add that while self-sustained SMTP facilities is
useful, the reportbug tool has a strong assumption: it assumes that the
bug reporter must be using Debian (or one of the Debian derivative,
though we know it won't work well) when reporting the bug. This is an
overly strong requirement that we as a project should avoid.

That is not a requirement for bug reporting - it works by plain email.
That's a requirement for reportbug to send it off directly - and the
information it collects is valuable. reportbug even offers to prepare a
report and you can put it someplace else.

I don't think we need to collect arbitrary requests from non-Debian
users. We are not the feature request place of last resort, the bug
reports should pertain primarily to the Debian integration. (Some stuff
to be forwarded upstream is fine.)

Kind regards
Philipp Kern

[Andrey Rakhmatullin]

I would like to add that while self-sustained SMTP facilities is useful, the
reportbug tool has a strong assumption: it assumes that the bug reporter
must be using Debian (or one of the Debian derivative, though we know it
won't work well) when reporting the bug. This is an overly strong
requirement that we as a project should avoid.

(note that while the original subthread about reportbug was already not
fully related to the initial contributors/maintainers discussion, this one
is even less so)

[s***@free.fr]

Well, "some places" includes basically all home users, at least in
Sweden where I live. This is not about ISPs blocking "some traffic",
they only block outgoing smtp traffic on default ports. The reasons are
obvious.

Did you try to connect using TCP port 587? Usually that one is not
blocked by ISPs (and should not be). I think that's what reportbug uses.

a CLI tool to report Debian bugs? Will not be configured by any
newcomer if you ask me.

reportbug has a nice GTK GUI that already works pretty well and is
included on live images, though there is still room for improvements in
terms of usability. But I think it already works better as it is than
many commercial alternatives, including web-based ones.

Cheers,

[Marc Haber]

On Wed, 11 Dec 2024 15:00:45 +0100, Alec Leamas

Post by s***@free.fr

Post by Pirate Praveen

reportbug can talk SMTP directly, is that not enough for you?

without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?

It does, and that works for me (though maybe not from some places that
block some traffic).

Well, "some places" includes basically all home users, at least in
Sweden where I live. This is not about ISPs blocking "some traffic",
they only block outgoing smtp traffic on default ports. The reasons are
obvious.

An ISP should NEVER block traffic to the SMTP submission port 587, for
obvious reasons as well.

Greetings
Marc

[Marc Haber]

On Wed, 11 Dec 2024 17:50:55 +0530, Pirate Praveen

Post by Pirate Praveen

Post by Marc Haber
On Wed, 11 Dec 2024 17:04:52 +0530, Pirate Praveen

Post by Pirate Praveen
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.

Is it not already the case that you can use reportbug without
e-mail-client or local server installed?

You have to quit reportbug and copy paste the text file to an email
client. I use it sometimes, but not friendly.

I always thought we were beyond that right now.

Post by Pirate Praveen

Post by Marc Haber
How would the local data be collected and included?

We can ask them to run a command and copy paste the output.

That is way more uncomforable than reportbug.

Post by Pirate Praveen
I'm not suggesting we remove email interface, just adding other options
for people who don't find email as their default communication tool.

We're having this discussion about once a year. It always ends up with
nobody implementing anything and the issue coming up again a year
later.

Greetings
Marc

[Wouter Verhelst]

Post by Marc Haber
On Wed, 11 Dec 2024 17:04:52 +0530, Pirate Praveen

Post by Pirate Praveen
I think a reportbug web based front end that authenticates with salsa
via oauth and sends emails without any email client needing to be
configured will already help.

Is it not already the case that you can use reportbug without
e-mail-client or local server installed?

You have to quit reportbug and copy paste the text file to an email client.
I use it sometimes, but not friendly.

This is not true.

reportbug can send emails through sendmail (if you have that
configured), or it can be set up so it can bypass that entirely and send
email directly to an SMTP server.

It interacts with the BTS over REST.

Basically reportbug automates as much as possible so you don't have to
do things manually.

Post by Marc Haber

Post by Pirate Praveen
Kind of like a mailing list web interface (hyperkitty in mailman) that
allows sending mails from a browser after authenticating.
Say reportbug.debian.org which has a login with salsa button (and create
a local user), then shows the report bug interface on ui, when
submitting it will send mail from the same server and any reply will be
forwarded to the email address in salsa account.

How would the local data be collected and included?

We can ask them to run a command and copy paste the output.

Post by Marc Haber
People who can install and use an app on their mobile can also use
reportbug.

As I said, it is not impossible, but a painful process. I use reportbug only
when I have to generate a template for rm requests, otherwise I always write
an email. We should avoid asking new people to run through hoops when
possible.

This is the whole point of reportbug...

With enough practice, anyone could jump through a hoop as well.
Initial days of the project, email was the primary communication for all the
people and these things (configuring email) were taken for granted. But now
email is not a primary communication tool for so many people.
I'm not suggesting we remove email interface, just adding other options for
people who don't find email as their default communication tool.

This I do agree with. I like your suggestion of salsa authentication.
Due to the magic of OAuth2, this can be done by reportbug too; the first
time it will just spawn a web browser and ask you to authenticate; this
can then get an authentication token. As long as that token does not
expire, you can then then use reportbug from the command line and
interact with the BTS.

[Ananthu C V]

Post by Wouter Verhelst
reportbug can send emails through sendmail (if you have that
configured), or it can be set up so it can bypass that entirely and send
email directly to an SMTP server.

If you use something like thunderbird, you can always do something like
`reportbug --mua=thunderbird` iirc, and I have used that in the past.
This is configurable as well, I use 'mua mutt' in my reportbugrc.

[Paul Gevers]

Hi

Post by Pirate Praveen
If reportbug can open your already configure email client (like
thunderbird) that already helps a lot.

I do that all the time:

***@toba ~ $ grep thunderbird ~/.reportbugrc
mua thunderbird

Paul

[Richard Lewis]

While I personally think e-mail-based workflows can be quite nice, the
BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100%
confident with the system, I way too often found myself waiting
minutes – as much as 10 or 15 – for replies to simple operations.

agree with this. Also the noisy reply to every message is pretty
unhelpful - even gmail cant work out what is being acknowledged


I'd like to help improve the docuemntation, and suggest ways to make it
less confusing to use, but the bts's own bug list makes me wonder if
anyone would review

[Otto Kekäläinen]

Hi,

Post by Richard Lewis

While I personally think e-mail-based workflows can be quite nice, the
BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100%
confident with the system, I way too often found myself waiting
minutes – as much as 10 or 15 – for replies to simple operations.

agree with this. Also the noisy reply to every message is pretty
unhelpful - even gmail cant work out what is being acknowledged
I'd like to help improve the docuemntation, and suggest ways to make it
less confusing to use, but the bts's own bug list makes me wonder if
anyone would review

I submitted 4 years ago
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/6,
which got some approving comments, but nobody merged it. Your time is
probably better used contributing to the Debian Developers Reference
or other docs.

Honestly, I suspect bugs.debian.org is intentionally cumbersome to use
to deter "noobies", and raise the bar for submission so high, that any
bug that actually gets filed is likely already well researched by a
Debian expert and half of the time comes with a patch attached.
Unfortunately it also leads to maintainers having to put more effort
in maintaining the bug reports as the barrier for contributors to help
out with bug triage etc way too high.

[Tiago Bortoletto Vaz]

Post by Otto Kekäläinen
Hi,

Post by Richard Lewis

While I personally think e-mail-based workflows can be quite nice, the
BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100%
confident with the system, I way too often found myself waiting
minutes – as much as 10 or 15 – for replies to simple operations.

agree with this. Also the noisy reply to every message is pretty
unhelpful - even gmail cant work out what is being acknowledged
I'd like to help improve the docuemntation, and suggest ways to make it
less confusing to use, but the bts's own bug list makes me wonder if
anyone would review

I submitted 4 years ago
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/6,
which got some approving comments, but nobody merged it. Your time is
probably better used contributing to the Debian Developers Reference
or other docs.
Honestly, I suspect bugs.debian.org is intentionally cumbersome to use
to deter "noobies", and raise the bar for submission so high, that any
bug that actually gets filed is likely already well researched by a
Debian expert and half of the time comes with a patch attached.
Unfortunately it also leads to maintainers having to put more effort
in maintaining the bug reports as the barrier for contributors to help
out with bug triage etc way too high.

Btw, for triage I used to suggest https://fabre.debian.net to newcomers. I had
some hope that it could be a start for something bigger, so I tried to have
access to the code to improve a few things but never had an answer from the
maintainer :\

Just pointing out this somewhat unknown project which is still online.

Bests,

--
Tiago Vaz

[Richard Lewis]

Post by Tiago Bortoletto Vaz
Btw, for triage I used to suggest https://fabre.debian.net to
newcomers. I had some hope that it could be a start for something
bigger, so I tried to have access to the code to improve a few things
but never had an answer from the maintainer :\

This looks like it has some improvements over the bts pages, at least
for viewing a single bug!

If you do manage to view a single bug eg
https://fabre.debian.net/bugs/1089233 you can click a button and it
pre-populates an email to reply/close/tag

it's a shame the bts doesnt have some of this, is there any way to get
development going?

[Pirate Praveen]

Post by Richard Lewis

Btw, for triage I used to suggesthttps://fabre.debian.net to
newcomers. I had some hope that it could be a start for something
bigger, so I tried to have access to the code to improve a few things
but never had an answer from the maintainer :\

This looks like it has some improvements over the bts pages, at least
for viewing a single bug!
If you do manage to view a single bug eg
https://fabre.debian.net/bugs/1089233 you can click a button and it
pre-populates an email to reply/close/tag
it's a shame the bts doesnt have some of this, is there any way to get
development going?

I think this is really nice improvement and should get more attention,
may be via https://salsa.debian.org/freexian-team/project-funding ?

Sending to bts from fabre could be controlled via salsa oauth and could
use the reportbug smtp server.

[Sean Whitton]

Hello,

Post by Richard Lewis

While I personally think e-mail-based workflows can be quite nice, the
BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100%
confident with the system, I way too often found myself waiting
minutes – as much as 10 or 15 – for replies to simple operations.

agree with this. Also the noisy reply to every message is pretty
unhelpful - even gmail cant work out what is being acknowledged

(gmail's threading support is famously simplistic)

[Marc Haber]

On Wed, 11 Dec 2024 23:00:58 +0000, Richard Lewis

Post by Richard Lewis

While I personally think e-mail-based workflows can be quite nice, the
BTS' asynchronous nature did cause me a lot of extra pointless work
when I was an outsider attempting to learn the ropes. Being not 100%
confident with the system, I way too often found myself waiting
minutes – as much as 10 or 15 – for replies to simple operations.

agree with this. Also the noisy reply to every message is pretty
unhelpful - even gmail cant work out what is being acknowledged

Since mutt can pretty well sort out the BTS's reply, all Google needs
to do is to fix their webmail to follow the Internet Standards that
wer already there when that horrible company was founded. Otoh, they
don't want to be compatible with the world, they want the world to
adapt to them (see also their "spam" filters).

Greetings
Marc

[Don Armstrong]

Post by Gard Spreemann
Being not 100% confident with the system,
I way too often found myself waiting minutes – as much as 10 or 15 – for
replies to simple operations.

The BTS processes messages every 3 minutes. There's nothing really
stopping an inotify-based daemon always running and invoking processall
than inertia (and some processes which pull long-running locks due to
old design decisions around archiving).

There's also no processes left which require waiting to receive a bug
number; you can do everything in the initial message that you can do
later using the Control: pseudoheader.

That said, the critique is received, and I've been very, very slowly
working on rewriting the entire system to address some of these issues.
[Being a parent has made my Debian time very precious, however, so
keeping things running has taken precedence.]

[Sean Whitton]

Hello,

Post by Don Armstrong
That said, the critique is received, and I've been very, very slowly
working on rewriting the entire system to address some of these issues.
[Being a parent has made my Debian time very precious, however, so
keeping things running has taken precedence.]

Wow! Thanks for working on this!