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]>
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]>>
> 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]>
> >     > 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]>>>:
> >     >
> >     >     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]>>
> >     >     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]>>.
> >     >
> >
> >
> >     --
> >     Taras Kondratiuk
> >
> >     _______________________________________________
> >     lng-odp mailing list
> >     [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

Reply via email to