On Fri, Jan 20, 2017 at 7:22 AM, Mike Holmes <mike.hol...@linaro.org> wrote: > 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. >>
+1 for the development branch approach. I think we've reached the level of maturity in the project where that technique should be the default for any larger changes. >>> >>> >>>> >>>> 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"
