On 9/16/24 10:35, sia kc wrote: > > > On Mon, Sep 16, 2024 at 11:28 AM Tomas Vondra <to...@vondra.me > <mailto:to...@vondra.me>> wrote: > > On 9/16/24 00:17, sia kc wrote: > > I have a bad experience. I picked up a task from MariaDB backlog, > > explained in their chat rooms that I started doing that. After it was > > done which was a SQL command which MySQL already supported to restart > > server instance with SQL, they started rethinking the validity of the > > feature for the MariaDB. So the task got suspended. > > > > Unfortunately this can happen here too, to some extent. Sometimes it's > not obvious how complex the patch will be, the feature may conflict with > another feature in some unexpected way, etc. It's not like we have a > 100% validated and agreed design somewhere. > > > > This is why my advice is to pick a patch the contributor is personally > interested in. It puts him/her in a better position to advocate for the > feature, decide what trade offs are more appropriate, etc. > > By picking a patch I assume you mean picking an already done task and > seeing for example how I would have done it, right? >
I mean both the patch you'd review and the patch/feature you'd be writing yourself. My experience is that when a person is genuinely interested in a topic, that makes it easier to reason about approaches, trade offs, and stick with the patch even if it doesn't go smoothly. It's a bit similar to a homework. I always absolutely hated homework done only for the sake of a homework, and done the absolutely bare minimum. But if it was something useful/interesting, I'd spend hours perfecting it. Patches are similar, IMO. If you pick a patch that's useful for you (e.g. the feature would make your job easier), that's a huge advantage IMO. regards -- Tomas Vondra
