On 9/16/24 10:35, sia kc wrote:
>
>
> On Mon, Sep 16, 2024 at 11:28 AM Tomas Vondra <tomas@vondra.me
> <mailto:tomas@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
