<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020 at 9:31 AM Michael Van Canneyt <<a href="mailto:michael@freepascal.org">michael@freepascal.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Wed, 13 May 2020, Christo Crause via fpc-pascal wrote:<br>
<br>
> On Tue, May 12, 2020 at 11:11 PM Noel Duffy via fpc-pascal <<br>
> <a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.org</a>> wrote:<br>
><br>
>> Sure, I can do that. I will look at creating a patch for this. For your<br>
>> purposes, do you prefer to have a new bug in the bug tracker opened for<br>
>> tracking this change?<br>
>><br>
><br>
> If your patch is related to an existing open bug report then keep updates,<br>
> discussions etc. under the same report, else the information gets<br>
> fragmented. A reporter cannot delete his/her own old patches, so just<br>
> append a version number to a new patch, if the patch completely replace a<br>
> previous patch, and mention the changes/updates in a comment. In your case<br>
> something like StrToHostAddr6-v2.patch for an updated patch.<br>
<br>
That is correct if you want to fix a wrong patch.<br>
<br>
But not what you should do for this case, because there are 2<br>
issues: fix existing api, and extend the existing api (a refactor).<br>
<br>
So: separate reports, and if so desired add a link in 'related to'.<br></blockquote><div> </div><div>Apologies, I should probably only comment if I followed all the details of the discussion...</div></div></div>