[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: makelsr
From: |
Phil Holmes |
Subject: |
Re: makelsr |
Date: |
Sat, 29 Dec 2018 17:21:13 -0000 |
----- Original Message -----
From: "Malte Meyn" <address@hidden>
To: <address@hidden>
Sent: Saturday, December 29, 2018 9:29 AM
Subject: Re: makelsr
Am 28.12.18 um 21:33 schrieb Phil Holmes:
A little late to the party, but I am almost certain that running makelsr
to create an LSR patch and then (after testing with at least make, make
doc) and pushing that patch, and then putting up the doc patch for review
is a perfectly accestable way to go. I've rather got out of the habit,
but I regularly used to run makelsr, eyeball it carefully (as in the CG)
then push it without review. Extra files in the patch won't break the
build, only missing ones.
I think that this sounds like the easiest way. That way every single
commit ‘make’s without problems, there is no makelsr output in the review
of the then following doc patch and one doesn’t have to mess with
different branches. (Ok, I have to admit that I simply didn’t understand
exactly how the solution with separate commits and a merge should look
like. But it seems as if I’m not the only one.)
Could you, Phil, please push such a makelsr run as you described? As long
as I don’t have permission/trust from some of you to do this without
review, I’d have to go the ‘long’ Rietveld way.
Of course, if there are objections against this way, I’ll try to figure
out how exactly the ‘separate-branches-and-merge-commit’ thing works.
Pushed to staging and then patchy-ed to master.
--
Phil Holmes