[FFmpeg-devel] [RFC] What to do with 15k euro from STF?

[epirat07 at gmail.com]

On 12 Nov 2024, at 10:09, Diederick C. Niehorster wrote:

> On Tue, Nov 12, 2024 at 9:44 AM martin schitter <ms+git at mur.at> wrote:
>>
>>
>>
>> On 12.11.24 08:51, Martin Storsjö wrote:
>>> On Tue, 12 Nov 2024, martin schitter wrote:
>>>
>>>> The git history of Patches here on this mailinglist are usually
>>>> rewritten whenever one of the reviewers requests some change, but the
>>>> typical workflow in github/gitlab doesn't use or even forbids this
>>>> kind of changes in uploaded code resp. forced pushes. It's enforcing a
>>>> strict incremental timeline of changes.
>>>
>>> This is entirely up to the policy of each individual project; it's
>>> totally possible to use the exact same workflow with rewriting and force
>>> pushing the PR/MR branch, with both github and gitlab. Gitlab is usually
>>> a bit better at tracking review state across such events than github
>>> though. Anyway, this is how all such reviews are conducted on e.g. the
>>> videolan gitlab/projects.
>>
>> Well -- you can try to work around these limitations to some degree, but
>> as a rule of thumb you should simply avoid git history rewrites and
>> forced push's in MRs and any other form of published/shared remote
>> branches in GitLab, although no strict protection mechanism will hinder
>> you to use it in your own forks or any other unprotected branch, where
>> you have sufficient access privileges, but the system simply doesn't
>> like this kind of handling -- i.e. it will cause unwanted side effects:
>
> Wouldn't the solution be for each new version of a patch to be a new
> merge request, linked in the message to the previous MR (which is
> closed when the new version is posted)?

IMO thats a terrible workflow as it looses context (but of course nothing prevents
you from doing it).

Like I said in my other reply, I have yet to see any big issues by force-pushing to MRs,
we do it at VideoLAN for years already.

>
> Cheers,
> Dee
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".