Note, "driver" would stage though next for CI to look at it just as api-next does.
On 20 January 2017 at 08:08, Mike Holmes <mike.hol...@linaro.org> wrote: > 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" -- Mike Holmes Program Manager - Linaro Networking Group Linaro.org │ Open source software for ARM SoCs "Work should be fun and collaborative, the rest follows"
