On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com> wrote: >> -----Original Message----- >> From: Bill Fischofer [mailto:bill.fischo...@linaro.org] >> Sent: Thursday, January 19, 2017 11:53 PM >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell- >> labs.com> >> Cc: lng-odp-forward <lng-odp@lists.linaro.org> >> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files >> >> This series represents a significant structural change and as such >> should go against api-next, not master. Patches aimed at master should >> be bug fixes, not something that introduces new structure development. > > > I think we should stop right here of doing "significant changes" through > api-next. Last time that policy effectively stopped the work in master due to > dependencies over many files changed. Api-next should be reserved only for > API spec changing modifications, since only those are visible to > applications. E.g. changes in ABI does not require any application change. > Today our "ABI" support is non-existent. This sets ground work for files and > Makefiles to enable ABI(s) and force that.
I would argue that we should use branches, the problem was not api-next IMHO, but rather we had major changes from multiple contributors that collided in that one location. We ended up halting all work in api-next whilst the underpinning work was completed, not a criticism as such but the same would happen to any single repository bottle neck. I think we need to develop on parallel branches and then when they are ready they are just merged. I could see two important maintainer branches in parallel to master. api-next owned by you driver owned by Christophe When either of these major work area branches (on your own public repo) is ready you just send maxim a pull request and he can be sure the branch owners have already attained the required reviews etc. Releases are super simple now, all pre tested and reviewed ready to go, merge and tag, it also scales to any amount of parallel conflicting work. > > >> >> While the goals here seem good, I'm concerned that at this stage >> applying this removes strong typing support. For example, as an >> experiment I changed the buffer validation test to contain this error: > > I'll look into strong typing as default. But vendors may very well agree not > to support it, since it requires handles to be pointer size types. E.g. arm64 > ABI may be agreed to use uint32_t for handles instead of pointers. > > -Petri -- Mike Holmes Program Manager - Linaro Networking Group Linaro.org │ Open source software for ARM SoCs "Work should be fun and collaborative, the rest follows"
