On 05/08/2015 01:15, Anders Roxell wrote:
On 2015-05-07 16:26, Bill Fischofer wrote:
On Thu, May 7, 2015 at 11:50 AM, Maxim Uvarov <[email protected]>
wrote:
Here I have patches from api-next needed to be merged to master:
https://git.linaro.org/people/maxim.uvarov/odp.git/shortlog/refs/heads/api-next
There are 4 commits:
5f9b8df example: classifier: remove odp_pmr_create_range() support
dab82ac validation: remove test case for odp_pmr_create_range() function
3bd420c api: classification: remove odp_pmr_create_range() function
definition.
088cea5 linux-generic: classification: remove odp_pmr_create_range()
function implementation.
The only thing wrong I see with this sequence is the removal of the API
should be last, so reverse the order of patches 3 and 4.
That wont work, because the patches don't do what it stats its doing in
the commit log...
For instance: api: classification: remove odp_pmr_create_range() function
definition
Don't lie there, however, it does a lot more e.g., remove
odp_pmr_create_match() and add odp_pmr_create() function
What we should have done would be to add a first api patch that adds the
new api + implementation for that and then build the 4 patches on that.
For this specific case we can either look the other way and hope we will
never need to do git bisect below this point, squash the patchset or
revert it and redo the patchset.
Cheers,
Anders
Ok, I'm going to squash them if nobody needs that separate commit.
Maxim.
Which breaks git bisect. So I'm thinking what is better to do here merge
them to one commit or
leave as is.
pros for not squash to 1 patch:
+ logic split patches from api, validation and example easy for post merge
review.
cons for not squash to 1 patch:
- not git bisect command friendly, but commits grouped and followed one by
one.
So that git bisect --skip can avoid this block;
pros to squash to 1 patch:
+ git bisect friendly;
cons to squash to 1 patch:
- one monster patch.
For now I think it's better to not squash that commits to single commit.
Any ideas what is better to do in that case?
I think we should define somewhere that such separation for api patches &
tests are acceptable.
Thanks,
Maxim.
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
