Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #117485 > unrolled thread
| Started by | Joachim Zobel <jz-2017@heute-morgen.de> |
|---|---|
| First post | 2025-05-30 11:00 +0200 |
| Last post | 2025-06-04 13:50 +0200 |
| Articles | 20 on this page of 148 — 37 participants |
Back to article view | Back to linux.debian.devel
New contributor experience Joachim Zobel <jz-2017@heute-morgen.de> - 2025-05-30 11:00 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-05-30 11:20 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-05-30 14:50 +0200
Re: New contributor experience Antonio Terceiro <terceiro@debian.org> - 2025-05-30 15:30 +0200
Re: New contributor experience Simon McVittie <smcv@debian.org> - 2025-05-30 15:40 +0200
Re: New contributor experience "Theodore Ts'o" <tytso@mit.edu> - 2025-05-30 17:20 +0200
Re: Re: New contributor experience Antoine Le Gonidec <debian@vv221.fr> - 2025-05-30 20:00 +0200
Re: New contributor experience Joachim Zobel <jz-2017@heute-morgen.de> - 2025-05-30 16:30 +0200
Re: New contributor experience Joachim Zobel <jz-2017@heute-morgen.de> - 2025-05-30 17:10 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-05-30 17:20 +0200
Re: New contributor experience Soren Stoutner <soren@debian.org> - 2025-05-30 19:50 +0200
Re: New contributor experience Jonas Smedegaard <jonas@jones.dk> - 2025-05-30 21:40 +0200
Re: New contributor experience gregor herrmann <gregoa@debian.org> - 2025-05-30 22:30 +0200
Re: New contributor experience Soren Stoutner <soren@debian.org> - 2025-05-30 22:30 +0200
Re: New contributor experience gregor herrmann <gregoa@debian.org> - 2025-05-31 00:20 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-05-31 07:40 +0200
Re: New contributor experience Fabio Fantoni <fantonifabio@tiscali.it> - 2025-05-31 11:10 +0200
Re: New contributor experience Chris Hofstaedtler <zeha@debian.org> - 2025-06-02 10:20 +0200
Pondering a Welcome Team (Was: New contributor experience) Daniel Gröber <dxld@darkboxed.org> - 2025-06-01 22:40 +0200
Re: Pondering a Welcome Team (Was: New contributor experience) Joachim Zobel <jz-2017@heute-morgen.de> - 2025-06-02 11:30 +0200
Re: New contributor experience Phil Wyett <philip.wyett@kathenas.org> - 2025-06-02 10:20 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-02 12:40 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-04 12:50 +0200
Re: New contributor experience Joachim Zobel <jz-2017@heute-morgen.de> - 2025-06-04 13:10 +0200
Re: New contributor experience Holger Levsen <holger@layer-acht.org> - 2025-06-04 13:30 +0200
Re: New contributor experience Joachim Zobel <jzobel@heute-morgen.de> - 2025-06-04 14:00 +0200
Re: New contributor experience Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-06-04 13:50 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 13:30 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-04 13:40 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-04 13:50 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 14:00 +0200
Re: New contributor experience Jonas Smedegaard <jonas@jones.dk> - 2025-06-04 14:30 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 15:00 +0200
Re: New contributor experience Nilesh Patra <nilesh@debian.org> - 2025-06-04 16:40 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-04 17:20 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-04 17:30 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-04 17:50 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-04 17:40 +0200
Re: New contributor experience Russ Allbery <rra@debian.org> - 2025-06-04 17:40 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-04 17:50 +0200
Re: New contributor experience Russ Allbery <rra@debian.org> - 2025-06-04 18:20 +0200
Re: New contributor experience Raphael Hertzog <hertzog@debian.org> - 2025-06-06 14:50 +0200
Re: "People can't be bothered" (Was: New contributor experience) Daniel Gröber <dxld@darkboxed.org> - 2025-06-04 19:40 +0200
Re: New contributor experience Nilesh Patra <nilesh@debian.org> - 2025-06-05 06:50 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-05 07:30 +0200
Re: New contributor experience Nilesh Patra <nilesh@debian.org> - 2025-06-05 06:50 +0200
Re: New contributor experience Richard Lewis <richard.lewis.debian@googlemail.com> - 2025-06-05 22:00 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-05 22:10 +0200
Re: New contributor experience Richard Lewis <richard.lewis.debian@googlemail.com> - 2025-06-05 22:50 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-05 23:10 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-06 10:00 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-06 10:00 +0200
Re: New contributor experience Richard Lewis <richard.lewis.debian@googlemail.com> - 2025-06-06 20:00 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-06 20:20 +0200
Re: New contributor experience Joachim Zobel <jzobel@heute-morgen.de> - 2025-06-06 20:50 +0200
Re: New contributor experience Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-06-04 15:00 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 15:10 +0200
Re: New contributor experience Jonas Smedegaard <jonas@jones.dk> - 2025-06-04 15:40 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 16:10 +0200
Re: New contributor experience Soren Stoutner <soren@debian.org> - 2025-06-05 00:00 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-05 20:00 +0200
Re: New contributor experience Soren Stoutner <soren@debian.org> - 2025-06-05 22:40 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-05 23:10 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-05 20:20 +0200
Re: New contributor experience Charles Plessy <plessy@debian.org> - 2025-06-05 01:50 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-04 13:40 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 14:00 +0200
Re: New contributor experience Jonas Smedegaard <jonas@jones.dk> - 2025-06-04 14:20 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-04 14:30 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-04 14:50 +0200
Re: New contributor experience Russ Allbery <rra@debian.org> - 2025-06-04 17:40 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-04 17:50 +0200
Re: New contributor experience Simon McVittie <smcv@debian.org> - 2025-06-04 18:00 +0200
Re: New contributor experience Jonas Smedegaard <jonas@jones.dk> - 2025-06-04 18:30 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-04 18:40 +0200
Re: New contributor experience Jonas Smedegaard <jonas@jones.dk> - 2025-06-04 19:20 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-04 20:20 +0200
Re: New contributor experience Andreas Tille <andreas@an3as.eu> - 2025-06-08 11:00 +0200
Re: Re: New contributor experience Alex <alex@puer-robustus.eu> - 2025-06-11 00:10 +0200
Re: New contributor experience Pirate Praveen <praveen@onenetbeyond.org> - 2025-06-11 20:40 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-11 21:40 +0200
Re: New contributor experience IOhannes m zmölnig <umlaeute@debian.org> - 2025-06-12 18:40 +0200
Re: New contributor experience Joachim Zobel <jzobel@heute-morgen.de> - 2025-06-13 12:50 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-13 08:00 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-04 18:40 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 19:20 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-04 19:30 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 19:40 +0200
Re: New contributor experience Tim Woodall <debiandevel@woodall.me.uk> - 2025-06-07 18:00 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-07 18:10 +0200
apt-cacher-ng (Was Re: New contributor experience) Andy Smith <andy@strugglers.net> - 2025-06-07 23:00 +0200
Re: apt-cacher-ng (Was Re: New contributor experience) "Andrea Pappacoda" <tachi@debian.org> - 2025-06-07 23:20 +0200
Re: apt-cacher-ng (Was Re: New contributor experience) Alexandre Detiste <alexandre.detiste@gmail.com> - 2025-06-07 23:30 +0200
Re: apt-cacher-ng (Was Re: New contributor experience) Peter Pentchev <roam@ringlet.net> - 2025-06-08 03:40 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 18:20 +0200
Re: New contributor experience Russ Allbery <rra@debian.org> - 2025-06-04 18:30 +0200
Re: New contributor experience Ahmad Khalifa <ahmad@khalifa.ws> - 2025-06-04 19:20 +0200
Re: New contributor experience Russ Allbery <rra@debian.org> - 2025-06-04 19:50 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-04 21:00 +0200
Re: New contributor experience Holger Levsen <holger@layer-acht.org> - 2025-06-05 13:30 +0200
Re: New contributor experience Soren Stoutner <soren@debian.org> - 2025-06-05 17:50 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-05 18:00 +0200
Re: New contributor experience James McCoy <jamessan@debian.org> - 2025-06-05 20:20 +0200
Re: New contributor experience "Theodore Ts'o" <tytso@mit.edu> - 2025-06-14 16:20 +0200
Re: New contributor experience IOhannes m zmölnig <umlaeute@debian.org> - 2025-06-14 19:30 +0200
Re: New contributor experience IOhannes m zmölnig <umlaeute@debian.org> - 2025-06-14 20:40 +0200
Re: New contributor experience "Theodore Ts'o" <tytso@mit.edu> - 2025-06-16 23:50 +0200
Re: New contributor experience "Theodore Ts'o" <tytso@mit.edu> - 2025-06-17 00:10 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-17 08:00 +0200
Re: New contributor experience "Theodore Ts'o" <tytso@mit.edu> - 2025-06-17 14:10 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-17 19:00 +0200
Re: New contributor experience Russ Allbery <rra@debian.org> - 2025-06-17 19:20 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-17 19:40 +0200
Re: New contributor experience Russ Allbery <rra@debian.org> - 2025-06-17 20:40 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-17 22:00 +0200
Re: New contributor experience Phil Wyett <philip.wyett@kathenas.org> - 2025-06-18 12:40 +0200
Re: New contributor experience Alex <alex@puer-robustus.eu> - 2025-06-20 16:20 +0200
Re: New contributor experience Phil Wyett <philip.wyett@kathenas.org> - 2025-06-20 16:20 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-20 16:40 +0200
Re: New contributor experience Phil Wyett <philip.wyett@kathenas.org> - 2025-06-20 19:10 +0200
Re: New contributor experience Alex <alex@puer-robustus.eu> - 2025-06-21 21:00 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-21 22:40 +0200
Re: New contributor experience Alex <alex@puer-robustus.eu> - 2025-06-21 23:40 +0200
Re: New contributor experience Mechtilde Stehmann <mechtilde@debian.org> - 2025-06-22 08:30 +0200
Re: New contributor experience Andreas Tille <andreas@an3as.eu> - 2025-06-24 22:20 +0200
Re: New contributor experience Jeremy Stanley <fungi@yuggoth.org> - 2025-06-17 23:10 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-17 23:20 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-18 12:30 +0200
Re: New contributor experience "Andrea Pappacoda" <tachi@debian.org> - 2025-06-18 11:40 +0200
Re: New contributor experience "Theodore Ts'o" <tytso@mit.edu> - 2025-06-17 20:40 +0200
Re: New contributor experience Otto Kekäläinen <otto@debian.org> - 2025-06-17 22:20 +0200
Re: New contributor experience Soren Stoutner <soren@debian.org> - 2025-06-17 22:50 +0200
Re: New contributor experience Jeremy Stanley <fungi@yuggoth.org> - 2025-06-17 23:20 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-18 12:40 +0200
Re: New contributor experience IOhannes m zmölnig <umlaeute@debian.org> - 2025-06-18 14:50 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-18 15:00 +0200
Re: New contributor experience Simon McVittie <smcv@debian.org> - 2025-06-18 15:40 +0200
Re: New contributor experience "Theodore Ts'o" <tytso@mit.edu> - 2025-06-18 16:20 +0200
Re: New contributor experience Colin Watson <cjwatson@debian.org> - 2025-06-18 16:30 +0200
Re: New contributor experience Soren Stoutner <soren@debian.org> - 2025-06-23 19:10 +0200
Re: New contributor experience "Theodore Ts'o" <tytso@mit.edu> - 2025-06-18 02:30 +0200
Re: New contributor experience "Theodore Ts'o" <tytso@mit.edu> - 2025-06-18 05:50 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-18 12:40 +0200
Let's make it visible when a package has no maintainer scripts (Re: New contributor experience) Charles Plessy <plessy@debian.org> - 2025-06-18 02:40 +0200
Re: New contributor experience Joachim Zobel <jzobel@heute-morgen.de> - 2025-06-04 18:40 +0200
Re: New contributor experience Marc Haber <mh+debian-devel@zugschlus.de> - 2025-06-04 21:30 +0200
Re: New contributor experience Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-06-04 13:30 +0200
Re: New contributor experience Andrey Rakhmatullin <wrar@debian.org> - 2025-06-04 13:50 +0200
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Soren Stoutner <soren@debian.org> |
|---|---|
| Date | 2025-06-05 17:50 +0200 |
| Message-ID | <KUl0S-8rt8-21@gated-at.bofh.it> |
| In reply to | #117609 |
[Multipart message — attachments visible in raw view] — view raw
On Thursday, June 5, 2025 4:26:10 AM Mountain Standard Time Holger Levsen wrote: > On Wed, Jun 04, 2025 at 11:51:37PM +0500, Andrey Rakhmatullin wrote: > > 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 -- Soren Stoutner soren@debian.org
[toc] | [prev] | [next] | [standalone]
| From | Andrey Rakhmatullin <wrar@debian.org> |
|---|---|
| Date | 2025-06-05 18:00 +0200 |
| Message-ID | <KUlax-8rwI-13@gated-at.bofh.it> |
| In reply to | #117611 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Jun 05, 2025 at 08:41:30AM -0700, Soren Stoutner wrote: >> > 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 Besides this missing closed bugs (which started this subthread) it's also not always possible to find the bug by the software name, because there could be several ways to write it. -- WBR, wRAR
[toc] | [prev] | [next] | [standalone]
| From | James McCoy <jamessan@debian.org> |
|---|---|
| Date | 2025-06-05 20:20 +0200 |
| Message-ID | <KUnm1-8t7P-7@gated-at.bofh.it> |
| In reply to | #117611 |
On Thu, Jun 05, 2025 at 08:41:30AM -0700, Soren Stoutner wrote: >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 There's also https://wnpp.debian.net/ which allows doing some more filtering / searching. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2025-06-14 16:20 +0200 |
| Message-ID | <KXzTH-awso-1@gated-at.bofh.it> |
| In reply to | #117599 |
On Wed, Jun 04, 2025 at 10:47:35AM -0700, Russ Allbery wrote: > > 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've been on vacation, so I only came across this thread now. 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. And of course, there is always the case of the xz-utils backdoor, where the maintainer was bullied into letting a fresh-faced contributor "help", and that person ended ended up being a bad actor (perhaps from state-funded intelligence agency, such as the MSS, NSA or KGB). For critical code, if you don't have time, and the code quality is suspect, I don't think we should be shaming open source maintainers or package maintainers that they have some obligation to respond in some set time. Code quality is much more important than keeping newbies happy; at least, that's my set of priorities. - Ted
[toc] | [prev] | [next] | [standalone]
| From | IOhannes m zmölnig <umlaeute@debian.org> |
|---|---|
| Date | 2025-06-14 19:30 +0200 |
| Message-ID | <KXCRz-ayhA-3@gated-at.bofh.it> |
| In reply to | #117689 |
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...
> 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.
fair enough.
however, submitting a "not acceptable" contribution need not necessarily be a featuring experience - if we can communicate to the contributor why a suggestion is rejected.
afaict, frustration arises if there's missing feedback where
- the contributor is lost in "how to contribute" ("what are my possibilities to act?", aka: they don't know where to start)
- the contributor is lost after they contributed ("what are the effects of my action?"; aka: they don't know what happened to their work)
so far the discussion was mostly about the first issue, you bring in the second one.
in this (2nd) case I think it would be helpful for the contributor to receive a *minimal* response telling them that their contribution was in vain die to the complexity of the project.
in the end I'm pretty sure it is less effort to write a short (canned) response ("I'm afraid I cannot accept drive-by contributions for such a complex project") than to be bothered with endless discussions on debian-devel :-)
mfh.her.fsr
IOhannes
[toc] | [prev] | [next] | [standalone]
| From | IOhannes m zmölnig <umlaeute@debian.org> |
|---|---|
| Date | 2025-06-14 20:40 +0200 |
| Message-ID | <KXDXj-ayU8-1@gated-at.bofh.it> |
| In reply to | #117690 |
sorry for all the typos, I'm on my mobile Am 14. Juni 2025 19:09:59 MESZ schrieb "IOhannes m zmölnig" <umlaeute@debian.org>: >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... > obviously "by doing" >however, submitting a "not acceptable" contribution need not necessarily be a featuring rather, they need not be "a *frustrating* experience" I'm sure there are more autocorrection errors that I haven't spotted yet. mfh.her.fsr IOhannes
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2025-06-16 23:50 +0200 |
| Message-ID | <KYpSh-b3kz-1@gated-at.bofh.it> |
| In reply to | #117690 |
On Sat, Jun 14, 2025 at 07:09:59PM +0200, IOhannes m zmölnig wrote: > > > >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 And there have been some over-eager contributors in the Linux Kernel community that were actively bad enough that maintainers just started ignoring them. The worst ones were the ones that tried to "help" other newcomers by giving (bad) advice and code review, to the point where some senior maintainers had to tell other contributors, "feel free to ignore anything coming from this particular person". (So just as not all contributors are not necessarily good, not all code reivews are necessarily constructive, either...) I do agree that in the ideal world, sure, potential contributors should get some kind of response. The question is whether shaming voluinteers by demanding that they provide labor to respond to contributors is either (a) ethical, or (b) productive. I don't see it as much different than demanding that an open source programmer develop some feature, or investigate some bug fix, by some entitled user or corporation expecting that free software is the same as free support or free work. 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! [4] https://www.kernel.org/doc/html/latest/process/submitting-patches.html It's when package mainatiners are told that somehow they are "less than" for not dealing with new contributions quickly enough, especially when they send pull requests to places which they don't follow, that I'd suggest that perhaps we need to tell those people issuing these sorts of demands that there needs to be the organizational equivalent of "patches gratefully accepted". If you want a new feature; code it yourself. If you think new contributors should get more attention, perhaps you should be part of the solution instead of demanding more work from volunteers. I'll also note that most of the time maintainers are well motivated to try to recuit people to help out; many hands make light work, and all that. But also needs to be understood that any time you spend a lot of time helping a new contributor, you are taking a risk that the effort you put into helping that new contributor has a positive return on investment. If too many contributors end up having a negative ROI, and maintainers are shamed into helping those newbies out regardless, that can be a recipe for maintainer burnout, or another Jia Tan episode. Cheers, - Ted
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2025-06-17 00:10 +0200 |
| Message-ID | <KYqbD-b3Hg-1@gated-at.bofh.it> |
| In reply to | #117695 |
On Mon, Jun 16, 2025 at 05:43:12PM -0400, Theodore Ts'o wrote: > 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 Oh, and how could I forget --- another example of "bad" contributors was Professor Kangjie Lu from the University of Minnesota and his graduate students[1]. [1] https://www.theverge.com/2021/4/30/22410164/linux-kernel-university-of-minnesota-banned-open-source 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. Cheers, - Ted
[toc] | [prev] | [next] | [standalone]
| From | Otto Kekäläinen <otto@debian.org> |
|---|---|
| Date | 2025-06-17 08:00 +0200 |
| Message-ID | <KYxwt-b8bQ-1@gated-at.bofh.it> |
| In reply to | #117696 |
Hi, > 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! We have CI that does most of this, and I believe strongly that investing X amount of effort in the CI will have great ROI in doing the above mostly automatically for all submissions, so that once a human starts looking at a new submission the contribution should already be past a certain bar. > 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. 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. I don't think the Forge model makes git usabiilty issues any worse, on the contrary it gives an additional place where people can browse the commits visually and drill into discussions about each changed etc. > 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. 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. 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. 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. If you only focus on your own "local optimum" and don't think about the more generic working methods and document them and teach them to new contributors, somebody else will teach them something, and if those "others" are developer advocates from Microsoft, then open source won't win the long game.. Personally I like to support things like e.g. GitLab and Pulsar because I see it as the most viable competitors to GitHub and VS Code. As a lot of people have experienced doing reviews with the support of nice UIs, CI that run on every commit etc, I don't think devs will en mass go back to using just e-mail for code reviews.
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2025-06-17 14:10 +0200 |
| Message-ID | <KYDix-bbVQ-1@gated-at.bofh.it> |
| In reply to | #117698 |
On Tue, Jun 17, 2025 at 08:51:19AM +0300, Otto Kekäläinen wrote:
>
> 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
separately. That way you can see what the logical change of a small
change makes, and if there's something suspicious, it's much easier to
spot.
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"
Pulling all of the changes and then going on an airplane also doesn't
scale if you have a huge number of changes to review. See below for
an example. Granted, this represents about two months worth of
changes and I didn't do them all while off-line, but this should give
you an idea of the scale that I'm working at --- and a merge request
workflow Just Doesn't Scale.
This is why in general for the kernel, only Pull requests are done by
trusted maintainers who have PGP keys so they can sign their git
pulls, and then Linus will do a cursory review, but *all* changes from
new contributors get done via e-mail review, and they get reviewed
very carefully, especially after the hijinks of some Univeristy of
Minnesota researchers and the attack by Jia Tan.
Can we say that the Debian package maintainers are reviewing their
pull requests at *least* as rigorously as kernel maintainers? We had
better hope so, because Debian package scripts get run as root, and
most Debian might not appreciate it if their e-mails, private keys or
other data gets exfiltrated.
Maybe it's just me, but if I had to trade off the security of Debian
versus keeping newbie contributors happy, I know which I would
consider higher priority.
` - Ted
----------
New ext4 features and performance improvements:
* Fast commit performance improvements
* Multi-fsblock atomic write support for bigalloc file systems
* Large folio support for regular files
This last can result in really stupendous performance for the right
workloads. For example, see [1] where the Kernel Test Robot reported
over 37% improvement on a large sequential I/O workload.
[1] https://lore.kernel.org/all/202505161418.ec0d753f-lkp@intel.com/
There are also the usual bug fixes and cleanups. Of note are cleanups
of the extent status tree to fix potential races that could result in
the extent status tree getting corrupted under heavy siulatneous
allocation and deallocation to a single file.
----------------------------------------------------------------
Arnd Bergmann (1):
ext4: avoid -Wformat-security warning
Brian Foster (1):
ext4: only dirty folios when data journaling regular files
Christoph Hellwig (1):
ext4: use writeback_iter in ext4_journalled_submit_inode_data_buffers
Eric Biggers (4):
ext4: remove sbi argument from ext4_chksum()
ext4: remove sb argument from ext4_superblock_csum()
jbd2: remove journal_t argument from jbd2_chksum()
jbd2: remove journal_t argument from jbd2_superblock_csum()
Harshad Shirwadkar (9):
ext4: convert i_fc_lock to spinlock
ext4: for committing inode, make ext4_fc_track_inode wait
ext4: mark inode dirty before grabbing i_data_sem in ext4_setattr
ext4: rework fast commit commit path
ext4: drop i_fc_updates from inode fc info
ext4: update code documentation
ext4: temporarily elevate commit thread priority
ext4: convert s_fc_lock to mutex type
ext4: hold s_fc_lock while during fast commit
Jan Kara (1):
ext4: fix calculation of credits for extent tree modification
Jeongjun Park (1):
jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()
Ritesh Harjani (IBM) (12):
ext4: Document an edge case for overwrites
ext4: Check if inode uses extents in ext4_inode_can_atomic_write()
ext4: Make ext4_meta_trans_blocks() non-static for later use
ext4: Add support for EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS
ext4: Add multi-fsblock atomic write support with bigalloc
ext4: Enable support for ext4 multi-fsblock atomic write using bigalloc
ext4: Add atomic block write documentation
ext4: Unwritten to written conversion requires EXT4_EX_NOCACHE
ext4: Simplify last in leaf check in ext4_map_query_blocks
ext4: Rename and document EXT4_EX_FILTER to EXT4_EX_QUERY_FILTER
ext4: Simplify flags in ext4_map_query_blocks()
ext4: Add a WARN_ON_ONCE for querying LAST_IN_LEAF instead
Thadeu Lima de Souza Cascardo (1):
ext4: inline: fix len overflow in ext4_prepare_inline_data
Zhang Yi (21):
ext4: ext4: unify EXT4_EX_NOCACHE|NOFAIL flags in ext4_ext_remove_space()
ext4: generalize EXT4_GET_BLOCKS_IO_SUBMIT flag usage
ext4: prevent stale extent cache entries caused by concurrent I/O writeback
ext4: prevent stale extent cache entries caused by concurrent fiemap
ext4: prevent stale extent cache entries caused by concurrent get es_cache
ext4: factor out is_special_ino()
ext4: introduce ext4_check_map_extents_env() debug helper
ext4: check env when mapping and modifying extents
ext4: clairfy the rules for modifying extents
ext4: fix out of bounds punch offset
ext4: fix incorrect punch max_end
ext4: factor out ext4_get_maxbytes()
ext4: ensure i_size is smaller than maxbytes
ext4: make ext4_mpage_readpages() support large folios
ext4: make regular file's buffered write path support large folios
ext4: make __ext4_block_zero_page_range() support large folio
ext4/jbd2: convert jbd2_journal_blocks_per_page() to support large folio
ext4: correct the journal credits calculations of allocating blocks
ext4: make the writeback path support large folios
ext4: make online defragmentation support large folios
ext4: enable large folio for regular file
Documentation/filesystems/ext4/atomic_writes.rst | 225 ++++++++
Documentation/filesystems/ext4/overview.rst | 1 +
fs/ext4/bitmap.c | 8 +-
fs/ext4/ext4.h | 91 +++-
fs/ext4/ext4_jbd2.c | 3 +-
fs/ext4/ext4_jbd2.h | 4 +-
fs/ext4/extents.c | 177 +++++--
fs/ext4/extents_status.c | 35 +-
fs/ext4/fast_commit.c | 460 +++++++++--------
fs/ext4/file.c | 14 +-
fs/ext4/ialloc.c | 8 +-
fs/ext4/inline.c | 3 +-
fs/ext4/inode.c | 510 ++++++++++++++++---
fs/ext4/ioctl.c | 16 +-
fs/ext4/mmp.c | 2 +-
fs/ext4/move_extent.c | 11 +-
fs/ext4/namei.c | 10 +-
fs/ext4/orphan.c | 13 +-
fs/ext4/readpage.c | 28 +-
fs/ext4/resize.c | 2 +-
fs/ext4/super.c | 84 ++-
fs/ext4/xattr.c | 10 +-
fs/jbd2/commit.c | 6 +-
fs/jbd2/journal.c | 23 +-
fs/jbd2/recovery.c | 10 +-
fs/jbd2/transaction.c | 5 +-
include/linux/jbd2.h | 5 +-
27 files changed, 1290 insertions(+), 474 deletions(-)
create mode 100644 Documentation/filesystems/ext4/atomic_writes.rst
[toc] | [prev] | [next] | [standalone]
| From | Otto Kekäläinen <otto@debian.org> |
|---|---|
| Date | 2025-06-17 19:00 +0200 |
| Message-ID | <KYHPb-bevw-1@gated-at.bofh.it> |
| In reply to | #117701 |
> > 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. The above is very subjective language, I should probably not continue this thread but.. > > 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 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. Or using gitk graphically. In fact, as described in https://optimizedbyotto.com/post/how-to-code-review/ I would always start by reviewing the commit message to understand *why* the change is being done before even looking at the actual code changes. What you see in email as patches are generated in git and you for sure know that the exact same output can be generated offline from git commits by a plain git show. > 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. Same. > 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" 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. Unless of course git itself would start shipping an email client that has built-in the features to automatically show colorized diffs and arbitrary diffs against any selected target branch, and diffs between diffs, and fetch CI statuses from external APIs to render in the email client view etc. It is much easier to build an integrated UI in a browser that has full audit logs and discussion tracking etc with an git API, than it is to build a git client with all of that and an e-mail API.
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2025-06-17 19:20 +0200 |
| Message-ID | <KYI8x-beRO-1@gated-at.bofh.it> |
| In reply to | #117702 |
Otto Kekäläinen <otto@debian.org> writes: > 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. 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. In contrast, if you carefully review a diff that is sitting locally on your computer because, for instance, it is in your email, and then you apply exactly that diff that you reviewed rather than pulling it from somewhere else or clicking on a button on a web site, this is indeed inherently more secure. It reduces the security risk to only compromise of your local system and your own failure to understand the diff that you're reviewing, both of which are going to be an issue under most review systems and are mostly not avoidable. You generally lose some other ancillary properties (cryptographically-attested authorship, for instance), but in terms of the security of the code itself, it's generally a better approach. I think you're assuming that because email itself is insecure, Ted's approach is less secure, but Ted's point is that he's doing a detailed code review and therefore doesn't care very much about anything that happens upstream of that. It's the code review that creates the security properties he's after, and doing that locally in his email produces a very tight and close chain of custody between the code review and the commit, whereas a forge weakens that chain of custody considerably. All of security is a trade-off and a lot of people prefer the user experience of a forge for other reasons and are willing to accept the additional security risk or carefully configure the forge for the security properties they want. Those folks are not wrong to do that. It is to a very large extent a matter of opinion about competing trade-offs. But if what you care about the most is ensuring that the code that was reviewed is the code that was committed, Ted's approach is going to win in most security scenarios that I can think of. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Otto Kekäläinen <otto@debian.org> |
|---|---|
| Date | 2025-06-17 19:40 +0200 |
| Message-ID | <KYIrT-beXZ-1@gated-at.bofh.it> |
| In reply to | #117703 |
Hi, > 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. 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. I am sure anybody reading this can see why if they are honest to themselves and not trying to find straw man arguments to blame. 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? Or will you document your current email setup and start promoting it for new people to embrace instead of using UIs tailored to code reviews?
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2025-06-17 20:40 +0200 |
| Message-ID | <KYJnX-bfxK-1@gated-at.bofh.it> |
| In reply to | #117704 |
Otto Kekäläinen <otto@debian.org> writes: > 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. As I said explicitly, it does give up some tracing of the origin of the original MR, in favor of removing a lot of complexity and potential for security issues in the chain of custody between the review and the commit. This is a trade-off; people will have different opinions about which is more valuable. I personally agree with Ted that the chain of custody is a very nice security property and the way that he does patch review via email is more secure than the way people normally use forges. (Personally, I consider it much less *convenient*, but that's a different argument.) As I said in my original message, you can claw back some similar properties if you configure the forge very carefully, but most people do not. > 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 legitimate trade-offs, and the other person's workflow is simply wrong. This tendency annoys me, so sometimes I say something when I think people are oversimplifying. I don't disagree with many of your arguments in favor of forges. I use forges myself quite heavily. But they are not strictly better; Ted's approach is more secure than the normal forge workflow. Life is full of trade-offs, and I think arguments go better when they're acknowledged. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Otto Kekäläinen <otto@debian.org> |
|---|---|
| Date | 2025-06-17 22:00 +0200 |
| Message-ID | <KYKDo-bggh-27@gated-at.bofh.it> |
| In reply to | #117705 |
> > 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. Note that reviewing something and merging it as separate steps in the process. With Forges one can have track metadata for code submissions such as how many approvals it has had and whatnot. > > 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 no trace back to the original author, which is a major minus for e-mail submissions. I think anyone with some imagination can come up with multiple scenarios where an authorship attack via e-mail is much easier to both deliver and to evade audits on, but I won't go there now as it isn't the main point in the context of the new contributor experience. > 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 have not asserted that. I wrote today very explicitly this, quoting myself: > 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 topic here is the new contributor experience. I don't feel your comments about e-mail submissions improving the security posture of the overall system convincing, nor does it seem to offer any solutions on what the Debian community can do to improve the new contributor experience.
[toc] | [prev] | [next] | [standalone]
| From | Phil Wyett <philip.wyett@kathenas.org> |
|---|---|
| Date | 2025-06-18 12:40 +0200 |
| Message-ID | <KYYmZ-bph0-7@gated-at.bofh.it> |
| In reply to | #117707 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, 2025-06-18 at 00:40 +0200, Alex wrote: > > 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? Hi, 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. :-) -- Regards Phil Donate: https://buymeacoffee.com/kathenasorg -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: @kathenas:matrix.org --
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@puer-robustus.eu> |
|---|---|
| Date | 2025-06-20 16:20 +0200 |
| Message-ID | <KZKKZ-bUD3-11@gated-at.bofh.it> |
| In reply to | #117726 |
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Phil Wyett <philip.wyett@kathenas.org> |
|---|---|
| Date | 2025-06-20 16:20 +0200 |
| Message-ID | <KZKKZ-bUD3-7@gated-at.bofh.it> |
| In reply to | #117747 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 2025-06-20 at 15:59 +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. > Many thanks. I totally agree. A structured newcomers program would be fantastic and if I could help in such an effort, I certainly would try to free up time for it. -- Regards Phil Donate: https://buymeacoffee.com/kathenasorg -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: @kathenas:matrix.org --
[toc] | [prev] | [next] | [standalone]
| From | Andrey Rakhmatullin <wrar@debian.org> |
|---|---|
| Date | 2025-06-20 16:40 +0200 |
| Message-ID | <KZL4l-bUJQ-5@gated-at.bofh.it> |
| In reply to | #117747 |
[Multipart message — attachments visible in raw view] — view raw
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". -- WBR, wRAR
[toc] | [prev] | [next] | [standalone]
| From | Phil Wyett <philip.wyett@kathenas.org> |
|---|---|
| Date | 2025-06-20 19:10 +0200 |
| Message-ID | <KZNpw-bWnt-3@gated-at.bofh.it> |
| In reply to | #117749 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 2025-06-20 at 19:36 +0500, Andrey Rakhmatullin wrote: > 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". > I am aware that people do ask where they can get a mentor. I think defining what a Debian Mentor is as of now as works within the RFS process, review and help on a case by case package submission basis. This while partly mentoring it is in most cases is raising issues in a submitted package. Other parts of Debian Mentors is IRC and mailing list that are the places as you state (one of the main people that helps in these areas), the place to ask your questions. I would like to help in bringing together newcomers resources for people to read, get help and always know where they can ask for help if wanted information is not readily available. -- Regards Phil Donate: https://buymeacoffee.com/kathenasorg -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: @kathenas:matrix.org --
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | linux.debian.devel
csiph-web