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 ________________________________ From: [email protected] <[email protected]> on behalf of Mike Holmes <[email protected]> Sent: Saturday, September 20, 2014 2:40 AM To: Taras Kondratiuk Cc: ext Magnus Karlsson; Hillo, Jarmo (NSN - FI/Espoo); [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
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
