[vlc-devel] [PATCH] esformat/transform work resubmission

[Lyndon Brown]

On Fri, 2020-09-18 at 20:31 +0300, Rémi Denis-Courmont wrote:
> Le torstaina 17. syyskuuta 2020, 1.26.18 EEST Lyndon Brown a écrit :
> > Resubmitting this now what with someone trying to add a transform
> > property to demux-mock and AJ having filed a couple of bugs
> > recently
> > relating to transformations. If correctness of transformations is
> > under
> > investigated, then there's more pressure to get my fixes to the
> > core
> > functionality in place.
> > 
> > I've put the work on a clean branch here (13 commits):
> > https://code.videolan.org/jnqnfe/vlc/-/tree/transform
> 
> A tree is hardly better than a zip file. There's no reasonable way to
> review 
> it. (In Gitlab, you're supposed to review merge requests, and they
> are not in 
> place for VLC at this time.)
> 
> Can't you please use git-send-email like everybody else does?

I understand the issue, and I've been holding back a lot of work
waiting to be able to submit via gitlab-MRs since the announcement of
moving to it early last year because I knew that attaching wasn't ideal
for you guys. I'm told it should be opened up this month; I'm eagerly
awaiting it having just put in the work in to rebase almost all of it.
I've had no intention these past few weeks of submitting any of it
until through MRs, but a couple of discussions prompted immediate re-
submission of a couple of blocks of old work, and AJ suggested a tree
would be better/okay in one case. Yesterday I ended up firing off a
bunch of the smallest/simplest things, including a few additional
blocks where there were too many to seem appropriate for attachments.
I've had no intention of sending more like that if you did not seem
open to it, and you're not, so as planned, I'll keep waiting for MRs
with the big blocks.

With respect to git-send-mail... It's not something I've ever used. I
tried setting things up a few weeks ago, but it was problematic. The
biggest issue is that I'd be wanting to push things through Evolution,
and Evolution does not particularly like allowing users to send un-
wrapped emails, and of course if wrapping occurs, the patches are
corrupted. I'd want to send through Evolution rather than directly in
order to preview and ensure that I've not screwed up selecting the
right range of commits, and to write the initial cover message (though
I presume there's some facility for doing that otherwise). I could
switch back and forth between having git send to my drafts folder and
directly, to bypass the wrapping issue, but that's a pain and open to
mistakes.

Then there's concern whether sending via my drafts folder with
Evolution would actually preserve the threading correctly, and
additionally git-send-mail doesn't work with 2FA, so I'd need to create
a second 2FA-less password just for git, since it does not seem
possible for it to place them in a local drafts directory (and I'm not
aware that I can have mboxes written to disk and manually move them in
to the drafts folder, or open them in Evolution). I could write the
commits to files (as I do for attaching), and copy&paste the contents
directly into individual emails, but I'm not certain that would work
properly, never mind again the wrapping issue.

I really seems like a lot of hassle to spend time experimenting with
and risk in possibly things going wrong, to be worthwhile when MR
submissions is imminent.

Again though, the intention has not been to be a pain submitting
everything as trees/zips, and I'll try to refrain from sending any more
like that. I appreciate the review difficulty with it.