On 19 September 2014 17:28, Jacob, Jerin <[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] <[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]>
> 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
>



-- 
*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