| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 92:14:21 |
| Calls: | 483 |
| Calls today: | 1 |
| Files: | 1,073 |
| Messages: | 97,705 |
Hi.
Since I am relatively new contributing to Debian (while doing software >development for 3 decades). I thought it might be useful to share a bit
of the experience.
One fundamental thing is that you may not be welcomed simply because
there is nobody there welcoming you. Adding a merge request for a fix
may be pointless, because nobody will merge it. Reviewing is a certain
effort and nobody has time for that.
Also because MRs are second-class citizens and maintainers normally
don't even get notifications that one was created.
On 30/05/2025 10:14, Andrey Rakhmatullin wrote:
Also because MRs are second-class citizens and maintainers normally
don't even get notifications that one was created.
What should you do in that situation where you have a no-response MR?
On Fri, May 30, 2025 at 01:46:57PM +0100, Ahmad Khalifa wrote:
What should you do in that situation where you have a no-response MR?
Open a bug report pointing to the MR.
I just wanted to add that there is also an emotional aspect to this. I >offered help and was ignored. So as a result I feel rejected with a
general "if they don't want me they can get on without me" shrug.
Also I am aware that this is _nonsense_ - no response probably means
there simply was nobody - the feeling of being rejected is still there.
This seems like a good opportunity to point out that for non-trivial
changes, it's often a good idea to have a bug report (or issue, or
whatever this particular project uses) *anyway*, as a place to put a solution-neutral problem statement. The change that's being proposed
is often one of several ways to address a particular problem, and if
the maintainer is being asked to reverse-engineer the problem from
the proposed solution, that makes it harder (and more
time-consuming, and less likely to be done) to review the proposed
change and assess whether it's a good solution to the problem.
If maintainer bandwidth is the limiting factor in a particular
project (which it often is), then it's all the more important to
provide a good bug report (steps to reproduce / expected result /
actual result) or a user story for a new feature (who wants the
proposed feature and why) so that it's as easy and quick as possible
for the maintainer to understand that the proposed solution is a
good one....
I saw too many bug reports, that didn't had any reaction from the
package maintainer for years. This should be avoided.
What should you do in that situation where you have a no-response MR?
Hi.
I just wanted to add that there is also an emotional aspect to this. I offered help and was ignored. So as a result I feel rejected with a
general "if they don't want me they can get on without me" shrug.
Also I am aware that this is _nonsense_ - no response probably means
there simply was nobody - the feeling of being rejected is still there.
On Friday, May 30, 2025 8:03:40 AM Mountain Standard Time Joachim Zobel wrote:
Hi.
I just wanted to add that there is also an emotional aspect to this. I offered help and was ignored. So as a result I feel rejected with a
general "if they don't want me they can get on without me" shrug.
Also I am aware that this is _nonsense_ - no response probably means
there simply was nobody - the feeling of being rejected is still there.
By default, Salsa does not notify anyone of MRs. A package maintainer needs to go to
each Salsa repository and change their notification settings if they want to receive
notifications about MRs. Many package maintainers don’t even know they need to do that.
And, in the case of someone who maintains a lot of packages, it is easy to forget to do it
for one repository.
Bug reports, on the other hand, email the package maintainers automatically.
The bigger problem is probably that the above isn’t obvious to someone who is
contributing to Debian for the first time.
On Fri, 30 May 2025 10:46:04 -0700, Soren Stoutner wrote:needs
By default, Salsa does not notify anyone of MRs. A package maintainer
to go to each Salsa repository and change their notification settings if >they want to receive notifications about MRs.
I'm no salsa expert but I don't think this is correct: I'm pretty
sure I never went to all 4000 pkg-perl repos and messed with
notification settings in each of them, so I must have turned a knob
in my general settings once after salsa became a thing.
By default, Salsa does not notify anyone of MRs. A package maintainer needs to go to
each Salsa repository and change their notification settings if they want to receive
notifications about MRs.
On Friday, May 30, 2025 1:20:07 PM Mountain Standard Time gregor herrmann >wrote:
I'm no salsa expert but I don't think this is correct: I'm prettyYou can edit your notification settings for a team if you would like to >receive notifications for every project under that team namespace.
sure I never went to all 4000 pkg-perl repos and messed with
notification settings in each of them, so I must have turned a knob
in my general settings once after salsa became a thing.
That works
for small teams, but, as you mentioned, isn’t necessarily what most people are
looking for in large teams like Perl or Python.
You can also edit your general notification settings, but if you are a Debian >Developer (and thus a member of the Salsa Debian team) that would mean you >would receive notifications for every package under the Debian namespace (as >well as all the teams you belong to).
I just wanted to add that there is also an emotional aspect to this. I offered help and was ignored. So as a result I feel rejected with a
general "if they don't want me they can get on without me" shrug.
Also I am aware that this is _nonsense_ - no response probably means
there simply was nobody - the feeling of being rejected is still there.
On Fri, 30 May 2025 10:46:04 -0700, Soren Stoutner wrote:
By default, Salsa does not notify anyone of MRs. A package maintainer needs to go to
each Salsa repository and change their notification settings if they want to receive
notifications about MRs.
I'm no salsa expert but I don't think this is correct: I'm pretty sure
I never went to all 4000 pkg-perl repos and messed with notification
settings in each of them, so I must have turned a knob in my general
settings once after salsa became a thing.
Hi.
Since I am relatively new contributing to Debian (while doing software development for 3 decades). I thought it might be useful to share a bit
of the experience.
One fundamental thing is that you may not be welcomed simply because
there is nobody there welcoming you. Adding a merge request for a fix
may be pointless, because nobody will merge it. Reviewing is a certain
effort and nobody has time for that.
This is what I learned when trying to contribute to apache. I had read
they might need help and found out there is no way I can help them.
Note that I am not complaining, this is just the way it is.
It seems you really need to insist a bit if you want to help. I did
this with mosquitto and it worked.
My experience does however also include other things that worked. I did
a successful package salvation for libsml and I did a successful RFS
for vzlogger.
Sincerely,
Joachim
I'm glad you decided to reach out and share your experience instead of
going for a silent exit as I'm sure many others do in this situation <3.
As other have suggested, I personally would open a bug report and link to any >Merge Request (MR).
Oh, there is a new upstream version of vzlogger - hint - hint. ;-)
One fundamental thing is that you may not be welcomed simply because..
there is nobody there welcoming you. Adding a merge request for a fix
may be pointless, because nobody will merge it. Reviewing is a certain
effort and nobody has time for that.
My experience does however also include other things that worked. I did
a successful package salvation for libsml and I did a successful RFS
for vzlogger.
as the
maintenance of this specific package (apache2) relies mostly on two
specific people and not just any Debian Developer in general.
We should have a word for that, may be uncontributable does
fit.
Separately, may I also suggest some kind of timeout on the RFH bugs?
(oldest is about to turn 20 yo)
PS, similarly with RFP/ITP? (oldest RFP is about to turn 24!)
On 04/06/2025 11:39, Otto Kekäläinen wrote:
Lack of maintainer time is likely the reason why your >>https://salsa.debian.org/apache-team/apache2/-/merge_requests/43 went...
8 months without a response. Some people in this thread suggested
Separately, may I also suggest some kind of timeout on the RFH bugs?
(oldest is about to turn 20 yo)
They are one of the first things people would look at and seeing stale
bugs abandoned is like having a welcome mat that says "no one is
home".
PS, similarly with RFP/ITP? (oldest RFP is about to turn 24!)
Lack of maintainer time is likely the reason why your https://salsa.debian.org/apache-team/apache2/-/merge_requests/43 went...
8 months without a response. Some people in this thread suggested
the maintenance of this specific package (apache2) relies mostly on two specific people and not just any Debian Developer in general.
My guess was that the apache2 package is beyond receiving help.
This is a bad state (that quite some open source projects have
reached). We should have a word for that, may be uncontributable does
fit.
two specific people and not just any Debian Developer in general.
Also note that this package has an open RFH (Request For Help) [1],
We should just abolish and forbid RFPs, but in the current state
having old open RFPs works as designed IMO, saying that someone at
some time in the past wanted this software packaged for some reason.
For ITPs, we should indeed close ones that didn't have activity for
some specific period of time, or turn them into RFPs, and that's
already implemented in the bartm's scripts, though I'm not sure if
it's currently enabled or not.
On Wed, Jun 04, 2025 at 12:24:15PM +0100, Ahmad Khalifa wrote:
Separately, may I also suggest some kind of timeout on the RFH bugs?
(oldest is about to turn 20 yo)
Why?
If the team no longer wants help, they should just close it.
If the package was orphaned since then, ideally it should be closed, sure.
PS, similarly with RFP/ITP? (oldest RFP is about to turn 24!)
We should just abolish and forbid RFPs, but in the current state having
old open RFPs works as designed IMO, saying that someone at some time in
the past wanted this software packaged for some reason.
For ITPs, we should indeed close ones that didn't have activity for some specific period of time, or turn them into RFPs, and that's already implemented in the bartm's scripts, though I'm not sure if it's
currently enabled or not.
On Wed, Jun 04, 2025 at 12:24:15PM +0100, Ahmad Khalifa wrote:
On 04/06/2025 11:39, Otto Kekäläinen wrote:
Lack of maintainer time is likely the reason why your...
https://salsa.debian.org/apache-team/apache2/-/merge_requests/43 went
8 months without a response. Some people in this thread suggested
Separately, may I also suggest some kind of timeout on the RFH bugs?
(oldest is about to turn 20 yo)
They are one of the first things people would look at and seeing stale
bugs abandoned is like having a welcome mat that says "no one is home".
RFH bugs are kind of saying "help appreciated". That is still current
even after 20 years especially if no one is home.
if you want to add insult to injury, yes, then it's a perfect fit.
else I would suggest to find another word...
On 04/06/2025 12:39, Andrey Rakhmatullin wrote:
On Wed, Jun 04, 2025 at 12:24:15PM +0100, Ahmad Khalifa wrote:
Separately, may I also suggest some kind of timeout on the RFH bugs?
(oldest is about to turn 20 yo)
Why?
If the team no longer wants help, they should just close it.
If the package was orphaned since then, ideally it should be closed, sure.
Because they're misleading and waste contributor time.
Have you spent time going through a lot of the 50 RFH bugs?
They're full of spam and people being ignored.
I wonder if I should flag all of the 700+ packages that I am involved
in packaging as RFH, since I am in principle open for help.
I wonder if I should flag all of the 700+ packages that I am involved
in packaging as RFH, since I am in principle open for help.
I think this thread is wildly mixing up bugs that are tagged "help"
with packages that have an RFH Bug in WNPP. Could it be the case that
we're talking about different things?
Because they're misleading and waste contributor time.
They're both useful within a "recent" time span (say 6m or 1y).
After that, why keep it and have a long wnpp page that's not useful?
Debbugs will have a record of archived ones for future historians.
Quoting Ahmad Khalifa (2025-06-04 13:56:49)
On 04/06/2025 12:39, Andrey Rakhmatullin wrote:
On Wed, Jun 04, 2025 at 12:24:15PM +0100, Ahmad Khalifa wrote:Because they're misleading and waste contributor time.
Separately, may I also suggest some kind of timeout on the RFH bugs?
(oldest is about to turn 20 yo)
Why?
If the team no longer wants help, they should just close it.
If the package was orphaned since then, ideally it should be closed, sure. >>
Have you spent time going through a lot of the 50 RFH bugs?
They're full of spam and people being ignored.
I do, occationally, look through WNPP bugreports.
If you consider 1 hour old bugreports stale, then you are free to ignore older ones - noone told you to "waste" time on them.
Please, when talking in absolutes (like they're misleading") then please provide some more information on how you come to that conclusive
judgement on behalf of all thousands of Debian contributors.
Alternatively (because that might indeed be a waste of time), please
consider framing personal opinions as such, not as absolutes. Reason
I encourage you to do that is that I want to discuss with you, and I
find it easier to discuss when the conversation is easy to separate
opinion from fact.
On 04/06/2025 12:38, Marc Haber wrote:
On Wed, Jun 04, 2025 at 12:24:15PM +0100, Ahmad Khalifa wrote:
On 04/06/2025 11:39, Otto Kekäläinen wrote:
Lack of maintainer time is likely the reason why your...
https://salsa.debian.org/apache-team/apache2/-/merge_requests/43 went
8 months without a response. Some people in this thread suggested
Separately, may I also suggest some kind of timeout on the RFH bugs?
(oldest is about to turn 20 yo)
They are one of the first things people would look at and seeing stale
bugs abandoned is like having a welcome mat that says "no one is home".
RFH bugs are kind of saying "help appreciated". That is still current
even after 20 years especially if no one is home.
You're not hearing the message.
Joachim was mislead by an RFH. Even raised an MR and still got ignored.
I replied to an RFH bug, got ignored. Raised an MR and still got ignored
(my MR is only 5 months old, maybe still hope?).
Clearly the maintainers are not ready for help. But I wasted time on
that junk.
Le 2025-06-04 13:56, Ahmad Khalifa a écrit :
Because they're misleading and waste contributor time.
I don't think so, in general. Some RFH are not detailed enough, but many
are pretty clear about which kind of help is needed.
They're both useful within a "recent" time span (say 6m or 1y).
After that, why keep it and have a long wnpp page that's not useful?
Debbugs will have a record of archived ones for future historians.
I strongly disagree with this. Older RFP/ITP are often useful as they document prior interest, work and issues encountered while trying to
package the project. They can also be referenced in blocks:
relationships with other RFPs or bugs (e.g. request to update a package).
A review process with enough votes to keep or close stale RFPs could be interesting, but they should not be closed arbitrarily.
On 04/06/2025 13:50, Julien Plissonneau Duquène wrote:
Le 2025-06-04 13:56, Ahmad Khalifa a écrit :
Because they're misleading and waste contributor time.
I don't think so, in general. Some RFH are not detailed enough, but many are pretty clear about which kind of help is needed.
I have recent evidence of 2 newcomers complaining about wasting time on
RFH bugs. Do you have recent evidence of anyone benefiting from RFH bugs?
They're both useful within a "recent" time span (say 6m or 1y).
After that, why keep it and have a long wnpp page that's not useful?
Debbugs will have a record of archived ones for future historians.
I strongly disagree with this. Older RFP/ITP are often useful as they document prior interest, work and issues encountered while trying to package the project. They can also be referenced in blocks:
relationships with other RFPs or bugs (e.g. request to update a package).
A review process with enough votes to keep or close stale RFPs could be interesting, but they should not be closed arbitrarily.
I say this after working on the 4th oldest open ITP (#412060), it
reduces the visibility of what's important when you have a list of WNPP
bugs that's 4-digits long! No one is browsing through all that.
Quoting Ahmad Khalifa (2025-06-04 15:05:25)
On 04/06/2025 13:50, Julien Plissonneau Duquène wrote:
Le 2025-06-04 13:56, Ahmad Khalifa a écrit :
Because they're misleading and waste contributor time.
I don't think so, in general. Some RFH are not detailed enough, but many >>> are pretty clear about which kind of help is needed.
I have recent evidence of 2 newcomers complaining about wasting time on
RFH bugs. Do you have recent evidence of anyone benefiting from RFH bugs?
I do not have strong evince for RFH bugreports making newcomers happy.
I dare say that I dont find your evidence presented here strong either:
What you describe is newcomers being frustrated over not being able to
figure out out how to navigate the complexities of Debian. That is a
real problem, I agree with that. I disagree, however, that the solution
is to remove features in Debian that newcomers risk "wasting time" on.
On 04/06/2025 13:28, Jonas Smedegaard wrote:
Alternatively (because that might indeed be a waste of time), please
consider framing personal opinions as such, not as absolutes. Reason
I encourage you to do that is that I want to discuss with you, and I
find it easier to discuss when the conversation is easy to separate
opinion from fact.
Everything I say is my opinion. I have no formal role here.
The top message is only a polite suggestion.
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute"
2. Read https://www.debian.org/devel/join/, points you to "WNPP"
3. Go to https://www.debian.org/devel/wnpp/, browse the page
- At that point, you might not know what is adoption and orphans.
- Easiest thing to dip your toes in: "packages in need of help".
4. Go to the RFH page, https://www.debian.org/devel/wnpp/help_requested
5. Browse interesting bugs:
- Read the spam messages, maybe click on "this bug has spam"
(which I feel is a placebo)
- Look at other comments and interactions, no closed loop, no
conclusions
- Realize the bug is several years old
- Decide that it's beyond a newcomer's ability and move on
Of course, this is my opinion, but it's debian's primary journey from
the homepage.
As unfortunate as it may sound, some of this is actually true. The worse part is
if the newcomers want to chat, the official media in Debian for that is IRC, which
is hard to use and setup a bouncer and so on. I don't argue against making our tooling
better.
Do you seriously think that people who can't be bothered with finding
an IRC Client, pointing it to a server and joining a channel can be
bothered with Debian's other peculiariaties?
Will we have to change our packaging to writing just one file as other distributions do?
Joachim was mislead by an RFH. Even raised an MR and still got ignored.
I replied to an RFH bug, got ignored. Raised an MR and still got ignored
(my MR is only 5 months old, maybe still hope?).
As unfortunate as it may sound, some of this is actually true. The worse part is
if the newcomers want to chat, the official media in Debian for that is IRC, which
is hard to use and setup a bouncer and so on. I don't argue against making our tooling
better.
Do you seriously think that people who can't be bothered with finding an
IRC Client, pointing it to a server and joining a channel can be
bothered with Debian's other peculiariaties? Will we have to change our packaging to writing just one file as other distributions do?
As unfortunate as it may sound, some of this is actually true. The worse part is
if the newcomers want to chat, the official media in Debian for that is IRC, which
is hard to use and setup a bouncer and so on. I don't argue against making our tooling
better.
Do you seriously think that people who can't be bothered with finding an
IRC Client, pointing it to a server and joining a channel can be
bothered with Debian's other peculiariaties?
Marc Haber <mh+debian-devel@zugschlus.de> writes:
Do you seriously think that people who can't be bothered with finding an
IRC Client, pointing it to a server and joining a channel can be
bothered with Debian's other peculiariaties?
Yes? I refuse to use IRC because I find it annoying, and yet I seem to put
up with all of the rest of our peculiarities. :)
That would be nice and the work is already ongoing.
Maybe we should not direct newcomers to wnpp but instead
to a list of wishlist bugs tagged help (for newbies), and optionally
to a list of RC bugs tagged help (with the warning "not for the faint
of the heart").
Ahmad Khalifa <ahmad@khalifa.ws> writes:
Joachim was mislead by an RFH. Even raised an MR and still got ignored.
I replied to an RFH bug, got ignored. Raised an MR and still got ignored
(my MR is only 5 months old, maybe still hope?).
The most common (not the only) reason why packages file an RFH bug, in my experience, is that they are overwhelmed and unable to keep up with the packaging, which unfortunately is the same state that will lead them to
not responed to MRs. Unfortunately, often the ideal response to an RFH bug
is for an experienced Debian maintainer who wouldn't require much
assistance to offer to be co-maintainer directly. It's hard for a newcomer
to offer that type of help, through absolutely no fault of the newcomer.
Often RFH bugs are not filed until the situation is already dire and the existing maintainers may not be able to mentor newcomers or perform a
clean handoff to anyone other than an experienced Debian developer. This
is very much not ideal, and I wish this were not the case, but I suspect
that means that, at the moment, RFH is more useful as a flag for
experienced developers, and newcomers will find it easier to contribute to packages that, paradoxically, are not tagged as needing help.
On Wed, Jun 04, 2025 at 08:32:49AM -0700, Russ Allbery wrote:
Yes? I refuse to use IRC because I find it annoying, and yet I seem to
put up with all of the rest of our peculiarities. :)
Would you use Matrix, XMPP or some of those modern chat systems?
But something has to break the cycle. There is no daily standup or a
project manager to come in and ask for updates here :)
Debian has the RFA process, orphaning, submitting another RFH, etc...
I don't know, but seems no one wants to solve this and the status quo is fantastic as it is.
Amen to that. Maybe we should not direct newcomers to wnpp but instead
to a list of wishlist bugs tagged help (for newbies), and optionally to
a list of RC bugs tagged help (with the warning "not for the faint of
the heart").
I suggest to instead more narrowly guide them towards *recent* *RFP* >bugreports rather than WNPP bugreports in general.
On Wed, Jun 04, 2025 at 08:31:09AM -0700, Russ Allbery wrote:
The most common (not the only) reason why packages file an RFH bug, in my >experience, is that they are overwhelmed and unable to keep up with the >packaging, which unfortunately is the same state that will lead them to
not responed to MRs. Unfortunately, often the ideal response to an RFH bug >is for an experienced Debian maintainer who wouldn't require much >assistance to offer to be co-maintainer directly. It's hard for a newcomer >to offer that type of help, through absolutely no fault of the newcomer.
Often RFH bugs are not filed until the situation is already dire and the >existing maintainers may not be able to mentor newcomers or perform a
clean handoff to anyone other than an experienced Debian developer. This
is very much not ideal, and I wish this were not the case, but I suspect >that means that, at the moment, RFH is more useful as a flag for >experienced developers, and newcomers will find it easier to contribute to >packages that, paradoxically, are not tagged as needing help.
Amen to that. Maybe we should not direct newcomers to wnpp but instead
to a list of wishlist bugs tagged help (for newbies), and optionally to
a list of RC bugs tagged help (with the warning "not for the faint of
the heart").
I suggest to instead more narrowly guide them towards *recent* *RFP* >bugreports rather than WNPP bugreports in general.
It will not surprise me if some newcomers find recent RFP bugreports a
total waste of their time, but I know from experience that some do not.
On Wed, Jun 04, 2025 at 06:22:49PM +0200, Jonas Smedegaard wrote:
Amen to that. Maybe we should not direct newcomers to wnpp but instead
to a list of wishlist bugs tagged help (for newbies), and optionally to
a list of RC bugs tagged help (with the warning "not for the faint of
the heart").
I suggest to instead more narrowly guide them towards *recent* *RFP* >bugreports rather than WNPP bugreports in general.
I think suggesting people to create and maintain packages that they will
not be using themselves is a bad idea.
Ahmad Khalifa <ahmad@khalifa.ws> writes:
But something has to break the cycle. There is no daily standup or a
project manager to come in and ask for updates here :)
Debian has the RFA process, orphaning, submitting another RFH, etc...
I don't know, but seems no one wants to solve this and the status quo is
fantastic as it is.
I think you are reading lack of interest or opposition into a situation
where the primary problem is lack of resources.
I would love to solve this. I do not like the status quo. I certainly
don't think the status quo is fantastic. I'm also massively behind on the packages that I already agreed to be responsible for and other Debian work that I am supposed to be doing, and given that my day job exhausts nearly
all of my available energy for high-interaction discussions, I don't have
the bandwidth to mentor newcomers. I suspect this is a very common problem among experienced Debian maintainers.
This says bad things about the project's sustainability and I think
everyone knows that. No one thinks the situation is good. But knowing that things need to improve does not create the time and energy required to improve them; in fact, in my experience, it sadly often does the opposite.
It's a trap and I'm not sure how to get out of it, but the problem isn't
lack of caring. It's that we have to figure out a way to get out of the
trap without piling more work on people who can't handle more and will
start dropping even more things if people insist.
Hi,
On Wed, Jun 04, 2025 at 06:22:49PM +0200, Jonas Smedegaard wrote:
I suggest to instead more narrowly guide them towards *recent* *RFP*
bugreports rather than WNPP bugreports in general.
It will not surprise me if some newcomers find recent RFP bugreports a
total waste of their time, but I know from experience that some do not.
Maintaining a package is a significant commitment. I'd prefer newcomers
to fix bugs instead. There it doesnt hurt when they vanish after a few months.
And, when you "just" fix bugs, you don't have to the next frustrating threadmill that we offer: looking for a sponsor.
And, when you "just" fix bugs, you don't have to the next
frustrating threadmill that we offer: looking for a sponsor.
What does this line mean?
On Wed, Jun 04, 2025 at 06:13:57PM +0100, Ahmad Khalifa wrote:
And, when you "just" fix bugs, you don't have to the next frustrating
threadmill that we offer: looking for a sponsor.
What does this line mean?
That getting a sponsor as a new contributor, especially for a new
package, is frustrating and often very long.
I just thought there would have been a much higher willingness to
discuss how to improve things. I was wrong.
This is not different from other projects, except that debian has a
lower percentage of paid contributors. They all solve it by prioritising important things, dropping less important things, etc... I don't like
it, but reality!
Basic prioritisation is where the idea of timing out older WNPP issues
comes from.
The other point is that if debian can't handle its current workload, why
is debian inviting people to package 20 year old projects that don't
even have an upstream page.
Anyway, I learned to ignore most WNPP pages now.
Amen to that. Maybe we should not direct newcomers to wnpp but instead
to a list of wishlist bugs tagged help (for newbies), and optionally to >> >> a list of RC bugs tagged help (with the warning "not for the faint of
the heart").
I suggest to instead more narrowly guide them towards *recent* *RFP*
bugreports rather than WNPP bugreports in general.
I think suggesting people to create and maintain packages that they will
not be using themselves is a bad idea.
I think so too: We should pick work that we can find passion for.
Sorry if that was not obvious.
I think the problem you're running into there is that people perceive
closing old WNPP issues as making the information in them disappear. I'm
not sure that's quite accurate, but it certainly makes it much harder to >find.
Am Mittwoch, dem 04.06.2025 um 17:10 +0100 schrieb Ahmad Khalifa:
But something has to break the cycle. There is no daily standup or a
project manager to come in and ask for updates here :)
This is actually an important point. The usually means that make a
project socially work are not there.
Not that we should have daily standups :-)
On 04/06/2025 13:50, Julien Plissonneau Duquène wrote:
Le 2025-06-04 13:56, Ahmad Khalifa a écrit :
Because they're misleading and waste contributor time.
I don't think so, in general. Some RFH are not detailed enough, but many are pretty clear about which kind of help is needed.
I have recent evidence of 2 newcomers complaining about wasting time on
RFH bugs. Do you have recent evidence of anyone benefiting from RFH bugs?
They're both useful within a "recent" time span (say 6m or 1y).
After that, why keep it and have a long wnpp page that's not useful?
Debbugs will have a record of archived ones for future historians.
I strongly disagree with this. Older RFP/ITP are often useful as they document prior interest, work and issues encountered while trying to package the project. They can also be referenced in blocks:
relationships with other RFPs or bugs (e.g. request to update a package).
A review process with enough votes to keep or close stale RFPs could be interesting, but they should not be closed arbitrarily.
I say this after working on the 4th oldest open ITP (#412060), it
reduces the visibility of what's important when you have a list of WNPP
bugs that's 4-digits long! No one is browsing through all that.
We should just abolish and forbid RFPs
Do you seriously think that people who can't be bothered with finding an
IRC Client, pointing it to a server and joining a channel can be
bothered with Debian's other peculiariaties?
Will we have to change our
packaging to writing just one file as other distributions do?
On 04/06/2025 13:28, Jonas Smedegaard wrote:
Quoting Ahmad Khalifa (2025-06-04 13:56:49)
On 04/06/2025 12:39, Andrey Rakhmatullin wrote:
On Wed, Jun 04, 2025 at 12:24:15PM +0100, Ahmad Khalifa wrote:Because they're misleading and waste contributor time.
Separately, may I also suggest some kind of timeout on the RFH bugs? >>>>> (oldest is about to turn 20 yo)
Why?
If the team no longer wants help, they should just close it.
If the package was orphaned since then, ideally it should be closed, sure. >>>
Have you spent time going through a lot of the 50 RFH bugs?
They're full of spam and people being ignored.
I do, occationally, look through WNPP bugreports.
If you consider 1 hour old bugreports stale, then you are free to ignore
older ones - noone told you to "waste" time on them.
Please, when talking in absolutes (like they're misleading") then please
provide some more information on how you come to that conclusive
judgement on behalf of all thousands of Debian contributors.
Alternatively (because that might indeed be a waste of time), please
consider framing personal opinions as such, not as absolutes. Reason
I encourage you to do that is that I want to discuss with you, and I
find it easier to discuss when the conversation is easy to separate
opinion from fact.
Everything I say is my opinion. I have no formal role here.
The top message is only a polite suggestion.
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute"
2. Read https://www.debian.org/devel/join/, points you to "WNPP"
3. Go to https://www.debian.org/devel/wnpp/, browse the page
- At that point, you might not know what is adoption and orphans.
- Easiest thing to dip your toes in: "packages in need of help".
4. Go to the RFH page, https://www.debian.org/devel/wnpp/help_requested
5. Browse interesting bugs:
- Read the spam messages, maybe click on "this bug has spam"
(which I feel is a placebo)
- Look at other comments and interactions, no closed loop, no
conclusions
- Realize the bug is several years old
- Decide that it's beyond a newcomer's ability and move on
Of course, this is my opinion, but it's debian's primary journey from
the homepage.
And when you say "pointing it to a server" the pre-requisite here is someone should "own" a server
for that.
You may argue that a contributor can find "someone" to setup a bouncer for them. But this is
pretty difficult if no-one around you does any of that.
Not much, in my experience, because the only reliable way to find WNPP bugs for given software is, in my experience, Google.
Not much, in my experience, because the only reliable way to find WNPP >bugs
for given software is, in my experience, Google.
And soon it will be s#Google#AI#. I think this tells more about you than
about Debian or WNPP bugs.
I search WNPP a fair amount, but I never use a search engine to do so.
I typically load one of these two pages and use my browser’s find-on-page >functionality to search them.
https://www.debian.org/devel/wnpp/being_packaged
https://www.debian.org/devel/wnpp/requested
On Wed, Jun 04, 2025 at 11:51:37PM +0500, Andrey Rakhmatullin wrote:bugs
Not much, in my experience, because the only reliable way to find WNPP
for given software is, in my experience, Google.
And soon it will be s#Google#AI#. I think this tells more about you than about Debian or WNPP bugs.
On Wednesday, June 4, 2025 6:05:25 AM Mountain Standard Time Ahmad Khalifa wrote:
On 04/06/2025 13:50, Julien Plissonneau Duquène wrote:
Le 2025-06-04 13:56, Ahmad Khalifa a écrit :
Because they're misleading and waste contributor time.
I don't think so, in general. Some RFH are not detailed enough, but many >>> are pretty clear about which kind of help is needed.
I have recent evidence of 2 newcomers complaining about wasting time on
RFH bugs. Do you have recent evidence of anyone benefiting from RFH bugs?
Yes, I recently adopted Courier (and related packages) because it had a RFH bug.
They're both useful within a "recent" time span (say 6m or 1y).
After that, why keep it and have a long wnpp page that's not useful?
Debbugs will have a record of archived ones for future historians.
I strongly disagree with this. Older RFP/ITP are often useful as they
document prior interest, work and issues encountered while trying to
package the project. They can also be referenced in blocks:
relationships with other RFPs or bugs (e.g. request to update a package). >>>
A review process with enough votes to keep or close stale RFPs could be
interesting, but they should not be closed arbitrarily.
I say this after working on the 4th oldest open ITP (#412060), it
reduces the visibility of what's important when you have a list of WNPP
bugs that's 4-digits long! No one is browsing through all that.
No, but I search through it frequently.
I typically load one of these two pages and use my browser’s find-on-page >functionality to search them.
https://www.debian.org/devel/wnpp/being_packaged
https://www.debian.org/devel/wnpp/requested
I have recent evidence of 2 newcomers complaining about wasting time on
RFH bugs. Do you have recent evidence of anyone benefiting from RFH bugs?
Yes, I recently adopted Courier (and related packages) because it had a RFH >bug.
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute"
2. Read https://www.debian.org/devel/join/, points you to "WNPP"
Of course, this is my opinion, but it's debian's primary journey from
the homepage.
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute"
2. Read https://www.debian.org/devel/join/, points you to "WNPP"
Of course, this is my opinion, but it's debian's primary journey from
the homepage.
agree, it's pretty bad journey. Steps 1 and 2 should point to a wiki
page, the package tracker and/or the bts as ways to contribute for newcomers.
On Thu, Jun 05, 2025 at 08:51:38PM +0100, Richard Lewis wrote:
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute"
2. Read https://www.debian.org/devel/join/, points you to "WNPP"
Of course, this is my opinion, but it's debian's primary journey from
the homepage.
agree, it's pretty bad journey. Steps 1 and 2 should point to a wiki
page, the package tracker and/or the bts as ways to contribute for newcomers.
What wiki page?
The package tracker and/or the bts for which package?
Looks like you took over maintainership completely. Not that you
provided help and collaborated with the original maintainer.
This looks more like a package that should have been orphaned long ago
when it was removed from testing. The RFH just helped you stumble upon it.
Andrey Rakhmatullin <wrar@debian.org> writes:
On Thu, Jun 05, 2025 at 08:51:38PM +0100, Richard Lewis wrote:
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute"
2. Read https://www.debian.org/devel/join/, points you to "WNPP"
Of course, this is my opinion, but it's debian's primary journey from
the homepage.
agree, it's pretty bad journey. Steps 1 and 2 should point to a wiki
page, the package tracker and/or the bts as ways to contribute for newcomers.
What wiki page?
https://wiki.debian.org/HelpDebian is the closest i have found so
far. it is lacking in specific suggestions, but seems to tick some of
the right boxes, what do you think?
The package tracker and/or the bts for which package?
for any package that the newcomer is interested in helping
On Thursday, June 5, 2025 10:53:17 AM Mountain Standard Time Ahmad Khalifa wrote:
Looks like you took over maintainership completely. Not that you
provided help and collaborated with the original maintainer.
This looks more like a package that should have been orphaned long ago
when it was removed from testing. The RFH just helped you stumble upon it.
The situation was a little more nuanced than that. It is correct to say that the package should have been orphaned. By the time I started looking at it, the prior maintainer was completely unresponsive. I attempted to contact him several times offering to co-maintain the package, but never received a response.
My interest in the package was that I use it myself and it was not in good shape. I did not find the package by looking directly at RFH bugs, but rather
by looking at the packages’ tracker page:
https://tracker.debian.org/pkg/courier
One of the nice things about tracker is that it prominently lists open RFH bugs in the top center. I went to the page to determine why the package was no longer in testing and discovered that it would soon be entirely removed from Debian due to serious bugs. The RFH bug indicated that at some point in the past, before the previous maintainer had become completely unresponsive, he had been willing to accept help maintaining the package.
When I was not successful in contacting the previous maintainer, I adopted the
package.
If there had not been an RFH bug, I would have had to do a formal salvage process, which I might not have started or which might have taken longer. The
RFH bug was a nice open door saying, “Come on in”. It meant that I could start working on the package while waiting to hear back from the maintainer, (which never happened). If it hadn’t been for the RFH, Courier would likely
not have made it into trixie.
This is a very complex piece of software with a lot of non-trivial open bugs and some antiquated package design. Many people use the software in ways I don’t. Making changes too quickly would likely end up unintentionally breaking production systems. However, I was able to safely clean it up enough
to get it into trixie. Going forward, I expect it will take about 2 years to full clean up the package and all outstanding bugs.
As has already been mentioned in this thread, RFH bugs are often filed when maintainers are looking for experienced co-maintainers, usually with very difficult packages, which are often in bad shape. As such, they should probably be understood as Request For Experienced Developers To Help (but RFEDTH is a little long). They are probably the very last thing that a new contributor would be prepared to tackle. It might be best to adjust our documentation to not steer new contributors towards them, but rather towards the debian-mentors mailing list, where people can point them to some beginning
tasks if they ask.
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute" >>>>>2. Read https://www.debian.org/devel/join/, points you to "WNPP"
Of course, this is my opinion, but it's debian's primary journey from >>>>>the homepage.
agree, it's pretty bad journey. Steps 1 and 2 should point to a wiki >>>>page, the package tracker and/or the bts as ways to contribute for newcomers.
What wiki page?
https://wiki.debian.org/HelpDebian is the closest i have found so
far. it is lacking in specific suggestions, but seems to tick some of
the right boxes, what do you think?
My 2 cents on where newcomers should go:
https://salsa.debian.org/explore/projects?sort=stars_desc >https://salsa.debian.org/explore/groups?sort=created_asc
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute"
2. Read https://www.debian.org/devel/join/, points you to "WNPP"
Of course, this is my opinion, but it's debian's primary journey from
the homepage.
agree, it's pretty bad journey. Steps 1 and 2 should point to a wiki >>>page, the package tracker and/or the bts as ways to contribute for newcomers.
What wiki page?
https://wiki.debian.org/HelpDebian is the closest i have found so
far. it is lacking in specific suggestions, but seems to tick some of
the right boxes, what do you think?
The package tracker and/or the bts for which package?
for any package that the newcomer is interested in helping
Marc Haber <mh+debian-devel@zugschlus.de> writes:
On Wed, Jun 04, 2025 at 08:32:49AM -0700, Russ Allbery wrote:
Yes? I refuse to use IRC because I find it annoying, and yet I seem to
put up with all of the rest of our peculiarities. :)
Would you use Matrix, XMPP or some of those modern chat systems?
No, which, fair point, you were making a point in context about adopting those new systems and I lost the context. Sorry about that; my message
wasn't very useful.
Sadly I'm not sure there's a great option for real-time chat that both follows our free software principles and would reach newcomers where they probably are. The option that would maximize outreach is probably Discord, which has obvious issues.
On Thu, Jun 05, 2025 at 09:48:47PM +0100, Richard Lewis wrote:
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute" >>>>> 2. Read https://www.debian.org/devel/join/, points you to "WNPP"
Of course, this is my opinion, but it's debian's primary journey from >>>>> the homepage.
agree, it's pretty bad journey. Steps 1 and 2 should point to a wiki >>>>page, the package tracker and/or the bts as ways to contribute for newcomers.
What wiki page?
https://wiki.debian.org/HelpDebian is the closest i have found so
far. it is lacking in specific suggestions, but seems to tick some of
the right boxes, what do you think?
Is it really better than https://www.debian.org/intro/help which I
usually use and which it already links to?
The package tracker and/or the bts for which package?
for any package that the newcomer is interested in helping
This suggestion makes no sense to me.
my "suggestion", if you can call it that, is that historitically debian
has tried to direct people to "package something new", but this doesnt
seem to work very well any more - most things are already packages or
are not suitable.
Consider this random new contributor's experience:
1. Go to https://www.debian.org/, click on "Get Involved, Contribute" >>>>>> 2. Read https://www.debian.org/devel/join/, points you to "WNPP"
Of course, this is my opinion, but it's debian's primary journey from >>>>>> the homepage.
agree, it's pretty bad journey. Steps 1 and 2 should point to a wiki >>>>>page, the package tracker and/or the bts as ways to contribute for newcomers.
What wiki page?
https://wiki.debian.org/HelpDebian is the closest i have found so
far. it is lacking in specific suggestions, but seems to tick some of
the right boxes, what do you think?
Is it really better than https://www.debian.org/intro/help which I
usually use and which it already links to?
no i think https://www.debian.org/intro/help is even better than the
wiki page. but that is not listed on https://www.debian.org/devel/join/
i dont think either are particularly clear for newcomers. i really
struggle to understand how i can help from either to be honest.
The package tracker and/or the bts for which package?
for any package that the newcomer is interested in helping
This suggestion makes no sense to me.
my "suggestion", if you can call it that, is that historitically debian
has tried to direct people to "package something new"
I think a better way for newcomers who want to do "development" to get >involved in debian is to pick an existing package (or team?) that they
use and help make it better.
The package tracker and in the bts which
have a large number of "things that could be better" that no-one has
fixed but someone thought should be. By helping fix these issues it's
quite easy to get drawn into debian, and you can learn as you go. And -
i would suggest - this actually helps debian more than yet another
package. Obviously this still depends on existing maintainers accepting >contributions, but i tihnk it's a better experience to discuss how to
fix a bug than to try and learn an esoteric packaging workflow.
Hi,
On Wed, Jun 04, 2025 at 06:22:49PM +0200, Jonas Smedegaard wrote:
I suggest to instead more narrowly guide them towards *recent* *RFP*
bugreports rather than WNPP bugreports in general.
It will not surprise me if some newcomers find recent RFP bugreports a
total waste of their time, but I know from experience that some do not.
Maintaining a package is a significant commitment. I'd prefer newcomers to fix bugs instead. There it doesnt hurt when they vanish after a few months.
And, when you "just" fix bugs, you don't have to the next frustrating threadmill that we offer: looking for a sponsor.
Maintaining a package is a significant commitment. I'd preferAlthough just fixing bugs has its own frustrations.
newcomers to fix bugs instead. There it doesnt hurt when they vanish
after a few months.
And, when you "just" fix bugs, you don't have to the next
frustrating threadmill that we offer: looking for a sponsor.
I mostly used to write "works for me" fixes and now I look to
submitting to upstream first and go to the BTS if I can't quickly see
how to open a bug/MR upstream.
There's a patch for apt-cacher-ng for a multi-year old bug that I know
is in use in at least three large deployments due to private emails.
The patch could do with some TLC, the comments in particular reflect
my journey of understanding rather than the final state, and had I got >prompt feedback I'd have done that work but a year plus later I'd have
to spend time reminding myself just what was going on - at this point
anyone is as well placed as me to do that cleanup - and I'm not sure
I'd bother, if there's ever a new release I'll get an alert and if
there isn't well "it works for me".
A while back I fixed a number of FTBFS and usr-merge bugs in packages
I care about. Those were merged, but as NMU which I found out by
accident when I went looking at what was going on months later. TBH I
was thinking "why bother?" although actually it should have been a
positive experience.
spending hours reading documentation on how to
do this officially would feel annoying when I already have a working
and deployed package locally.
I think so too: We should pick work that we can find passion for.
Since 2013 I'm preaching on every DebConf I attended in each of my
Debian Med related events about
https://salsa.debian.org/med-team/community/MoM/-/wikis/Mentoring-of-the-Month-(MoM)
The idea is to help newcomers to package what they need. I wished other teams would try to adopt this method.
As a very new contributor to Debian as part of the Google Summer of Code (GSoC) '25 program I can only second Andreas' point. Packages / package teams who are willing/have the bandwith to mentor newcomers are most certainly a great starting point for newbies. Is there an easy way to
find those mentorship opportunities in Debian (outside of dedicated programs like GSoC)? IMHO these should be "advertised" to newcomers.
I have started a new wiki page for this purpose
https://wiki.debian.org/Newcomers
I have started a new wiki page for this purpose
https://wiki.debian.org/Newcomers
All teams can and should welcome and mentor newcomers
eg the multimedia team (which I'm a proud member of) is really not very much of a "team" (with people working *together* on a bunch of packages), at least in my impression (which might be totally off).
in practice, it is more of a "lowNMU" team, and that's it.
I don't really see how there would be enough bandwidth to do actual mentoring and stuff.
other people might have similar experiences with other teams.
Sorry, yes, Debian discussions around workflow are often frustrating
because part of the discussion is usually at least a mild request
for existing maintainers to change their current workflows, and when
people feel overwhelmed, changing workflows often feels particularly draining. Sometimes we manage to steer the discussion away from
existing maintainers changing how they currently do things towards
creating recommended best practices for *new* maintainers, and those
are often less fraught.
I think the other reason why these discussions are a bit frustrating
is that there seems to be an implicit assumptions that all
contributions from newcomers *must* be good,
and MR's must be reviewed
ASAP or it's an indication that the project or package is moribund.
Sometimes code contributions are just bad quality. They might
introduce bugs; or they might make the code unmaintable; or in the
case of Debian packaging, the patch might be better sent upstream for >evaluation.
Am 14. Juni 2025 16:18:40 MESZ schrieb Theodore Ts'o <tytso@mit.edu>:
I think the other reason why these discussions are a bit frustrating
is that there seems to be an implicit assumptions that all
contributions from newcomers *must* be good,
dunno.
I think the implicit assumption is that "new *contributors* are good" (which I can relate to), not necessarily that their contributions are of outstanding quality.
we all started out stupid and learned but doing...
however, submitting a "not acceptable" contribution need not necessarily be a featuring
I think the other reason why these discussions are a bit frustrating
is that there seems to be an implicit assumptions that all
contributions from newcomers *must* be good,
dunno.
I think the implicit assumption is that "new *contributors* are
good" (which I can relate to), not necessarily that their
contributions are of outstanding quality.
The obvious counter example here is Jia Tan[1][2]. Another more recent example is the "X11Libre" developer who had to get ejected from
Freedesk.org after contributing a huge number of questionable
commits[3].
[1] https://cyberscoop.com/open-source-security-trust-xz-utils/
[2] https://www.wired.com/story/jia-tan-xz-backdoor/
[3] https://www.phoronix.com/news/X.Org-Server-Lots-Of-Reverts
If some debian developer wants to make it to be their special mission
to help out new contributors, and be that ombudsperson to review
patches, and tell them how "no really, you need to follow the
upstream's documented requirements for code submissions[4]", or "gee,
it appears that your code doesn't even build; I suggest you try to test-compile your patch and run it through the project's regtression
suite", or, "Ah, your patch seems to allow shell scripts from the
network to be blindly run on the target system", great!
This is why careful review of patches is super important, and why I am personally very dubious of the Forge Pull Request model. Unless
people are super, super careful about code review, a "git pull" could
very easily pull in some malicious code. Maintainers need to be super paranoid, especially for code contributions coming from an unknown new contributor.
Just for myself, I find that e-mail review is just more effective; I
can review patches much more easily when I am partially off-line, such
as while on an airplane, or on a cruise ship. It's much more
difficult to do this via a web-based Forge system.
After a `git fetch` or a `git pull` it is very easy to review what
the change is or diff it against the current main branch. There are
a bunch of tolls, including of course the usual gitk and `git
difftool --dir-diff` + Meld.
Indeed, Forge's don't work offline, but you could git pull/fetch the
branch before you board an airplane? And then after review git merge
locally? And once you are off the flight run git push and all modern
Forges will automatically detect that the commit landed on main and
close all related pull requests and issues.
After a `git fetch` or a `git pull` it is very easy to review what
the change is or diff it against the current main branch. There are
a bunch of tolls, including of course the usual gitk and `git
difftool --dir-diff` + Meld.
The problem is that it's also very easy *not* to do a very careful
review. And this is where I really object to the pressure campaign to
tell package maintainers that they have some obligation to review pull requests from new contributors post-haste, or they are a bad, bad
person.
Indeed, Forge's don't work offline, but you could git pull/fetch the
branch before you board an airplane? And then after review git merge locally? And once you are off the flight run git push and all modern
Forges will automatically detect that the commit landed on main and
close all related pull requests and issues.
Reviewing all of the changes via a "git diff FETCH_HEAD" is far more difficult and much easier to miss things than reviewing each patch
If someone sends me a gargantuan commits with dozens of logical
changes, whether it's in a pull request or a singleton message, I
*will* just reject the change outright or just ignore the change until
I have a huge amount of time.
This is why e-mail review of dozens of patches is just far more
convenient, and more secure, than doing a git pull and then trying to
review the damage using "git diff FETCH_HEAD"
In general, no. Using a forge introduces numerous opportunities for race conditions (reviewing a PR and having someone else update it before you
merge it, for instance) and compromises of other systems (the forge shows
you something different than what it would merge when you press the merge button). It is then possible to configure the forge to eliminate those
again, but it has to be done carefully and nearly all users of forges do
not do so.
Sure it is more convenient to, you as you most likely have some well optimized Emacs email setup going on. But more secure? Surely signed
commits and a system that tracks real git commits and who pushed what
from where is more secure than plain-text patches in e-mail.
A person with your seniority surely knows better commands to use than
review plain diffs. Naturally, it is better to review using the git
log -p output that shows each commit message individually and related changes.
Sure it is more convenient to, you as you most likely have some well optimized Emacs email setup going on. But more secure? Surely signed
commits and a system that tracks real git commits and who pushed what
from where is more secure than plain-text patches in e-mail.
Note that I am not claiming that the current UX of e.g. GitLab is
perfect. There are many things to improve, for example the default
MR review vies should show all commit message as an expanded list
instead of hiding them. My point here is that your e-mail setup is
something you have optimized for years. I don't think it is
something the next generation of devs is going to adopt.
fetch CI statuses from external APIs...
If you are concerned about the PR being updated without you noticing it
(very unlikely), you can git pull it locally, review locally and git
push on mainline, which with all modern Forges will automatically close
the PR/MR/issue.
Using real git commits with SHA hashes, signatures, SSH key protected
pulls and pushes, multiple server logs on who did what etc is easily
more secure than using plaintext emails.
The big question here you seem to avoid commenting on is what is the
workflow you expect the next generation to seriously adopt?
If you are concerned about the PR being updated without you noticing it (very unlikely), you can git pull it locally, review locally and git
push on mainline, which with all modern Forges will automatically close
the PR/MR/issue.
Yes, that would also work. That's not what people using forges *actually
do*, though, which I believe was Ted's point. Nor do people advocate
forges because they're advocating that workflow; quite to the contrary, people who want others to use forges generally want them to review MRs directly on the forge for a host of other reasons.
...Using real git commits with SHA hashes, signatures, SSH key protected
pulls and pushes, multiple server logs on who did what etc is easily
more secure than using plaintext emails.
Ted's workflow doesn't rule out signatures, SSH-key-protected pushes, and other similar security properties. I suspect it usually terminates them at Ted (the reviewer) rather than the original author, which has pluses and minuses.
The big question here you seem to avoid commenting on is what is the workflow you expect the next generation to seriously adopt?
I didn't comment on that because I don't have an opinion on it. I only commented about the security analysis that you did, which I believe is
wrong.
There is a tendency in these discussions to assert that one's preferred workflow is strictly better on every possible axis, there are no
I know a lot of veterans in the industry have very good e-mail setups
and are very efficient in reviewing patches by e-mail. I am not asking
you to abandon it. You should do what you want.
The big question here you seem to avoid commenting on is what is[...]
the workflow you expect the next generation to seriously adopt?
I just merged a first-time contributor MR in https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/614,
and I think it was good quality. I don't think that people who use MRs
are noobs and their quality is in general bad, and I don't think this
barrier of e-mail-only really helps drive up contribution quality.
over a mailing list. And people who uploaded the patch to a Forge
won't see the comments in the Forge's pull request. If they don't read e-mail, then they won't see the replies --- just as people who don't monitor salsa won't see the pull requests. Oh, well....
Sure it is more convenient to, you as you most likely have some well optimized Emacs email setup going on. But more secure? Surely signed commits and a system that tracks real git commits and who pushed what
from where is more secure than plain-text patches in e-mail.
People aren't using signed commits on most Forges. And even they do,
they signanture doesn't mean much when they come from newbie
contributors. The main issue, though, is that you *should* be doing line-by-line patch review, and so the authentication comes from the
person doing the review assuring that the patch is good, and has no
bugs, either introduced accidentally or maliciously.
And for the record, no, I don't use Emacs to read my e-mail. I happen
to use mutt, with fairly generic settings.
So what if we have gazillions of low-quality devs that don't know how
to program except by asking a LLM to write code for them, and who
refuse to use e-mail? I don't care about them. What I care about the absolute number of highly skilled developers who can do proper
architectural design, writes regression tests, and know how to
maintain stable ABI so that they can maintain a shared library
initerface for ever a decade without breaking backwards compatibility.
And so far, I haven't seen a decline in the number of people are
becoming new kernel developers, with our "archiac" workflow
requirements. So personally, I'm not terribly worried about "the next generation of developers". I just care about the next generation of
highly qualified developers. And I find it hard to believe that these
people won't be using e-mail, but only using Instagram or TikTok ---
and Forges, and are not capable of using any other workflow.
[...]
The big question here you seem to avoid commenting on is what is[...]
the workflow you expect the next generation to seriously adopt?
Perhaps playing devil's advocate a bit, but why do you assume that
young people are incapable of learning and using working,
established systems? Having worked closely with new contributors on
various projects, many fresh out of school, I think you do them a
disservice in implying that they will only use flashy new
technologies.
But I am worried about the next generation of open source
contributors. I have never seen anyone under 40 e.g. use Emacs to read
email.
I know that not all the people who prefer to use an email patch[...]
workflow believe what is being discussed above. Some prefer it
because it fits their taste or is what they are used to.
Regarding working with patch submissions, I greatly prefer an MR.
I almost never merge a request without requesting changes, or at
least clarification. Having the ability to highlight specific
lines of code and start a thread discussing them, and having
several threads going at once for different parts of the code,
each of which can independently be marked as completed, is a
workflow that I would find difficult to replicate in email.
I've seen some of this same sentiment in discussions about
bugs.debian.org. People think that having a hard-to-use bug tracker
will keep the "noobs" away and maintain a higher quality of bug
reports and discussions among the people who do pass the bar of
figuring out how to use it. I think this is a very elitist attitude.
Also, I see a lot of bugs that have low-quality participation exactly
because participants got past the barrier of figuring out how to
interact with it, but didn't figure out how to do it properly and for
example attach metadata on what is the upstream bug report URL
correctly.
Also, when you went from discussing the utility of reviews in e-mail
vs Forges to talking about people who don't use e-mail *at all*, and
then mention software development driven by TikTok and Instagram, I
think this discussion probably has seen the best arguments and we can conclude here.
You are aware that you can send e-mail to a MR on GitHub and to a PR
on GitLab and pretty much every Forge supports both email
notifications and email replies?
The only feature currently missing in GitLab is to have the
notification of a new MR have the actual patch attached so people
using e-mail only can read it and reply directly.
Yes, but as soon as you get the second or third contribution, the
ability to attribute the submissions to the same submitter with
higher guarantees will start to matter.
I just merged a first-time contributor MR in https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/614,
and I think it was good quality. I don't think that people who use MRs
are noobs and their quality is in general bad, and I don't think this
barrier of e-mail-only really helps drive up contribution quality.
The big question here you seem to avoid commenting on is what is the
workflow you expect the next generation to seriously adopt? Any plans
to write a new e-mail client and then ask e.g. university students to
start learning it?
On 2025-06-17 20:31:31 +0300 (+0300), Otto Kekäläinen wrote:
[...]
The big question here you seem to avoid commenting on is what is[...]
the workflow you expect the next generation to seriously adopt?
Perhaps playing devil's advocate a bit, but why do you assume that
young people are incapable of learning and using working,
established systems? Having worked closely with new contributors on
various projects, many fresh out of school, I think you do them a
disservice in implying that they will only use flashy new
technologies.
I've seen some of this same sentiment in discussions about
bugs.debian.org. People think that having a hard-to-use bug tracker
will keep the "noobs" away and maintain a higher quality of bug
reports and discussions among the people who do pass the bar of
figuring out how to use it. I think this is a very elitist attitude.
I just merged a first-time contributor MR in >https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/614,
and I think it was good quality. I don't think that people who use MRs
are noobs and their quality is in general bad,
and I don't think this
barrier of e-mail-only really helps drive up contribution quality.
When I compare my experiences of top-tier developers who I have seen
doing both e-mail reviews and in-browser reviews, in my experience
their in-browser reviews end up being much more productive and
scalable as they can have rich context information that is always
up-to-date, can track statuses and in general juggle many more reviews
in parallel. Also, if a bug goes into production, having the track
record properly in git and Forges really makes a difference.
But as said, I understand you have now your optimized workflow in
Mutt, and I am not asking you to change it.
any solutions
on what the Debian community can do to improve the new contributor experience.
Hi everyone
I've been following this thread with great interest from the very
beginning and can relate to the many good points raised herein throughout.
I'll try to make a suggestion as a very new contributor to Debian myself
- so take my thoughts with massive grains of salt :)
A _part_ of the problem seems to be to provide new contributors an entry point to the Debian project. Not for a lack of need of things to be done
but because of difficulties in **directing new contributors to maintainers/maintainer teams who can and are willing to dedicate time to
new contributors** - who, by the nature of things, will require more guidance and patience.
As Andreas has mentioned previously in this thread, these kind of
mentoring opportunities exist in Debian. E.g. [0] and [1]. Probably
there are more. My point is: It is hard to find them. Neither the
[Debian > Get Involved][2], nor the - harder to find but more complete - [How you can help Debian][3] pages mention them.
[0]: https://salsa.debian.org/med-team/community/MoM/-/wikis/Mentoring-of-the-Month-(MoM)
[1]: https://wiki.debian.org/SummerOfCode2025
[2]: https://www.debian.org/devel/join/
[3]: https://www.debian.org/intro/help
While the OP of this thread managed to create a MR, many potential contributors will not even get to that point. I doubt that I personally would have started contributing to Debian if it was not for the highly structured Google Summer of Code program with a dedicated mentor. Maybe
it is just me, but as a newbie it is still somewhat intimidating to contribute to a big project like Debian after all. Having an actionable
"Get in touch with Mentoring Project X to start contributing to Debian" would be helpful in this situation.
Guiding potential contributors to mentors with the necessary bandwidth
to support newcomers is obviously only a partial solution. Not all new contributors will need/want mentorship. It will also not help those, who want a particular bug in a particular package fixed. It will still
require dedication and persistence from new contributors. But matching
those who are willing to contribute with Debian Developers/Maintainers
who are (explicitly) willing to be mentors feels doable.
I have a feeling that this is a more important factor in attracting new contributors than having one workflow/tool chain or another. To me,
those are just another thing one might have to learn in the process of contributing to Debian.
I'd be happy to add a page on the Debian website or a wiki article
listing the existing mentoring opportunities in Debian if that would
help. Or does a mechanism to discover those exist already and I just
haven't found it?
Regarding working with patch submissions, I greatly prefer an MR. I almost >never merge a request without requesting changes, or at least clarification. >Having the ability to highlight specific lines of code and start a thread >discussing them, and having several threads going at once for different parts >of the code, each of which can independently be marked as completed, is a >workflow that I would find difficult to replicate in email.
On Tue, 17 Jun 2025 13:42:18 -0700, Soren Stoutner <soren@debian.org>
wrote:
I am not sure whether just
pushing my fixed code to the branch that I submitted an MR for will >automatically update the MR
Am 18. Juni 2025 12:35:04 MESZ schrieb Marc Haber <mh+debian-devel@zugschlus.de>:
On Tue, 17 Jun 2025 13:42:18 -0700, Soren Stoutner <soren@debian.org> >>wrote:
I am not sure whether just
pushing my fixed code to the branch that I submitted an MR for will >>automatically update the MR
it will.
in forges like gitlab (or GitHub), MRs (PRs) are just branches with discussion and I "merge" button.
the branch has to be within the same (instance of the) forge, to allow easy integration.
the full MR is the tip of the branch.
discussion on lines of code within the MR can become stale when you push new commits that change the very lines (but the history is kept), and the discussion can be "resolved" (hidden, as no longer relevant; but still there).
my experience comes mostly from GitHub (for whatever reasons my gitlab/salsa/... interaction has less reviewing), but I don't remember significant differences.
How about force pushes after doing rebase -i to squash fixups? I have
been told to NEVER do that, but the one time I accidentally did it, it
just worked.
The typical Github/Gitlab workflow encourages having a separation between
two categories of branches:
- stable, "public", safe to reference and will not be force-pushed
(for example "main" or "0.2.x" or "debian/latest")
- work-in-progress, unstable, expected to be force-pushed, only exist as a collaboration point
In the email-based Linux-kernel workflow, if I understand correctly, the convention is that only the first category ever get pushed anywhere public, and the second category exist only on your laptop (because they're sent to other developers as patches, rather than as a complete branch).
How about force pushes after doing rebase -i to squash fixups? I have
been told to NEVER do that, but the one time I accidentally did it, it
just worked.
Debian Mentors as a sub project of Debian already exists. While generally used
for those wishing review and also sponsorship of a package, we also have a mailing list for all those who need help with their existing or new contribution
to Debian. We have been open for business for many many years. :-)
Debian Mentors as a sub project of Debian already exists. While generally used
for those wishing review and also sponsorship of a package, we also have a mailing list for all those who need help with their existing or new contribution
to Debian. We have been open for business for many many years. :-)
I am subscribed to the debian-mentors list and see the tireless work
you're doing for Debian day-in, day-out. Thank you for that, Phil!
But as you say yourself, the traffic on that list is mostly from people
who are familiar enough with Debian that they can package for Debian _already_ but aren't Debian Maintainers or Debian Developers with upload rights yet. I'd argue, that only a minority of the people who'd be
willing to contribute to Debian, already come with the skills required
to do so. I wouldn't blame those who don't have the necessary knowledge
to package for Debian to conclude after browsing the archive of the debian-mentors list that this isn't the right place for them to ask
questions or look for guidance. Therefore, I still think that pointing (complete) newcomers to the "structured" mentorship programs already available in Debian would be helpful to them and the Debian project.
Debian Mentors as a sub project of Debian already exists. While generally used
for those wishing review and also sponsorship of a package, we also have a >> mailing list for all those who need help with their existing or new contribution
to Debian. We have been open for business for many many years. :-)
I am subscribed to the debian-mentors list and see the tireless work
you're doing for Debian day-in, day-out. Thank you for that, Phil!
But as you say yourself, the traffic on that list is mostly from people
who are familiar enough with Debian that they can package for Debian >_already_ but aren't Debian Maintainers or Debian Developers with upload >rights yet. I'd argue, that only a minority of the people who'd be
willing to contribute to Debian, already come with the skills required
to do so. I wouldn't blame those who don't have the necessary knowledge
to package for Debian to conclude after browsing the archive of the >debian-mentors list that this isn't the right place for them to ask
questions or look for guidance. Therefore, I still think that pointing >(complete) newcomers to the "structured" mentorship programs already >available in Debian would be helpful to them and the Debian project.
On Fri, Jun 20, 2025 at 03:59:38PM +0200, Alex wrote:
Debian Mentors as a sub project of Debian already exists. While generally used
for those wishing review and also sponsorship of a package, we also have a
mailing list for all those who need help with their existing or new contribution
to Debian. We have been open for business for many many years. :-)
I am subscribed to the debian-mentors list and see the tireless work
you're doing for Debian day-in, day-out. Thank you for that, Phil!
But as you say yourself, the traffic on that list is mostly from people
who are familiar enough with Debian that they can package for Debian _already_ but aren't Debian Maintainers or Debian Developers with upload rights yet. I'd argue, that only a minority of the people who'd be
willing to contribute to Debian, already come with the skills required
to do so. I wouldn't blame those who don't have the necessary knowledge
to package for Debian to conclude after browsing the archive of the debian-mentors list that this isn't the right place for them to ask questions or look for guidance. Therefore, I still think that pointing (complete) newcomers to the "structured" mentorship programs already available in Debian would be helpful to them and the Debian project.
While it's true that RFS replies provide a large part of the d-mentors@ traffic, d-mentors@ is the official place for people without experience to ask questions about contributing to Debian.
OTOH if people are willing to create that "structured mentorship program
for complete newcomers" you are talking about and be the mentors in it, that's up to them. We get a question of "this is #d-mentors, how do I get
a mentor assigned" on #d-mentors every several months, for which the
answer is always "there is no such thing, please ask specific questions".
We get a question of "this is #d-mentors, how do I get a mentor
assigned" on #d-mentors every several months, for which the answer
is always "there is no such thing, please ask specific questions".
But is the statement that "there is no such thing" factual?
There is the [MoM][0] in the Debian Med-Team.
There is the [Google Summer of Code program][1].
All I am advocating for is to simply make these *existing*
opportunities more visible. Something low-key like
* If you need more guidance as a new contributor to Debian, please
have a look at the [available mentoring opportunities](link to Debian
wiki page where those existing opportunities are listed).
as an addition to https://www.debian.org/intro/help#coding would be a
good start, I think.
Then you surely can point me to documentation about how I, as the MR submitter am supposed to improve the MR. I am not sure whether just
pushing my fixed code to the branch that I submitted an MR for will automatically update the MR
o whether I am supposed to do some magic
chants to have those changes show up in the MR,
or whether I am
supposed to comment on the thread after pushing an improvement
and who
is supposed to close the discussion thread in the MR.
There is the [MoM][0] in the Debian Med-Team.
Is or was?
According to that page, last updated 3 years ago, while there was some significant activity in 2014-2015 (10 years ago) it died out around 2017.
It was also team-specific.