Here come my 2 cents:
I think that the branch vs. repo argument should depend on the maintainer. One of the most important attrobutes of a repo, is its own access control, which is independent of all other repos. Also, when an SoC implementation is in a separate repo, the source includes the exact same example and test applications, documentation and header files as linux-generic from master, so a user can always merge several implementations into a single source tree. For this to be easy, I think that even linux-generic implementation itself should be present in all other implementations, for easier merges from master. All implementations maintained by Linaro can be just branches in a single repo, but each SoC vendotr probably should have their own repo, where all Linaro brances are also present, pkus the vendor's SoC implementations, one per branch. We are already maintaining our internal GIT repo, which has the master branch regularly synced with the Linaro repo master branch contentents, and each of our internal project is in its own branch within the same repo. Each of these projects can either periodically sync to the master branch at will, or even cherry pick commits from master (which are synced from Linaro master branch), as needed. - Leo ________________________________ From: [email protected] <[email protected]> on behalf of Mike Holmes <[email protected]> Sent: Friday, September 19, 2014 2:44 PM To: Jacob, Jerin Cc: Hillo, Jarmo (NSN - FI/Espoo); ext Magnus Karlsson; [email protected] Subject: Re: [lng-odp] Relaxing merge process On 19 September 2014 17:28, Jacob, Jerin <[email protected]<mailto:[email protected]>> wrote: How about git "submodules", A master git odp repo and platforms specific sub repos within it.Best of both worlds. http://git-scm.com/book/en/Git-Tools-Submodules A lot of the different SoC implementations will never be submodules though, only the public ones will be making a difference for users. IMHO upstream ODP should just be the reference, which is then just the docs (some examples), the unit tests and linux-generic which is obviously also the important part because it is the API reference which is the part that really matters. After chatting a bit just now I even agree that netmap should be its own repo following the "all implementations have their own repo" model. ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Mike Holmes <[email protected]<mailto:[email protected]>> Sent: Saturday, September 20, 2014 2:40 AM To: Taras Kondratiuk Cc: ext Magnus Karlsson; Hillo, Jarmo (NSN - FI/Espoo); [email protected]<mailto:[email protected]> Subject: Re: [lng-odp] Relaxing merge process My 2 cents Repos: * A private SoCs implementation such as Axxia, Cavium, Freescale are already separate repos, why should public ones be different ? * When you pull you only get the implementation you want, you don't get others for "free" i.e. if I want KS2 and I don't care about DPDK I don't get DPDK Branch: * All in one place for public variants - more open source, but ODP is not pure open source, a lot of members never will be. I think the strongest argument is for keeping it all working the same way so I vote for separate repos So a 1.0 is called for when linux-generic meets these requirements - The API feature set has been agreed by SC <- by necessity all platforms who are Members of ODP get to define this I suspect this step will ensure the API is acceptable to all, even if not complete on all platforms (as we just experienced with crypto) - The doxygen documentation is complete - The unit tests all pass - The code builds for all variants of linux-generic, currently the only variant is netmap Then DPDK, KS2, Axxia, Octeon all catch up when they also pass those same test criteria. On 19 September 2014 16:29, Taras Kondratiuk <[email protected]<mailto:[email protected]>> wrote: Yes something like this. On 09/19/2014 12:07 PM, Mike Holmes wrote: > As repos, something like this ? > > On 19 September 2014 14:55, Taras Kondratiuk > <[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>>> > wrote: > > Both approaches have pros and cons. > I prefer branches, so all open implementations can be found in one > upstream place. I hope there will be more open implementations in > future :) > > The main point we should keep in mind is that linux-generic (master > branch) won't be completely independent from other implementations even > if they are in a separate repositories (private or public). At release > points several implementations should be at the same API level to prove > that API can be implemented. So we can't just tag v1.0 on master branch > when linux-generic is ready. > As an option these parts can be in a separate repositories, but get > pulled into release branches which forked from master branch. > > On 09/19/2014 11:31 AM, Hillo, Jarmo (NSN - FI/Espoo) wrote: > > Agree that separate repos make more sense than branches. Jarmo > > > > > > Sent from Samsung Mobile > > > > > > -------- Alkuperäinen viesti -------- > > Lähettäjä: ext Magnus Karlsson > > Päivämäärä:19.09.2014 10.25 (GMT-08:00) > > Saaja: Taras Kondratiuk > > Kopio: [email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>> > > Aihe: Re: [lng-odp] Relaxing merge process > > > > Taras, > > > > Sounds good as long as we substitute the word branches with > > repositories. Branches do not make much sense IMHO. > > > > Magnus > > > > Den 19 sep 2014 09:40 skrev "Taras Kondratiuk" > > <[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>> > <mailto:[email protected]<mailto:[email protected]> > > <mailto:[email protected]<mailto:[email protected]>>>>: > > > > I'd like to sum up our yesterday's discussion about making merge > > process more > > relaxed. Current process with a single master branch assumes that > > each patch > > need to keep all platforms in a working state, which is next to > > impossible, > > because patch author doesn't have enough expertise in all > platforms. > > The same > > happens with a complex examples. This leads to a significant slow > > down of new > > API sets development. > > > > The idea we came up with is to split the master branch into > several > > branches: > > - master: contains core LNG deliverables: linux-generic, tests and > > simple > > examples > > - implementation branches (linux-keystone2, linux-dpdk, etc): > > contains one > > implementation > > - examples: contains complex examples like IPSec. > > > > Each branch has its maintainer. > > At release point when linux-generic has everything for release we > > fork a release > > branch (odp-v1.0) from master. Other branches get pulled into > > release branch > > when branch maintainer have updated it to the same API level as > > linux-generic in > > release branch. > > > > This approach allows to unblock and speed up linux-generic > development. > > As before patches to any branch should go through ML review > process. > > > > -- > > Taras Kondratiuk > > > > _______________________________________________ > > lng-odp mailing list > > [email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>> > <mailto:[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>>> > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > To unsubscribe from this group and stop receiving emails from it, > > send an email to > [email protected]<mailto:lng-sc%[email protected]> > <mailto:lng-sc%[email protected]<mailto:lng-sc%[email protected]>> > > > <mailto:lng-sc%[email protected]<mailto:lng-sc%[email protected]> > > <mailto:lng-sc%[email protected]<mailto:lng-sc%[email protected]>>>. > > > > > -- > Taras Kondratiuk > > _______________________________________________ > lng-odp mailing list > [email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>> > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > -- > *Mike Holmes* > Linaro Technical Manager / Lead > LNG - ODP -- Taras Kondratiuk -- Mike Holmes Linaro Technical Manager / Lead LNG - ODP -- Mike Holmes Linaro Technical Manager / Lead LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
