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

[Alexandre Janniaux]

Hi,

On Fri, Sep 18, 2020 at 08:25:21PM +0100, Lyndon Brown wrote:
> 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.

To be honest, I don't think that's your fault or that you need
to justify yourself. Some developers here prefers mail patches,
others attached patches for ease of download, and others prefer
git branches.

I'm personnally ok with the three method, without any complex
setup to do.

However, in the current situation without MR, the main issue is
that patches are not linked to the discussion, which is a bit
annoying, and in the long term vision patches are not in the
mailing list, which make them «invisible».

Except from that, whatever the method you choose, you still
need someone to review it but it probably takes as much time
for any method as the others -- though mail is usually much
faster but biased because git branch are usually much longer.

Regards,
--
Alexandre Janniaux
Videolabs