On 2025-08-23 10:29 -0700, Otto Kekäläinen wrote:
However, if do all this work and discover that the first reply on your
MR was it being closed, there is no validation that you helped improve
Debian. The maintainer might have seen and copied your code, or the
maintainer might have investigated an
On Mon, Aug 25, 2025 at 01:31:16PM +0900, Simon Richter wrote:
For that to happen, we'd need an actual GitDevOps workflow for Debian
packages, not a set of mutually incompatible incomplete mappings that
each violate at least one core assumption that the web frontends make,
and by extension, at
Hi,
On 8/24/25 5:06 PM, Simon Josefsson wrote:
I think at some point we have to consider dropping bugs.debian.org
and/or augment with a more modern GitDevOps workflow, maybe based on
Salsa, but we are not there yet, at least not in any official standing
within Debian.
For that to happen, we'd
Hi,
On Sun, Aug 24, 2025 at 12:59:32AM +0200, gregor herrmann wrote:
On Sat, 23 Aug 2025 16:45:23 +0200, Marc Haber wrote:
nor get anything accumulated at
https://contributors.debian.org/contributor/.
I was neither aware that this page exists nor did it occur to me
that being mentioned there w
Otto Kekäläinen writes:
> I have now witnessed several cases where a maintainer blatantly
> ignored the MRs their package received. It is demotivating to new
> aspiring Debian contributors to put in significant effort to learn the
> complexities of Debian packaging and submit an improvement, only
On Sat, Aug 23, 2025 at 10:29:37AM -0700, Otto Kekäläinen wrote:
> On Sat, 23 Aug 2025 at 08:00, Andrea Bolognani wrote:
> > On Fri, Aug 22, 2025 at 01:34:16PM -0700, Otto Kekäläinen wrote:
> > > So all the effort the submitter did - and also me as mentor - was in
> > > vain. This is not the end o
On Sat, 23 Aug 2025 16:45:23 +0200, Marc Haber wrote:
nor get anything accumulated at
https://contributors.debian.org/contributor/.
I was neither aware that this page exists nor did it occur to me that
being mentioned there was of any importance to anyone.
Hu :)
I'm surprised that you don't k
On 23/08/25 10:59 pm, Otto Kekäläinen wrote:
> On Sat, 23 Aug 2025 at 08:00, Andrea Bolognani wrote:
>> On Fri, Aug 22, 2025 at 01:34:16PM -0700, Otto Kekäläinen wrote:
>>> On Sun, 17 Aug 2025 at 19:33, Theodore Ts'o wrote:
> ...
>>> So all the effort the submitter did - and also me as mentor - w
Quoting Otto Kekäläinen (2025-08-23 19:29:37)
> Hi Marc and Andrea,
>
> On Sat, 23 Aug 2025 at 07:45, Marc Haber wrote:
> > On Fri, Aug 22, 2025 at 01:34:16PM -0700, Otto Kekäläinen wrote:
> ...
> > >This is not the end of the world, but I wanted to share it as an
> > >anecdote of the new contrib
Hi Marc and Andrea,
On Sat, 23 Aug 2025 at 07:45, Marc Haber wrote:
> On Fri, Aug 22, 2025 at 01:34:16PM -0700, Otto Kekäläinen wrote:
...
> >This is not the end of the world, but I wanted to share it as an
> >anecdote of the new contributor experience.
>
> As a package maintainer, I am not very
On Fri, Aug 22, 2025 at 01:34:16PM -0700, Otto Kekäläinen wrote:
> On Sun, 17 Aug 2025 at 19:33, Theodore Ts'o wrote:
> > My point was that it takes a lot more effort, and time, to tell the
> > submitter what to change, and then (a) wait for them to make the
> > change, and (b) hope they make the
On Sat, Aug 23, 2025 at 04:45:23PM +0200, Marc Haber wrote:
On Fri, Aug 22, 2025 at 01:34:16PM -0700, Otto Kekäläinen wrote:
If think giving feedback and letting the submitter finalize the thing
will help them feel more ownership, but if you do decide to just
quickly do it yourself, you can actu
On Mon, Aug 18, 2025 at 11:04:02AM -0700, Soren Stoutner wrote:
Therefore, if they have not unchecked this box when creating the MR, those
reviewing the MR may consider this as permission to push changes to their MR.
Even push --force?
Greetings
Marc
--
--
On Fri, Aug 22, 2025 at 01:34:16PM -0700, Otto Kekäläinen wrote:
On August 19th the maintainer closed the MR. He thanked the submitter
for it but decided that merging or was too much effort after he did
other changes on the main branch, so he just went ahead and did the
exact same change himself
On 22/08/25 23:00, Jonas Smedegaard wrote:
What I find bad is to not credit*in changelog* the person contributing
a change notable of being mentioned in changelog.
I never thanked you for this very basic courtesy you've shown me (and
everybody else, I'm sure) over my year contributing to Debia
Quoting Jonas Smedegaard (2025-08-22 23:00:10)
> Just in case anyone cares. I have noted that Otto seems to not care
> about my comments in this thread.
The above remark was simply wrong. I apologize for that.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136
Quoting Otto Kekäläinen (2025-08-22 22:34:16)
> Let me share a story about something that happened this week. A person
> I am mentoring had been planning to contribute to Debian for a long
> time. I suggested they start small by for example fixing a bug in an
> existing package (as doing a new upst
Le ven. 22 août 2025 à 22:35, Otto Kekäläinen a écrit :
> Hi,
>
> On Sun, 17 Aug 2025 at 19:33, Theodore Ts'o wrote:
> > On Sun, Aug 17, 2025 at 02:44:06PM -0700, Otto Kekäläinen wrote:
> > > In the web interface you can suggest changes that automatically become
> > > patches on the branch, whic
Hi,
On Sun, 17 Aug 2025 at 19:33, Theodore Ts'o wrote:
> On Sun, Aug 17, 2025 at 02:44:06PM -0700, Otto Kekäläinen wrote:
> > In the web interface you can suggest changes that automatically become
> > patches on the branch, which the original submitter can easily clean
> > up / integrate next tim
> >> Has anyone thought about adding something like "Your package has XX open
> >> Merge Requests on Salsa" to the "action needed" section on the Package
> >> Tracker? That's something I almost always look at before doing a new
> >> upload on a package.
> >
> > Oh! Yes, that would be incredibly he
On Sun, 2025-08-17 at 08:13 -0400, Theodore Ts'o wrote:
> On Sun, Aug 17, 2025 at 04:46:25PM +0900, Charles Plessy wrote:
> >
> > I only see this working if either Salsa would have a (scriptable ?)
> > upload button, or if the usual command-line tools like dput would
> > have a config option to do
On 19/08/25 15:56, Jonas Smedegaard wrote:
(README.md for that repo is a bit misleading: Only Rust packages
maintained by that team are tracked there.)
Fixed, thanks :-)
Quoting Scott Talbert (2025-08-19 15:33:51)
> On Thu, 14 Aug 2025, Russ Allbery wrote:
>
> >> Has anyone thought about adding something like "Your package has XX open
> >> Merge Requests on Salsa" to the "action needed" section on the Package
> >> Tracker? That's something I almost always look at
On Thu, 14 Aug 2025, Russ Allbery wrote:
Has anyone thought about adding something like "Your package has XX open
Merge Requests on Salsa" to the "action needed" section on the Package
Tracker? That's something I almost always look at before doing a new
upload on a package.
Oh! Yes, that woul
On Mon, Aug 18, 2025 at 08:19:49PM +0200, Alexandre Detiste wrote:
> Worst case scenario is when the guy submitting the 3 PR is the XZ hacker.
>
> That _did_ happened:
> https://salsa.debian.org/games-team/empire/-/merge_requests/1
> https://salsa.debian.org/games-team/empire/-/merge_requests/2
>
* Andrey Rakhmatullin [250818 08:47]:
On Sun, Aug 17, 2025 at 11:51:32PM +0300, Peter Pentchev wrote:
I mean, yes, if the merge request has been made from a different branch in
the same Git repository, so you actually have enough access
Or if it's GitHub and the submitter didn't disable the "
Le 18 août 2025 20:34:08 GMT+02:00, Andrey Rakhmatullin a
écrit :
>> So MR for pristine-tar & upstream branch are too big to review and
>> can never be trusted if they are from newcomers.
>
>Same for master, as that one includes upstream changes.
… unless you only maintain the debian/ folder
On Mon, Aug 18, 2025 at 08:19:49PM +0200, Alexandre Detiste wrote:
Worst case scenario is when the guy submitting the 3 PR is the XZ hacker.
That _did_ happened:
https://salsa.debian.org/games-team/empire/-/merge_requests/1
https://salsa.debian.org/games-team/empire/-/merge_requests/2
https://ne
Worst case scenario is when the guy submitting the 3 PR is the XZ hacker.
That _did_ happened:
https://salsa.debian.org/games-team/empire/-/merge_requests/1
https://salsa.debian.org/games-team/empire/-/merge_requests/2
https://news.ycombinator.com/item?id=39868390
So MR for pristine-tar & upstrea
On Monday, August 18, 2025 1:45:38 AM Mountain Standard Time Marc Haber wrote:
> On Mon, Aug 18, 2025 at 10:54:40AM +0300, Peter Pentchev wrote:
> >I admit I wasn't aware of the fact that one can push a branch that
> >lives in a "personal" fork of the Git repository on the forge;
> >thanks, Otto. S
Hi,
> >And it prompts a question: Integrating a new upstream release means
> >changing at least two, in the case of pristine-tar being used three
> >branches at once, tightly connected to each other, and possibily an
> >external file (the orig tarball). Could a contributor do that with an
> >MR?
>
On Sat, Aug 16, 2025 at 07:14:06AM +0200, Marc Haber wrote:
And it prompts a question: Integrating a new upstream release means
changing at least two, in the case of pristine-tar being used three
branches at once, tightly connected to each other, and possibily an
external file (the orig tarball).
Hi!
[ Not disputing that review is a substantial effort. ]
On Sun, 2025-08-17 at 22:33:16 -0400, Theodore Ts'o wrote:
> You could just make the change yourself, and then do a "git commit
> --amend", but then the MR won't get closed automatically, becaue the
> forge won't recognize the modified co
On Mon, Aug 18, 2025 at 10:54:40AM +0300, Peter Pentchev wrote:
I admit I wasn't aware of the fact that one can push a branch that
lives in a "personal" fork of the Git repository on the forge;
thanks, Otto. Still, I agree that this is more work, and this is
partly what I meant when I first said
Le 17 août 2025 04:17:30 GMT+02:00, Theodore Ts'o a écrit :
>In some cases, if it's a patch sent via e-mail, I'll just fix up the
>patch and then let the contributor know that they failed to do error
>checking, or their patch had a buffer overrun and result in a security
>vulnerability etc. B
On Sun, Aug 17, 2025 at 10:33:16PM -0400, Theodore Ts'o wrote:
> On Sun, Aug 17, 2025 at 02:44:06PM -0700, Otto Kekäläinen wrote:
> > In the web interface you can suggest changes that automatically become
> > patches on the branch, which the original submitter can easily clean
> > up / integrate ne
On Sun, 17 Aug 2025 22:33:16 -0400, "Theodore Ts'o"
>You could just make the change yourself, and then do a "git commit
>--amend", but then the MR won't get closed automatically, becaue the
>forge won't recognize the modified commit. And if you do a "git
>commit" instead ofa "git commit --amend",
On Sun, Aug 17, 2025 at 11:51:32PM +0300, Peter Pentchev wrote:
I mean, yes, if the merge request has been made from a different branch in
the same Git repository, so you actually have enough access
Or if it's GitHub and the submitter didn't disable the "Allow edits and
access to secrets by m
On Sun, Aug 17, 2025 at 02:44:06PM -0700, Otto Kekäläinen wrote:
> In the web interface you can suggest changes that automatically become
> patches on the branch, which the original submitter can easily clean
> up / integrate next time they rebase/refresh the MR.
My point was that it takes a lot m
Hi,
> > ...but how do you then tell the Git forge to use your changes when
> > you want to tell it to merge this merge request?
>
> I mean, yes, if the merge request has been made from a different branch in
> the same Git repository, so you actually have enough access to force-push
> your changes
On Sun, Aug 17, 2025 at 10:22:57PM +0100, Richard Lewis wrote:
> Peter Pentchev writes:
>
> > On Sun, Aug 17, 2025 at 09:34:14PM +0100, Richard Lewis wrote:
> >> "Theodore Ts'o" writes:
> >>
> >> > In some cases, if it's a patch sent via e-mail, I'll just fix up the
> >> > patch and then let th
Peter Pentchev writes:
> On Sun, Aug 17, 2025 at 09:34:14PM +0100, Richard Lewis wrote:
>> "Theodore Ts'o" writes:
>>
>> > In some cases, if it's a patch sent via e-mail, I'll just fix up the
>> > patch and then let the contributor know that they failed to do error
>> > checking, or their patch
On Sun, Aug 17, 2025 at 11:46:29PM +0300, Peter Pentchev wrote:
> On Sun, Aug 17, 2025 at 09:34:14PM +0100, Richard Lewis wrote:
> > "Theodore Ts'o" writes:
> >
> > > In some cases, if it's a patch sent via e-mail, I'll just fix up the
> > > patch and then let the contributor know that they faile
On Sun, Aug 17, 2025 at 09:34:14PM +0100, Richard Lewis wrote:
> "Theodore Ts'o" writes:
>
> > In some cases, if it's a patch sent via e-mail, I'll just fix up the
> > patch and then let the contributor know that they failed to do error
> > checking, or their patch had a buffer overrun and result
"Theodore Ts'o" writes:
> In some cases, if it's a patch sent via e-mail, I'll just fix up the
> patch and then let the contributor know that they failed to do error
> checking, or their patch had a buffer overrun and result in a security
> vulnerability etc. But with a merge request, all I can
Hi!
> > > How about this strategy: instead of disabling or ignoring Merge
> > > Requests on Salsa, take a peek at them at least once before uploading
>
> > I only see this working if either Salsa would have a (scriptable ?) upload
> > button, or if the usual command-line tools like dput would have
Hi!
On Sun, 2025-08-17 at 16:46:25 +0900, Charles Plessy wrote:
> Le Sun, Aug 17, 2025 at 12:18:57AM -0700, Otto Kekäläinen a écrit :
> > How about this strategy: instead of disabling or ignoring Merge
> > Requests on Salsa, take a peek at them at least once before uploading
> I only see this wor
On Sun, Aug 17, 2025 at 04:46:25PM +0900, Charles Plessy wrote:
>
> I only see this working if either Salsa would have a (scriptable ?)
> upload button, or if the usual command-line tools like dput would
> have a config option to do so. For instance maybe dgit - which I am
> looking forward to te
Richard Lewis left as an exercise for the reader:
> I think all he is saying is that the minority of developers that dont
> want MRs should change the settings to disable them, isnt that why the
> setting is there?
this might have been suggested before, but what if submitting
the MR included a co
Le Sun, Aug 17, 2025 at 12:18:57AM -0700, Otto Kekäläinen a écrit :
>
> How about this strategy: instead of disabling or ignoring Merge
> Requests on Salsa, take a peek at them at least once before uploading
Hi Otto,
I only see this working if either Salsa would have a (scriptable ?) upload
butt
Hi,
> I understand that training a newbie on how to write a good patch is an
> investment in the future. But that assumes that the person is going
> to stick around so that eventually they become a contributing member
> of the development community. If it's someone who sends a drive-by
> patch,
Am Samstag, dem 16.08.2025 um 17:33 + schrieb Jeremy Stanley:
> Is it frustrating enough to prompt you to reach out to the package
> maintainer(s) through other channels (bug report, E-mail, IRC), or
> is that level of effort too much to ask?
I was not aware before this discussion that this
On Fri, Aug 15, 2025 at 07:58:12PM -0700, Otto Kekäläinen wrote:
> Yes I agree. I would not expect you or Linus Torvalds to be the people
> new contributors in Debian would interact with. Also due to nature of
> the packages you have, the chances of you uploading and ignoring
> pending contribution
On 16/08/2025 18:33, Jeremy Stanley wrote:
On 2025-08-16 14:53:26 +0200 (+0200), Joachim Zobel wrote:
[...]
Not being able to do a MR is OK. Submitting a MR that I think might be
useful and never getting any reaction is frustrating.
Is it frustrating enough to prompt you to reach out to the pa
On 2025-08-16 14:53:26 +0200 (+0200), Joachim Zobel wrote:
[...]
Not being able to do a MR is OK. Submitting a MR that I think
might be useful and never getting any reaction is frustrating.
Is it frustrating enough to prompt you to reach out to the package
maintainer(s) through other channels
I think it should be added:
If you are not willing to deal with MRs (this includes rejecting)
please _disable them_.
Not being able to do a MR is OK. Submitting a MR that I think might be
useful and never getting any reaction is frustrating.
Sincerely,
Joachim
--
Papier ist gebundenes CO
On 17688 March 1977, Otto Kekäläinen wrote:
surely it is more of "our" way than just me alone, and sending a
reminder for people using Salsa to review Merge Requests should not be
that controversial.
And that one sums up the whole problem. Take a step back, read what you
wrote. Then read your
On Fri, Aug 15, 2025 at 03:53:57PM -0700, Otto Kekäläinen wrote:
Since you are in the Python team, could you please review the one
other still open submission by this person who seems to be a new
Debian contributor, so they can have their 5th accepted merge request?
https://salsa.debian.org/dashb
Hello,
> With all due respect, Salvo isn't.
Premising that my contributions aren't as valuable as those of Ted,
the only volunteer you get to give orders to is yourself.
Reviewing isn't about saying "Good job!" it's about saying "Good job
but…" and asking for changes and then checking if those c
On Fri, 15 Aug 2025 21:49:16 -0400, "Theodore Ts'o"
wrote:
>On Fri, Aug 15, 2025 at 09:20:15AM +0200, Marc Haber wrote:
>> On Fri, Aug 15, 2025 at 09:11:27AM +0200, Salvo Tomaselli wrote:
>> > Why is their time more valuable than mine?
>>
>> Why do you think that your time is more valuable than t
On Fri, 15 Aug 2025 20:50:48 +0100, Colin Watson
wrote:
>This is a matter of my professional judgement, and the answer won't
>always be the same kind of thing. When we're coming up to a release, I
>tend to focus almost entirely on RC bugs. Near the start of a release
>cycle, my current judgem
Hi,
On 8/15/25 20:23, Lucas Nussbaum wrote:
There is another debate below this: if Debian's workflow is different from a
standard forge workflow, does Debian need to change, or the forge?
Could it be that the standard forge workflow is optimized for
organizations with a few projects, while i
On 16/08/25 at 01:51 +0200, gregor herrmann wrote:
> On Fri, 15 Aug 2025 10:46:04 -0700, Otto Kekäläinen wrote:
>
> > I put screenshots of those yesterday at
> > https://wiki2025.debian.org/wiki/Salsa
>
> "Subscribe to email notifications about new Merge Requests in your project"
> only makes se
Hi,
> I think my time is more valuable than others because there are many
Yes I agree. I would not expect you or Linus Torvalds to be the people
new contributors in Debian would interact with. Also due to nature of
the packages you have, the chances of you uploading and ignoring
pending contribut
On Fri, Aug 15, 2025 at 09:20:15AM +0200, Marc Haber wrote:
> On Fri, Aug 15, 2025 at 09:11:27AM +0200, Salvo Tomaselli wrote:
> > Why is their time more valuable than mine?
>
> Why do you think that your time is more valuable than theirs?
I think my time is more valuable than others because ther
On Fri, 15 Aug 2025 10:46:04 -0700, Otto Kekäläinen wrote:
I put screenshots of those yesterday at https://wiki2025.debian.org/wiki/Salsa
"Subscribe to email notifications about new Merge Requests in your
project" only makes sense if you maintain 1 (or 5) packages, not if
you're part of a te
Hi!
> This has happened to me in the past despite using DDPO and tracker.d.o
> regularly. Yes, DDPO shows open MRs, but it is incredibily easy to miss,
> especially if you happen to be involved in more than a handful of
> packages.
>
> In fact, I literally did "Ctrl+F !1" on my DDPO page on a hunc
Hi,
* Russ Allbery [2025-08-14 11:07]:
Otto Kekäläinen writes:
I have now witnessed several cases where a maintainer blatantly
ignored the MRs their package received.
As several of us have been noting for some time now, it is very easy to
accidentally ignore Salsa MRs because the defaults
On Fri, Aug 15, 2025 at 10:21:41AM -0700, Otto Kekäläinen wrote:
Also, I doubt that reviewing MRs actually takes that much time.
Hello! I have some data, at least for myself from when I went freelance
at the start of 2024 and started tracking most of the time I spend at a
keyboard. The foll
Le Fri, Aug 15, 2025 at 10:21:41AM -0700, Otto Kekäläinen a écrit :
> I don't advise people to disable MRs as it might discourage
> contributors and go against the Debian principle of "Be
> collaborative".
Well, I can’t satisfy both your request and the opposite request I got
from several people i
Hi,
> What I'm really missing here is the global picture of how this (= uses
> of Salsa beyond just using a Git repository) fits in Debian workflow_s_.
> Just saying "you can check open MRs from the command line with `salsa
> merge_requests` if you don't like checking the Salsa project page." is
>
> On Fri, Aug 15, 2025 at 09:11:27AM +0200, Salvo Tomaselli wrote:
> >Why is their time more valuable than mine?
>
> Why do you think that your time is more valuable than theirs?
This question by Marc hits what I think is the core of this discussion.
In my view, if somebody put in the effort to f
On 2025/08/15 13:23, Lucas Nussbaum wrote:
Alternatively, we could investigate whether it would make sense to merge
all Debian packages in a single "project" (either globally or one
project per team). That's what the Haskell Team is doing
(https://salsa.debian.org/haskell-team/DHG_packages/) and
On 15/08/25 at 19:02 +0900, Simon Richter wrote:
> Hi,
>
> On 8/15/25 6:26 PM, Lucas Nussbaum wrote:
>
> > All this is reasonable and meets real needs. As you care about better
> > integration of Salsa in Debian workflows, I think that you should review
> > what is the current integration level,
Hi,
On 8/15/25 6:26 PM, Lucas Nussbaum wrote:
All this is reasonable and meets real needs. As you care about better
integration of Salsa in Debian workflows, I think that you should review
what is the current integration level, and how it can be improved.
There is another debate below this: i
Hi Otto,
On 14/08/25 at 10:07 -0700, Otto Kekäläinen wrote:
> Hi!
>
> I encouraged DDs and DMs to review open Merge Requests on Salsa back in
> January:
> https://lists.debian.org/debian-devel/2025/01/msg00267.html. Hopefully
> folks can continue with doing reviews!
>
>
> ## Priority: Check MR
On 15/08/25 at 13:11 +0800, Blair Noctis wrote:
> (The last message got signing messed up, sorry)
>
> On 2025-08-14T22:21:56+0200, Salvo Tomaselli :
> > Hello,
> >
> > I do not want merge requests from random people. I want a bugreport
> > with an attached patch. How can I signal this to people? (
On Fri Aug 15, 2025 at 6:20 AM BST, Ansgar 🙀 wrote:
A principled opposition to apply patches or fix issues because the
author did not jump to an arbitrary set of hoops set up by a maintainer
seems like a bad idea. Enough security issues were not fixed or only
fixed much later because vendors insi
On Fri Aug 15, 2025 at 10:11 AM BST, Antoine Le Gonidec wrote:
PS: To prevent further confusion, I just disabled MR on all my Salsa
repostiories.
Thank you for doing this. I strongly disagree with your position that
people who open their dialogue with you via MR are "code dumping" and
should
On Thu, 14 Aug 2025 at 23:00:53 -0600, Antonio Russo wrote:
When I run in to a problem in Debian, I try to follow a rough pattern:
[0. I run into a problem]
1. I identify a suspect package, and diagnose a cause.
2. I identify a solution.
3. I implement the solution, recompile, and confirm it s
Le Fri, Aug 15, 2025 at 04:40:03PM +0800, Blair Noctis a écrit :
> (…)
> See, here's prejudice, to me. You implicitly assume *all* messages without a
> handshake "code dump", which I guess means low quality.
This is probably the root of our misunderstanding: my comment was never
about the quality
On 15/08/2025 16:22, Antoine Le Gonidec wrote:
Le Fri, Aug 15, 2025 at 03:57:29PM +0800, Blair Noctis a écrit :
I think you missed something: communications cost.
And me having to comply to a disagreeable workflow is free?
No, you are free to drop messages costing you more than you would lik
On Thu, Aug 14, 2025 at 11:07:32AM -0700, Russ Allbery wrote:
The best way to ensure that someone new gets appropriate attention and
encouragement is for someone to volunteer to be a mentor and commit some
time to that. I think this is great whenever people are willing to do it.
I don't have the
Le Fri, Aug 15, 2025 at 03:57:29PM +0800, Blair Noctis a écrit :
> I think you missed something: communications cost.
And me having to comply to a disagreeable workflow is free?
> (…)
> And people might consider the handshake to be exactly bureaucracy.
>
> While it might not appear as such to yo
On Fri, Aug 15, 2025 at 03:17:53PM +0800, Blair Noctis wrote:
- Submitter isn't notified about follow-ups (quite counter intuitive,
if this isn't meant to encourage one-off/fire-and-forget/etc. bug
reports)
- Uploaders don't get emails, while many packages are team maintained
and thus have the
On 15/08/2025 15:27, Antoine Le Gonidec wrote:
Le Thu, Aug 14, 2025 at 11:00:53PM -0600, Antonio Russo a écrit :
(…)
When I run in to a problem in Debian, I try to follow a rough pattern:
1. I identify a suspect package, and diagnose a cause.
2. I identify a solution.
3. I implement the solut
Le Fri, Aug 15, 2025 at 07:24:49AM +0200, Marc Haber a écrit :
> > (…)
> > A principled opposition to apply patches or fix issues because the
> > author did not jump to an arbitrary set of hoops set up by a maintainer
> > seems like a bad idea. Enough security issues were not fixed or only
> > fixe
Le Thu, Aug 14, 2025 at 11:00:53PM -0600, Antonio Russo a écrit :
> (…)
> When I run in to a problem in Debian, I try to follow a rough pattern:
>
> 1. I identify a suspect package, and diagnose a cause.
> 2. I identify a solution.
> 3. I implement the solution, recompile, and confirm it solves th
Hi,
thanks for reminding me that there are people who tick fundamentarily
different. One question remains, and then I am done with this part of
the thread.
On Fri, Aug 15, 2025 at 09:11:27AM +0200, Salvo Tomaselli wrote:
Why is their time more valuable than mine?
Why do you think that your
On 15/08/2025 13:00, Antonio Russo wrote:
(...)
This is very important to me because I have several open bug report
with patches that perhaps are being disregarded for this very reason,
and I'd like to understand how I can get people to look at them.
Would I need to close them and restart the wh
Hello,
> May I ask why? Is that a political thing?
? ??? ??
> Do you open the BTS web site,
No I don't. It emails me. I have no need to open it periodically. But
if I did, just be aware that it supports queries so I could bookmark
queries that are useful to me and see everything at
On 15/08/25 3:44 am, Jeremy Stanley wrote:
> On 2025-08-15 03:08:20 +0530 (+0530), Nilesh Patra wrote:
> [...]
>> Opening PRs/MRs are typically how most of the git forges are used
>> for contributions.
>>
>> Having salsa and allowing to open MRs and then saying that you
>> will accept a patch onl
On Fri, Aug 15, 2025 at 08:03:14AM +0200, Salvo Tomaselli wrote:
However by default salsa will not send an email when you create a MR,
and I personally (like many others I suspect) never open the salsa
website.
May I ask why? Is that a political thing? Do you open the BTS web site,
or the pack
Hello,
> If I am understanding this email correctly, it sounds to me like you
> are saying that this is a "code dump" because I didn't email you first.
It's different for every maintainer.
However by default salsa will not send an email when you create a MR,
and I personally (like many others I
On Fri, Aug 15, 2025 at 07:20:29AM +0200, Ansgar 🙀 wrote:
On Fri, 2025-08-15 at 00:23 +0200, Antoine Le Gonidec wrote:
Opening an MR without having contacted me *prior to the fact* is the
definition of a code dump. I do not care about code, I can very well
write it myself in the first place.
[.
On 2025-08-14 16:23, Antoine Le Gonidec wrote:
Opening an MR without having contacted me *prior to the fact* is the
definition of a code dump. I do not care about code, I can very well
write it myself in the first place.
What I care about is people, especially people who want to fix or
improve a
Hi,
On Fri, 2025-08-15 at 00:23 +0200, Antoine Le Gonidec wrote:
> Opening an MR without having contacted me *prior to the fact* is the
> definition of a code dump. I do not care about code, I can very well
> write it myself in the first place.
[...]
> If sending an e-mail is too much for them, we
(The last message got signing messed up, sorry)
On 2025-08-14T22:21:56+0200, Salvo Tomaselli :
> Hello,
>
> I do not want merge requests from random people. I want a bugreport
> with an attached patch. How can I signal this to people? (without
> spending an inordinate amount of time in salsa to c
On Thu, Aug 14, 2025 at 10:32:58PM +0100, Wookey wrote:
If these MRs got turned into bugreports automagically that could be
helpful. Listing them on tracker.d.o would also work (eventually).
The suggested tool to just turn the MR feature off (for my packages)
so that the problem doesn't arise sou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2025-08-14T22:21:56+0200, Salvo Tomaselli :
> Hello,
>
> I do not want merge requests from random people. I want a bugreport
> with an attached patch. How can I signal this to people? (without
> spending an inordinate amount of time in salsa to c
1 - 100 of 125 matches
Mail list logo
