You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@predictionio.apache.org by Pat Ferrel <pa...@occamsmachete.com> on 2016/08/14 15:30:18 UTC
0.10.0 release
Important things unresolved for release:
1) What to do with Apache templates—my suggestion is separate repos for the 3 reasons below.
2) We need a Gallery page listing at least a couple converted tested templates—couldn’t find this in the site but maybe I missed it. The UR is now converted and tested as are the examples.
3) AML fork healed, should be pushed this afternoon.
4) the rest of the release magic
PIO is rather moot without templates but if they are on a separate release schedule like the doc site (which also needs work) we could release without 1 & 2. I’d favor that rather than releasing with templates in a templates/ directory.
Anything else? How are people feeling about release?
On Aug 12, 2016, at 10:18 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
Independent of Apache I’d suggest each template have their own git repo as they do now. Is this practically possible in ASF (another example of my infrastructure rant but leave that for now). The semantics of this make sense. The requirements for all apache or non-apache templates seem to be:
1) They need to be allowed to have separate release cycles.
2) There should be only one way to install templates apache or non-apache
3) This method should support tags and branches, and separate PRs
Practically speaking for independent ones (the Universal Recommender will remain independent until the issues above are resolved) the templates *will* be a separate repo and `git pull` *will* be the method of download. To me this implies the Apache ones should use the same pattern.
The separate issue of rules for inclusion in Apache should include a test requirement IMO. But inclusion in the Gallery seems a looser attachment to the project—just one persons opinion
On Aug 11, 2016, at 3:42 PM, Chan Lee <chanlee514@gmail.com <ma...@gmail.com>> wrote:
I've begun working on migrating official PredictionIO templates into the main apache repository, and there are a few points I'd like to bring to attention.
1) Template code will be merged under templates/ directory, and all commit history and authorship will be preserved.
2) Organization namespace will change in the template code from "io.prediction" to "org.apache.predictionio".
3) In order to download an engine template, users could (1) git clone the entire repo and copy the files in templates/<some-template>, or (2) use something like svn to download only the necessary subdirectory. I'd like to ask what everyone thinks should be the recommended approach. The documentation should be updated accordingly (instead of `pio template get`).
4) I'd like to ask if there are any ActionML/outside templates that should be included or updated. For instance, template-scala-parallel-universal-recommendation in PredictionIO repo seems outdate compared to one in actionml repo.
Thanks,
Chan
On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński <zieminm@gmail.com <ma...@gmail.com>> wrote:
I think that this is a very good idea. Obviously it would require
configuring more concurrent builds to finish in reasonable time, what
should not be a problem. Besides, it would make the official templates be
consistent with every next release of PredictionIO and what is very
important - it would provide many different tests for the repository.
Having working templates of different types could give us more material to
test not only the reliability of PredictionIO, but also its performance
with every change. It would require adding different types of tests and
tools to gather runtime statistics, but this is something I would like to
take a look at in the future.
niedz., 7.08.2016 o 10:21 użytkownik Donald Szeto <donald@apache.org <ma...@apache.org>>
napisał:
> We can also make these templates part of the integration test that Chan and
> Marcin just submitted (
> https://github.com/apache/incubator-predictionio/pull/267 <https://github.com/apache/incubator-predictionio/pull/267>). That way we
> can
> make commitment to included templates be part of every committer's effort.
> Just my 2c.
>
> On Sun, Aug 7, 2016 at 9:47 AM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
>
> > If this sound ok, I propose the process be:
> > 1) inclusion in the gallery is a PR to the yaml gallery file. This is
> > reviewable by all but takes only one committer to approve and merge.
> > 2) submission for inclusion in the project can be a PR to the new
> > templates directory as Simon suggests. But this may require a more formal
> > vote, and come with some commitment for support and possibly
> consideration
> > of the author for committer status.
> >
> > Someone who knows Apache rules better than me may know the type of vote
> to
> > have for #2, maybe this is only informal review and single committer
> > acceptance too as long as the committer is willing to support the
> template.
> >
> > As far as the Salesforce templates marked official, I’d hope that most
> > would be donated. According to the proposed rules all we need is a PR for
> > each. And again a big thanks to Salesforce!
> >
> >
> > On Aug 4, 2016, at 2:55 PM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
> >
> > Actually this is mostly a fine idea but I think the bigger question is
> how
> > do we treat templates in general.
> >
> > IMO the maintaining author can decide to contribute them or not and the
> > committers can decide to accept or not. For example in the case of the
> UR I
> > may decide to support and maintain it outside of Apache while some from
> > Salesforce might be submitted as donations. Donation comes at some
> > obligation. There are lots of examples in Mahout of algorithms whose
> > authors no longer support them. These are slowly being deprecated and
> > removed so I’d like to see a method that avoids this issue.
> >
> > If we allow maintainers to submit templates to the Gallery with a link to
> > code as well as support then donating the template code to Apache is
> > independent of acceptance to the Gallery. Any template donated to Apache
> > should come with some commitment by the author to support it there
> > indefinitely and perhaps even acceptance as a PIO committer—and if they
> > disappear or don’t support the template it is easy to deprecate/remove.
> >
> > That means if Salesforce wants to donate the templates it
> maintains—great.
> > Personally I'd would vote for acceptance of most of them. Then the
> support
> > link can be to the Apache user list or instructions for joining it. If a
> > maintainer wants to stay out of the Apache repo and support separately
> then
> > this is possible also. With all templates treated equally—official or
> > not—and there is a route to becoming official for non-official ones.
> >
> > BTW it might be good to remove the “official” designation in favor of
> > “Apache supported” or the PredictionIO logo or something like that. We
> > really need to encourage template development even if they are not code
> > contributions.
> >
> >
> > On Aug 3, 2016, at 3:32 PM, Simon Chan <simon@salesforce.com <ma...@salesforce.com>> wrote:
> >
> > Hey guys,
> >
> > I just want to start the discussion about moving previously "official"
> > PredictionIO engine templates into Apache.
> >
> > Official templates are those marked "Official" here:
> > http://templates.prediction.io/ <http://templates.prediction.io/>
> >
> > In order to move them to ASF Git, would the best way be creating
> > sub-directory under PredictionIO repo?
> >
> > Simon
> >
> >
> >
>
Re: 0.10.0 release
Posted by Simon Chan <si...@salesforce.com>.
Sorry for the slow reply. I was waiting for some internal replies.
Donald will continue to follow up on the issue.
Regards,
Simon
On Wed, Aug 17, 2016 at 11:37 AM, Donald Szeto <do...@apache.org> wrote:
> I am keeping track of the SGA progress on SFDC side and will keep you guys
> updated.
>
> On Tue, Aug 16, 2016 at 4:43 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
>> Thanks for the clarification. I could have phrased that better too. Not
>> meant to sound abrasive.
>>
>> On Tue, Aug 16, 2016 at 3:53 PM, Pat Ferrel <pa...@occamsmachete.com>
>> wrote:
>>
>>> I don’t expect you to know where Simon is, I was just seeing if anyone
>>> on the list knew, some are relatives and friends of his and even work at
>>> the same location. I’m pretty sure Simon has the answers to take us to the
>>> SGA or get one created.
>>>
>>> Not trying to dump work on you Andy, just trying to track down the
>>> answers and not all questions are addressed to you :-)
>>>
>>>
>>> On Aug 16, 2016, at 3:39 PM, Andrew Purtell <ap...@apache.org> wrote:
>>>
>>> As I explained on the INFRA JIRA Pat I'm quite clear what was granted and
>>> if it's not already in an Apache repo it was not granted by that SGA.
>>>
>>> Sure, Simon would be a reasonable place to start for a new SGA
>>> discussion.
>>> I have no idea what he's up to, I'm not his keeper.
>>>
>>> On Tue, Aug 16, 2016 at 3:36 PM, Pat Ferrel <pa...@occamsmachete.com>
>>> wrote:
>>>
>>> > AFAIK Salesforce owns the code and Simon must have filled out the
>>> original
>>> > PIO grant, which may cover all the templates already. He also started
>>> this
>>> > discussion so I think we start with Simon unless someone knows better.
>>> Is
>>> > he on vacation?
>>> >
>>> >
>>> > On Aug 16, 2016, at 3:30 PM, Andrew Purtell <ap...@apache.org>
>>> wrote:
>>> >
>>> > I see that Pat filed INFRA-12441 (
>>> > https://issues.apache.org/jira/browse/INFRA-12441) which I read asks
>>> to
>>> > import code from GitHub repositories under the old PIO organization
>>> not yet
>>> > granted to the ASF.
>>> >
>>> > This presents you with a great opportunity to learn how software grants
>>> > work. (smile) Even when you are out of incubation this process will
>>> still
>>> > be necessary for imports of third party code not covered by an existing
>>> > SGA, CCLA, or ICLA. The procedure is pretty simple, assuming a single
>>> > rights holder (which is the case I believe for the scope of this
>>> request).
>>> > I encourage the PPMC to work out who will contact the rights holder to
>>> > execute a SGA (https://www.apache.org/licenses/software-grant.txt)
>>> that
>>> > covers all of the code you would like to import. When the granted code
>>> is
>>> > coming from a GitHub repository, Exhibit A should list all repository
>>> URLs
>>> > and exact SHAs desired for import covered by the grant.
>>> >
>>> > I'm happy to assist but the PPMC should take the lead. Good luck!
>>> >
>>> >
>>> > On Tue, Aug 16, 2016 at 2:27 PM, Andrew Purtell <ap...@apache.org>
>>> > wrote:
>>> >
>>> >> Go to https://issues.apache.org/jira/ and log in. Find the read
>>> 'Create'
>>> >> button. There's a drop down menu immediately to the right of it. Open
>>> > that
>>> >> menu, then click on 'New Git Repository'.
>>> >>
>>> >> The original request was here: https://issues.apache.
>>> >> org/jira/browse/INFRA-12112
>>> >> The second request for site was here: https://issues.apache.
>>> >> org/jira/browse/INFRA-12180
>>> >>
>>> >>
>>> >> On Tue, Aug 16, 2016 at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com>
>>> >> wrote:
>>> >>
>>> >>> +1
>>> >>>
>>> >>>
>>> >>>> On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org>
>>> wrote:
>>> >>>>
>>> >>>> 1) I’ll volunteer to take a couple templates and put them in their
>>> own
>>> >>> repos if we can get some created.
>>> >>>> Sure. I believe Chan might have some converted repos as well.
>>> >>>>
>>> >>>> 2) do we have a gallery page yet? we had a good proposal, is it
>>> >>> implemented?
>>> >>>> It's already been merged in develop. Once we release the old
>>> template
>>> >>> gallery will become a redirection to the new static page.
>>> >>>
>>> >>> This is needed only for historical reasons, right? The big blue
>>> Template
>>> >>> button will go there directly after release, I assume.
>>> >>>
>>> >>>>
>>> >>>> 3) What templates are worth inclusion? Seems like some of the ALS
>>> >>> recommender ones are supersets of others do we need them all?
>>> >>>> We should start with a core set of templates and one or a couple
>>> that
>>> >>> focuses on a use case (since they are popular): vanilla,
>>> recommendation
>>> >>> (both Scala and Java), similar product, classification, e-commerce,
>>> and
>>> >>> text classification.
>>> >>>
>>> >>> sounds good, that is 7. @chan have you scrubbed any of these?
>>> >>>
>>> >>>>
>>> >>>> 4) do we need “release” of these except through Apache git and
>>> Github?
>>> >>> Since they are all built by users I suspect the normal Apache release
>>> >>> process can be avoided for them, the full push to maven, binary
>>> hosting,
>>> >>> etc.
>>> >>>> I vote for maintaining the above set of templates to be at least
>>> >>> working and passing integration tests for the main release. They do
>>> not
>>> >>> necessarily go into the final binary distribution, but they should
>>> all
>>> > be
>>> >>> tagged and tested against with every release of PredictionIO.
>>> >>>
>>> >>> +1
>>> >>>
>>> >>>>
>>> >>>> 5) We need someone to file Infra Jira’s to get repos. If someone can
>>> >>> coach me on this I will do it.
>>> >>>> My guess is we can just file an infrastructure ticket to spawn some
>>> >>> discussion.
>>> >>>>
>>> >>>
>>> >>> Who did the original request for repo? Can someone point me to the
>>> Jira,
>>> >>> I’ll take it from there
>>> >>>
>>> >>>>
>>> >>>> This might only add a week or so to the release date. If we don’t
>>> do it
>>> >>> I bet it will be much more time spent in support and fixing later.
>>> >>>> Agree. If we all agree let's make this the final major thing to do
>>> >>> before 0.10.0 release to avoid feature creep.
>>> >>>>
>>> >>>
>>> >>> +1, with the possible exception of fixing install.sh
>>> >>> https://issues.apache.org/jira/browse/PIO-22 One option is to
>>> remove it
>>> >>> from the release, which I favor, discussion on the jira.
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> Best regards,
>>> >>
>>> >> - Andy
>>> >>
>>> >> Problems worthy of attack prove their worth by hitting back. - Piet
>>> Hein
>>> >> (via Tom White)
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Best regards,
>>> >
>>> > - Andy
>>> >
>>> > Problems worthy of attack prove their worth by hitting back. - Piet
>>> Hein
>>> > (via Tom White)
>>> >
>>> >
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> - Andy
>>>
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>
>
>
Re: 0.10.0 release
Posted by Donald Szeto <do...@apache.org>.
I am keeping track of the SGA progress on SFDC side and will keep you guys
updated.
On Tue, Aug 16, 2016 at 4:43 PM, Andrew Purtell <ap...@apache.org> wrote:
> Thanks for the clarification. I could have phrased that better too. Not
> meant to sound abrasive.
>
> On Tue, Aug 16, 2016 at 3:53 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
>> I don’t expect you to know where Simon is, I was just seeing if anyone on
>> the list knew, some are relatives and friends of his and even work at the
>> same location. I’m pretty sure Simon has the answers to take us to the SGA
>> or get one created.
>>
>> Not trying to dump work on you Andy, just trying to track down the
>> answers and not all questions are addressed to you :-)
>>
>>
>> On Aug 16, 2016, at 3:39 PM, Andrew Purtell <ap...@apache.org> wrote:
>>
>> As I explained on the INFRA JIRA Pat I'm quite clear what was granted and
>> if it's not already in an Apache repo it was not granted by that SGA.
>>
>> Sure, Simon would be a reasonable place to start for a new SGA discussion.
>> I have no idea what he's up to, I'm not his keeper.
>>
>> On Tue, Aug 16, 2016 at 3:36 PM, Pat Ferrel <pa...@occamsmachete.com>
>> wrote:
>>
>> > AFAIK Salesforce owns the code and Simon must have filled out the
>> original
>> > PIO grant, which may cover all the templates already. He also started
>> this
>> > discussion so I think we start with Simon unless someone knows better.
>> Is
>> > he on vacation?
>> >
>> >
>> > On Aug 16, 2016, at 3:30 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>> >
>> > I see that Pat filed INFRA-12441 (
>> > https://issues.apache.org/jira/browse/INFRA-12441) which I read asks to
>> > import code from GitHub repositories under the old PIO organization not
>> yet
>> > granted to the ASF.
>> >
>> > This presents you with a great opportunity to learn how software grants
>> > work. (smile) Even when you are out of incubation this process will
>> still
>> > be necessary for imports of third party code not covered by an existing
>> > SGA, CCLA, or ICLA. The procedure is pretty simple, assuming a single
>> > rights holder (which is the case I believe for the scope of this
>> request).
>> > I encourage the PPMC to work out who will contact the rights holder to
>> > execute a SGA (https://www.apache.org/licenses/software-grant.txt) that
>> > covers all of the code you would like to import. When the granted code
>> is
>> > coming from a GitHub repository, Exhibit A should list all repository
>> URLs
>> > and exact SHAs desired for import covered by the grant.
>> >
>> > I'm happy to assist but the PPMC should take the lead. Good luck!
>> >
>> >
>> > On Tue, Aug 16, 2016 at 2:27 PM, Andrew Purtell <ap...@apache.org>
>> > wrote:
>> >
>> >> Go to https://issues.apache.org/jira/ and log in. Find the read
>> 'Create'
>> >> button. There's a drop down menu immediately to the right of it. Open
>> > that
>> >> menu, then click on 'New Git Repository'.
>> >>
>> >> The original request was here: https://issues.apache.
>> >> org/jira/browse/INFRA-12112
>> >> The second request for site was here: https://issues.apache.
>> >> org/jira/browse/INFRA-12180
>> >>
>> >>
>> >> On Tue, Aug 16, 2016 at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com>
>> >> wrote:
>> >>
>> >>> +1
>> >>>
>> >>>
>> >>>> On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org>
>> wrote:
>> >>>>
>> >>>> 1) I’ll volunteer to take a couple templates and put them in their
>> own
>> >>> repos if we can get some created.
>> >>>> Sure. I believe Chan might have some converted repos as well.
>> >>>>
>> >>>> 2) do we have a gallery page yet? we had a good proposal, is it
>> >>> implemented?
>> >>>> It's already been merged in develop. Once we release the old template
>> >>> gallery will become a redirection to the new static page.
>> >>>
>> >>> This is needed only for historical reasons, right? The big blue
>> Template
>> >>> button will go there directly after release, I assume.
>> >>>
>> >>>>
>> >>>> 3) What templates are worth inclusion? Seems like some of the ALS
>> >>> recommender ones are supersets of others do we need them all?
>> >>>> We should start with a core set of templates and one or a couple that
>> >>> focuses on a use case (since they are popular): vanilla,
>> recommendation
>> >>> (both Scala and Java), similar product, classification, e-commerce,
>> and
>> >>> text classification.
>> >>>
>> >>> sounds good, that is 7. @chan have you scrubbed any of these?
>> >>>
>> >>>>
>> >>>> 4) do we need “release” of these except through Apache git and
>> Github?
>> >>> Since they are all built by users I suspect the normal Apache release
>> >>> process can be avoided for them, the full push to maven, binary
>> hosting,
>> >>> etc.
>> >>>> I vote for maintaining the above set of templates to be at least
>> >>> working and passing integration tests for the main release. They do
>> not
>> >>> necessarily go into the final binary distribution, but they should all
>> > be
>> >>> tagged and tested against with every release of PredictionIO.
>> >>>
>> >>> +1
>> >>>
>> >>>>
>> >>>> 5) We need someone to file Infra Jira’s to get repos. If someone can
>> >>> coach me on this I will do it.
>> >>>> My guess is we can just file an infrastructure ticket to spawn some
>> >>> discussion.
>> >>>>
>> >>>
>> >>> Who did the original request for repo? Can someone point me to the
>> Jira,
>> >>> I’ll take it from there
>> >>>
>> >>>>
>> >>>> This might only add a week or so to the release date. If we don’t do
>> it
>> >>> I bet it will be much more time spent in support and fixing later.
>> >>>> Agree. If we all agree let's make this the final major thing to do
>> >>> before 0.10.0 release to avoid feature creep.
>> >>>>
>> >>>
>> >>> +1, with the possible exception of fixing install.sh
>> >>> https://issues.apache.org/jira/browse/PIO-22 One option is to remove
>> it
>> >>> from the release, which I favor, discussion on the jira.
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >> - Andy
>> >>
>> >> Problems worthy of attack prove their worth by hitting back. - Piet
>> Hein
>> >> (via Tom White)
>> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > - Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> > (via Tom White)
>> >
>> >
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>
>>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: 0.10.0 release
Posted by Andrew Purtell <ap...@apache.org>.
Thanks for the clarification. I could have phrased that better too. Not
meant to sound abrasive.
On Tue, Aug 16, 2016 at 3:53 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> I don’t expect you to know where Simon is, I was just seeing if anyone on
> the list knew, some are relatives and friends of his and even work at the
> same location. I’m pretty sure Simon has the answers to take us to the SGA
> or get one created.
>
> Not trying to dump work on you Andy, just trying to track down the answers
> and not all questions are addressed to you :-)
>
>
> On Aug 16, 2016, at 3:39 PM, Andrew Purtell <ap...@apache.org> wrote:
>
> As I explained on the INFRA JIRA Pat I'm quite clear what was granted and
> if it's not already in an Apache repo it was not granted by that SGA.
>
> Sure, Simon would be a reasonable place to start for a new SGA discussion.
> I have no idea what he's up to, I'm not his keeper.
>
> On Tue, Aug 16, 2016 at 3:36 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> > AFAIK Salesforce owns the code and Simon must have filled out the
> original
> > PIO grant, which may cover all the templates already. He also started
> this
> > discussion so I think we start with Simon unless someone knows better. Is
> > he on vacation?
> >
> >
> > On Aug 16, 2016, at 3:30 PM, Andrew Purtell <ap...@apache.org> wrote:
> >
> > I see that Pat filed INFRA-12441 (
> > https://issues.apache.org/jira/browse/INFRA-12441) which I read asks to
> > import code from GitHub repositories under the old PIO organization not
> yet
> > granted to the ASF.
> >
> > This presents you with a great opportunity to learn how software grants
> > work. (smile) Even when you are out of incubation this process will still
> > be necessary for imports of third party code not covered by an existing
> > SGA, CCLA, or ICLA. The procedure is pretty simple, assuming a single
> > rights holder (which is the case I believe for the scope of this
> request).
> > I encourage the PPMC to work out who will contact the rights holder to
> > execute a SGA (https://www.apache.org/licenses/software-grant.txt) that
> > covers all of the code you would like to import. When the granted code is
> > coming from a GitHub repository, Exhibit A should list all repository
> URLs
> > and exact SHAs desired for import covered by the grant.
> >
> > I'm happy to assist but the PPMC should take the lead. Good luck!
> >
> >
> > On Tue, Aug 16, 2016 at 2:27 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> >> Go to https://issues.apache.org/jira/ and log in. Find the read
> 'Create'
> >> button. There's a drop down menu immediately to the right of it. Open
> > that
> >> menu, then click on 'New Git Repository'.
> >>
> >> The original request was here: https://issues.apache.
> >> org/jira/browse/INFRA-12112
> >> The second request for site was here: https://issues.apache.
> >> org/jira/browse/INFRA-12180
> >>
> >>
> >> On Tue, Aug 16, 2016 at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com>
> >> wrote:
> >>
> >>> +1
> >>>
> >>>
> >>>> On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org> wrote:
> >>>>
> >>>> 1) I’ll volunteer to take a couple templates and put them in their own
> >>> repos if we can get some created.
> >>>> Sure. I believe Chan might have some converted repos as well.
> >>>>
> >>>> 2) do we have a gallery page yet? we had a good proposal, is it
> >>> implemented?
> >>>> It's already been merged in develop. Once we release the old template
> >>> gallery will become a redirection to the new static page.
> >>>
> >>> This is needed only for historical reasons, right? The big blue
> Template
> >>> button will go there directly after release, I assume.
> >>>
> >>>>
> >>>> 3) What templates are worth inclusion? Seems like some of the ALS
> >>> recommender ones are supersets of others do we need them all?
> >>>> We should start with a core set of templates and one or a couple that
> >>> focuses on a use case (since they are popular): vanilla, recommendation
> >>> (both Scala and Java), similar product, classification, e-commerce, and
> >>> text classification.
> >>>
> >>> sounds good, that is 7. @chan have you scrubbed any of these?
> >>>
> >>>>
> >>>> 4) do we need “release” of these except through Apache git and Github?
> >>> Since they are all built by users I suspect the normal Apache release
> >>> process can be avoided for them, the full push to maven, binary
> hosting,
> >>> etc.
> >>>> I vote for maintaining the above set of templates to be at least
> >>> working and passing integration tests for the main release. They do not
> >>> necessarily go into the final binary distribution, but they should all
> > be
> >>> tagged and tested against with every release of PredictionIO.
> >>>
> >>> +1
> >>>
> >>>>
> >>>> 5) We need someone to file Infra Jira’s to get repos. If someone can
> >>> coach me on this I will do it.
> >>>> My guess is we can just file an infrastructure ticket to spawn some
> >>> discussion.
> >>>>
> >>>
> >>> Who did the original request for repo? Can someone point me to the
> Jira,
> >>> I’ll take it from there
> >>>
> >>>>
> >>>> This might only add a week or so to the release date. If we don’t do
> it
> >>> I bet it will be much more time spent in support and fixing later.
> >>>> Agree. If we all agree let's make this the final major thing to do
> >>> before 0.10.0 release to avoid feature creep.
> >>>>
> >>>
> >>> +1, with the possible exception of fixing install.sh
> >>> https://issues.apache.org/jira/browse/PIO-22 One option is to remove
> it
> >>> from the release, which I favor, discussion on the jira.
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >> - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: 0.10.0 release
Posted by Pat Ferrel <pa...@occamsmachete.com>.
I don’t expect you to know where Simon is, I was just seeing if anyone on the list knew, some are relatives and friends of his and even work at the same location. I’m pretty sure Simon has the answers to take us to the SGA or get one created.
Not trying to dump work on you Andy, just trying to track down the answers and not all questions are addressed to you :-)
On Aug 16, 2016, at 3:39 PM, Andrew Purtell <ap...@apache.org> wrote:
As I explained on the INFRA JIRA Pat I'm quite clear what was granted and
if it's not already in an Apache repo it was not granted by that SGA.
Sure, Simon would be a reasonable place to start for a new SGA discussion.
I have no idea what he's up to, I'm not his keeper.
On Tue, Aug 16, 2016 at 3:36 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> AFAIK Salesforce owns the code and Simon must have filled out the original
> PIO grant, which may cover all the templates already. He also started this
> discussion so I think we start with Simon unless someone knows better. Is
> he on vacation?
>
>
> On Aug 16, 2016, at 3:30 PM, Andrew Purtell <ap...@apache.org> wrote:
>
> I see that Pat filed INFRA-12441 (
> https://issues.apache.org/jira/browse/INFRA-12441) which I read asks to
> import code from GitHub repositories under the old PIO organization not yet
> granted to the ASF.
>
> This presents you with a great opportunity to learn how software grants
> work. (smile) Even when you are out of incubation this process will still
> be necessary for imports of third party code not covered by an existing
> SGA, CCLA, or ICLA. The procedure is pretty simple, assuming a single
> rights holder (which is the case I believe for the scope of this request).
> I encourage the PPMC to work out who will contact the rights holder to
> execute a SGA (https://www.apache.org/licenses/software-grant.txt) that
> covers all of the code you would like to import. When the granted code is
> coming from a GitHub repository, Exhibit A should list all repository URLs
> and exact SHAs desired for import covered by the grant.
>
> I'm happy to assist but the PPMC should take the lead. Good luck!
>
>
> On Tue, Aug 16, 2016 at 2:27 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
>> Go to https://issues.apache.org/jira/ and log in. Find the read 'Create'
>> button. There's a drop down menu immediately to the right of it. Open
> that
>> menu, then click on 'New Git Repository'.
>>
>> The original request was here: https://issues.apache.
>> org/jira/browse/INFRA-12112
>> The second request for site was here: https://issues.apache.
>> org/jira/browse/INFRA-12180
>>
>>
>> On Tue, Aug 16, 2016 at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com>
>> wrote:
>>
>>> +1
>>>
>>>
>>>> On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org> wrote:
>>>>
>>>> 1) I’ll volunteer to take a couple templates and put them in their own
>>> repos if we can get some created.
>>>> Sure. I believe Chan might have some converted repos as well.
>>>>
>>>> 2) do we have a gallery page yet? we had a good proposal, is it
>>> implemented?
>>>> It's already been merged in develop. Once we release the old template
>>> gallery will become a redirection to the new static page.
>>>
>>> This is needed only for historical reasons, right? The big blue Template
>>> button will go there directly after release, I assume.
>>>
>>>>
>>>> 3) What templates are worth inclusion? Seems like some of the ALS
>>> recommender ones are supersets of others do we need them all?
>>>> We should start with a core set of templates and one or a couple that
>>> focuses on a use case (since they are popular): vanilla, recommendation
>>> (both Scala and Java), similar product, classification, e-commerce, and
>>> text classification.
>>>
>>> sounds good, that is 7. @chan have you scrubbed any of these?
>>>
>>>>
>>>> 4) do we need “release” of these except through Apache git and Github?
>>> Since they are all built by users I suspect the normal Apache release
>>> process can be avoided for them, the full push to maven, binary hosting,
>>> etc.
>>>> I vote for maintaining the above set of templates to be at least
>>> working and passing integration tests for the main release. They do not
>>> necessarily go into the final binary distribution, but they should all
> be
>>> tagged and tested against with every release of PredictionIO.
>>>
>>> +1
>>>
>>>>
>>>> 5) We need someone to file Infra Jira’s to get repos. If someone can
>>> coach me on this I will do it.
>>>> My guess is we can just file an infrastructure ticket to spawn some
>>> discussion.
>>>>
>>>
>>> Who did the original request for repo? Can someone point me to the Jira,
>>> I’ll take it from there
>>>
>>>>
>>>> This might only add a week or so to the release date. If we don’t do it
>>> I bet it will be much more time spent in support and fixing later.
>>>> Agree. If we all agree let's make this the final major thing to do
>>> before 0.10.0 release to avoid feature creep.
>>>>
>>>
>>> +1, with the possible exception of fixing install.sh
>>> https://issues.apache.org/jira/browse/PIO-22 One option is to remove it
>>> from the release, which I favor, discussion on the jira.
>>>
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: 0.10.0 release
Posted by Andrew Purtell <ap...@apache.org>.
As I explained on the INFRA JIRA Pat I'm quite clear what was granted and
if it's not already in an Apache repo it was not granted by that SGA.
Sure, Simon would be a reasonable place to start for a new SGA discussion.
I have no idea what he's up to, I'm not his keeper.
On Tue, Aug 16, 2016 at 3:36 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> AFAIK Salesforce owns the code and Simon must have filled out the original
> PIO grant, which may cover all the templates already. He also started this
> discussion so I think we start with Simon unless someone knows better. Is
> he on vacation?
>
>
> On Aug 16, 2016, at 3:30 PM, Andrew Purtell <ap...@apache.org> wrote:
>
> I see that Pat filed INFRA-12441 (
> https://issues.apache.org/jira/browse/INFRA-12441) which I read asks to
> import code from GitHub repositories under the old PIO organization not yet
> granted to the ASF.
>
> This presents you with a great opportunity to learn how software grants
> work. (smile) Even when you are out of incubation this process will still
> be necessary for imports of third party code not covered by an existing
> SGA, CCLA, or ICLA. The procedure is pretty simple, assuming a single
> rights holder (which is the case I believe for the scope of this request).
> I encourage the PPMC to work out who will contact the rights holder to
> execute a SGA (https://www.apache.org/licenses/software-grant.txt) that
> covers all of the code you would like to import. When the granted code is
> coming from a GitHub repository, Exhibit A should list all repository URLs
> and exact SHAs desired for import covered by the grant.
>
> I'm happy to assist but the PPMC should take the lead. Good luck!
>
>
> On Tue, Aug 16, 2016 at 2:27 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > Go to https://issues.apache.org/jira/ and log in. Find the read 'Create'
> > button. There's a drop down menu immediately to the right of it. Open
> that
> > menu, then click on 'New Git Repository'.
> >
> > The original request was here: https://issues.apache.
> > org/jira/browse/INFRA-12112
> > The second request for site was here: https://issues.apache.
> > org/jira/browse/INFRA-12180
> >
> >
> > On Tue, Aug 16, 2016 at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com>
> > wrote:
> >
> >> +1
> >>
> >>
> >>> On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org> wrote:
> >>>
> >>> 1) I’ll volunteer to take a couple templates and put them in their own
> >> repos if we can get some created.
> >>> Sure. I believe Chan might have some converted repos as well.
> >>>
> >>> 2) do we have a gallery page yet? we had a good proposal, is it
> >> implemented?
> >>> It's already been merged in develop. Once we release the old template
> >> gallery will become a redirection to the new static page.
> >>
> >> This is needed only for historical reasons, right? The big blue Template
> >> button will go there directly after release, I assume.
> >>
> >>>
> >>> 3) What templates are worth inclusion? Seems like some of the ALS
> >> recommender ones are supersets of others do we need them all?
> >>> We should start with a core set of templates and one or a couple that
> >> focuses on a use case (since they are popular): vanilla, recommendation
> >> (both Scala and Java), similar product, classification, e-commerce, and
> >> text classification.
> >>
> >> sounds good, that is 7. @chan have you scrubbed any of these?
> >>
> >>>
> >>> 4) do we need “release” of these except through Apache git and Github?
> >> Since they are all built by users I suspect the normal Apache release
> >> process can be avoided for them, the full push to maven, binary hosting,
> >> etc.
> >>> I vote for maintaining the above set of templates to be at least
> >> working and passing integration tests for the main release. They do not
> >> necessarily go into the final binary distribution, but they should all
> be
> >> tagged and tested against with every release of PredictionIO.
> >>
> >> +1
> >>
> >>>
> >>> 5) We need someone to file Infra Jira’s to get repos. If someone can
> >> coach me on this I will do it.
> >>> My guess is we can just file an infrastructure ticket to spawn some
> >> discussion.
> >>>
> >>
> >> Who did the original request for repo? Can someone point me to the Jira,
> >> I’ll take it from there
> >>
> >>>
> >>> This might only add a week or so to the release date. If we don’t do it
> >> I bet it will be much more time spent in support and fixing later.
> >>> Agree. If we all agree let's make this the final major thing to do
> >> before 0.10.0 release to avoid feature creep.
> >>>
> >>
> >> +1, with the possible exception of fixing install.sh
> >> https://issues.apache.org/jira/browse/PIO-22 One option is to remove it
> >> from the release, which I favor, discussion on the jira.
> >>
> >>
> >>
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: 0.10.0 release
Posted by Pat Ferrel <pa...@occamsmachete.com>.
AFAIK Salesforce owns the code and Simon must have filled out the original PIO grant, which may cover all the templates already. He also started this discussion so I think we start with Simon unless someone knows better. Is he on vacation?
On Aug 16, 2016, at 3:30 PM, Andrew Purtell <ap...@apache.org> wrote:
I see that Pat filed INFRA-12441 (
https://issues.apache.org/jira/browse/INFRA-12441) which I read asks to
import code from GitHub repositories under the old PIO organization not yet
granted to the ASF.
This presents you with a great opportunity to learn how software grants
work. (smile) Even when you are out of incubation this process will still
be necessary for imports of third party code not covered by an existing
SGA, CCLA, or ICLA. The procedure is pretty simple, assuming a single
rights holder (which is the case I believe for the scope of this request).
I encourage the PPMC to work out who will contact the rights holder to
execute a SGA (https://www.apache.org/licenses/software-grant.txt) that
covers all of the code you would like to import. When the granted code is
coming from a GitHub repository, Exhibit A should list all repository URLs
and exact SHAs desired for import covered by the grant.
I'm happy to assist but the PPMC should take the lead. Good luck!
On Tue, Aug 16, 2016 at 2:27 PM, Andrew Purtell <ap...@apache.org> wrote:
> Go to https://issues.apache.org/jira/ and log in. Find the read 'Create'
> button. There's a drop down menu immediately to the right of it. Open that
> menu, then click on 'New Git Repository'.
>
> The original request was here: https://issues.apache.
> org/jira/browse/INFRA-12112
> The second request for site was here: https://issues.apache.
> org/jira/browse/INFRA-12180
>
>
> On Tue, Aug 16, 2016 at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com>
> wrote:
>
>> +1
>>
>>
>>> On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org> wrote:
>>>
>>> 1) I’ll volunteer to take a couple templates and put them in their own
>> repos if we can get some created.
>>> Sure. I believe Chan might have some converted repos as well.
>>>
>>> 2) do we have a gallery page yet? we had a good proposal, is it
>> implemented?
>>> It's already been merged in develop. Once we release the old template
>> gallery will become a redirection to the new static page.
>>
>> This is needed only for historical reasons, right? The big blue Template
>> button will go there directly after release, I assume.
>>
>>>
>>> 3) What templates are worth inclusion? Seems like some of the ALS
>> recommender ones are supersets of others do we need them all?
>>> We should start with a core set of templates and one or a couple that
>> focuses on a use case (since they are popular): vanilla, recommendation
>> (both Scala and Java), similar product, classification, e-commerce, and
>> text classification.
>>
>> sounds good, that is 7. @chan have you scrubbed any of these?
>>
>>>
>>> 4) do we need “release” of these except through Apache git and Github?
>> Since they are all built by users I suspect the normal Apache release
>> process can be avoided for them, the full push to maven, binary hosting,
>> etc.
>>> I vote for maintaining the above set of templates to be at least
>> working and passing integration tests for the main release. They do not
>> necessarily go into the final binary distribution, but they should all be
>> tagged and tested against with every release of PredictionIO.
>>
>> +1
>>
>>>
>>> 5) We need someone to file Infra Jira’s to get repos. If someone can
>> coach me on this I will do it.
>>> My guess is we can just file an infrastructure ticket to spawn some
>> discussion.
>>>
>>
>> Who did the original request for repo? Can someone point me to the Jira,
>> I’ll take it from there
>>
>>>
>>> This might only add a week or so to the release date. If we don’t do it
>> I bet it will be much more time spent in support and fixing later.
>>> Agree. If we all agree let's make this the final major thing to do
>> before 0.10.0 release to avoid feature creep.
>>>
>>
>> +1, with the possible exception of fixing install.sh
>> https://issues.apache.org/jira/browse/PIO-22 One option is to remove it
>> from the release, which I favor, discussion on the jira.
>>
>>
>>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: 0.10.0 release
Posted by Andrew Purtell <ap...@apache.org>.
I see that Pat filed INFRA-12441 (
https://issues.apache.org/jira/browse/INFRA-12441) which I read asks to
import code from GitHub repositories under the old PIO organization not yet
granted to the ASF.
This presents you with a great opportunity to learn how software grants
work. (smile) Even when you are out of incubation this process will still
be necessary for imports of third party code not covered by an existing
SGA, CCLA, or ICLA. The procedure is pretty simple, assuming a single
rights holder (which is the case I believe for the scope of this request).
I encourage the PPMC to work out who will contact the rights holder to
execute a SGA (https://www.apache.org/licenses/software-grant.txt) that
covers all of the code you would like to import. When the granted code is
coming from a GitHub repository, Exhibit A should list all repository URLs
and exact SHAs desired for import covered by the grant.
I'm happy to assist but the PPMC should take the lead. Good luck!
On Tue, Aug 16, 2016 at 2:27 PM, Andrew Purtell <ap...@apache.org> wrote:
> Go to https://issues.apache.org/jira/ and log in. Find the read 'Create'
> button. There's a drop down menu immediately to the right of it. Open that
> menu, then click on 'New Git Repository'.
>
> The original request was here: https://issues.apache.
> org/jira/browse/INFRA-12112
> The second request for site was here: https://issues.apache.
> org/jira/browse/INFRA-12180
>
>
> On Tue, Aug 16, 2016 at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com>
> wrote:
>
>> +1
>>
>>
>> > On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org> wrote:
>> >
>> > 1) I’ll volunteer to take a couple templates and put them in their own
>> repos if we can get some created.
>> > Sure. I believe Chan might have some converted repos as well.
>> >
>> > 2) do we have a gallery page yet? we had a good proposal, is it
>> implemented?
>> > It's already been merged in develop. Once we release the old template
>> gallery will become a redirection to the new static page.
>>
>> This is needed only for historical reasons, right? The big blue Template
>> button will go there directly after release, I assume.
>>
>> >
>> > 3) What templates are worth inclusion? Seems like some of the ALS
>> recommender ones are supersets of others do we need them all?
>> > We should start with a core set of templates and one or a couple that
>> focuses on a use case (since they are popular): vanilla, recommendation
>> (both Scala and Java), similar product, classification, e-commerce, and
>> text classification.
>>
>> sounds good, that is 7. @chan have you scrubbed any of these?
>>
>> >
>> > 4) do we need “release” of these except through Apache git and Github?
>> Since they are all built by users I suspect the normal Apache release
>> process can be avoided for them, the full push to maven, binary hosting,
>> etc.
>> > I vote for maintaining the above set of templates to be at least
>> working and passing integration tests for the main release. They do not
>> necessarily go into the final binary distribution, but they should all be
>> tagged and tested against with every release of PredictionIO.
>>
>> +1
>>
>> >
>> > 5) We need someone to file Infra Jira’s to get repos. If someone can
>> coach me on this I will do it.
>> > My guess is we can just file an infrastructure ticket to spawn some
>> discussion.
>> >
>>
>> Who did the original request for repo? Can someone point me to the Jira,
>> I’ll take it from there
>>
>> >
>> > This might only add a week or so to the release date. If we don’t do it
>> I bet it will be much more time spent in support and fixing later.
>> > Agree. If we all agree let's make this the final major thing to do
>> before 0.10.0 release to avoid feature creep.
>> >
>>
>> +1, with the possible exception of fixing install.sh
>> https://issues.apache.org/jira/browse/PIO-22 One option is to remove it
>> from the release, which I favor, discussion on the jira.
>>
>>
>>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: 0.10.0 release
Posted by Andrew Purtell <ap...@apache.org>.
Go to https://issues.apache.org/jira/ and log in. Find the read 'Create'
button. There's a drop down menu immediately to the right of it. Open that
menu, then click on 'New Git Repository'.
The original request was here:
https://issues.apache.org/jira/browse/INFRA-12112
The second request for site was here:
https://issues.apache.org/jira/browse/INFRA-12180
On Tue, Aug 16, 2016 at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> +1
>
>
> > On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org> wrote:
> >
> > 1) I’ll volunteer to take a couple templates and put them in their own
> repos if we can get some created.
> > Sure. I believe Chan might have some converted repos as well.
> >
> > 2) do we have a gallery page yet? we had a good proposal, is it
> implemented?
> > It's already been merged in develop. Once we release the old template
> gallery will become a redirection to the new static page.
>
> This is needed only for historical reasons, right? The big blue Template
> button will go there directly after release, I assume.
>
> >
> > 3) What templates are worth inclusion? Seems like some of the ALS
> recommender ones are supersets of others do we need them all?
> > We should start with a core set of templates and one or a couple that
> focuses on a use case (since they are popular): vanilla, recommendation
> (both Scala and Java), similar product, classification, e-commerce, and
> text classification.
>
> sounds good, that is 7. @chan have you scrubbed any of these?
>
> >
> > 4) do we need “release” of these except through Apache git and Github?
> Since they are all built by users I suspect the normal Apache release
> process can be avoided for them, the full push to maven, binary hosting,
> etc.
> > I vote for maintaining the above set of templates to be at least working
> and passing integration tests for the main release. They do not necessarily
> go into the final binary distribution, but they should all be tagged and
> tested against with every release of PredictionIO.
>
> +1
>
> >
> > 5) We need someone to file Infra Jira’s to get repos. If someone can
> coach me on this I will do it.
> > My guess is we can just file an infrastructure ticket to spawn some
> discussion.
> >
>
> Who did the original request for repo? Can someone point me to the Jira,
> I’ll take it from there
>
> >
> > This might only add a week or so to the release date. If we don’t do it
> I bet it will be much more time spent in support and fixing later.
> > Agree. If we all agree let's make this the final major thing to do
> before 0.10.0 release to avoid feature creep.
> >
>
> +1, with the possible exception of fixing install.sh
> https://issues.apache.org/jira/browse/PIO-22 One option is to remove it
> from the release, which I favor, discussion on the jira.
>
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: 0.10.0 release
Posted by Donald Szeto <do...@apache.org>.
I agree with removing all reference to pio-build sbt plugin from engine
templates. We will not need the "version tracking" and the pioVersion
settings in engine template's sbt once we start tagging our officially
tested templates.
On Tue, Aug 16, 2016 at 2:17 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> Awesome, all we need to do is push to the right repo? Can you share the
> links?
>
> Donald mentioned that he though we could do without the pio sbt plugin, no?
>
>
> On Aug 16, 2016, at 2:05 PM, Chan Lee <ch...@gmail.com> wrote:
>
> I've changed the namespace for all repos marked "official" except for
> Universal Recommender and is running integration tests on them.
>
> Also, I believe the sbt plugin for pio-build needs to be updated.
>
> On Tue, Aug 16, 2016 at 12:50 PM, Pat Ferrel <pat@occamsmachete.com
> <ma...@occamsmachete.com>> wrote:
> Let me know if anything is missing: https://issues.apache.org/
> jira/browse/PIO-24 <https://issues.apache.org/jira/browse/PIO-24>
>
>
> On Aug 16, 2016, at 12:26 PM, Pat Ferrel <pat@occamsmachete.com <mailto:
> pat@occamsmachete.com>> wrote:
>
> +1
>
>
> > On Aug 16, 2016, at 11:35 AM, Donald Szeto <donald@apache.org <mailto:
> donald@apache.org>> wrote:
> >
> > 1) I’ll volunteer to take a couple templates and put them in their own
> repos if we can get some created.
> > Sure. I believe Chan might have some converted repos as well.
> >
> > 2) do we have a gallery page yet? we had a good proposal, is it
> implemented?
> > It's already been merged in develop. Once we release the old template
> gallery will become a redirection to the new static page.
>
> This is needed only for historical reasons, right? The big blue Template
> button will go there directly after release, I assume.
>
> >
> > 3) What templates are worth inclusion? Seems like some of the ALS
> recommender ones are supersets of others do we need them all?
> > We should start with a core set of templates and one or a couple that
> focuses on a use case (since they are popular): vanilla, recommendation
> (both Scala and Java), similar product, classification, e-commerce, and
> text classification.
>
> sounds good, that is 7. @chan have you scrubbed any of these?
>
> >
> > 4) do we need “release” of these except through Apache git and Github?
> Since they are all built by users I suspect the normal Apache release
> process can be avoided for them, the full push to maven, binary hosting,
> etc.
> > I vote for maintaining the above set of templates to be at least working
> and passing integration tests for the main release. They do not necessarily
> go into the final binary distribution, but they should all be tagged and
> tested against with every release of PredictionIO.
>
> +1
>
> >
> > 5) We need someone to file Infra Jira’s to get repos. If someone can
> coach me on this I will do it.
> > My guess is we can just file an infrastructure ticket to spawn some
> discussion.
> >
>
> Who did the original request for repo? Can someone point me to the Jira,
> I’ll take it from there
>
> >
> > This might only add a week or so to the release date. If we don’t do it
> I bet it will be much more time spent in support and fixing later.
> > Agree. If we all agree let's make this the final major thing to do
> before 0.10.0 release to avoid feature creep.
> >
>
> +1, with the possible exception of fixing install.sh
> https://issues.apache.org/jira/browse/PIO-22 <https://issues.apache.org/
> jira/browse/PIO-22> One option is to remove it from the release, which I
> favor, discussion on the jira.
>
>
>
>
>
>
Re: 0.10.0 release
Posted by Pat Ferrel <pa...@occamsmachete.com>.
Awesome, all we need to do is push to the right repo? Can you share the links?
Donald mentioned that he though we could do without the pio sbt plugin, no?
On Aug 16, 2016, at 2:05 PM, Chan Lee <ch...@gmail.com> wrote:
I've changed the namespace for all repos marked "official" except for Universal Recommender and is running integration tests on them.
Also, I believe the sbt plugin for pio-build needs to be updated.
On Tue, Aug 16, 2016 at 12:50 PM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
Let me know if anything is missing: https://issues.apache.org/jira/browse/PIO-24 <https://issues.apache.org/jira/browse/PIO-24>
On Aug 16, 2016, at 12:26 PM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
+1
> On Aug 16, 2016, at 11:35 AM, Donald Szeto <donald@apache.org <ma...@apache.org>> wrote:
>
> 1) I’ll volunteer to take a couple templates and put them in their own repos if we can get some created.
> Sure. I believe Chan might have some converted repos as well.
>
> 2) do we have a gallery page yet? we had a good proposal, is it implemented?
> It's already been merged in develop. Once we release the old template gallery will become a redirection to the new static page.
This is needed only for historical reasons, right? The big blue Template button will go there directly after release, I assume.
>
> 3) What templates are worth inclusion? Seems like some of the ALS recommender ones are supersets of others do we need them all?
> We should start with a core set of templates and one or a couple that focuses on a use case (since they are popular): vanilla, recommendation (both Scala and Java), similar product, classification, e-commerce, and text classification.
sounds good, that is 7. @chan have you scrubbed any of these?
>
> 4) do we need “release” of these except through Apache git and Github? Since they are all built by users I suspect the normal Apache release process can be avoided for them, the full push to maven, binary hosting, etc.
> I vote for maintaining the above set of templates to be at least working and passing integration tests for the main release. They do not necessarily go into the final binary distribution, but they should all be tagged and tested against with every release of PredictionIO.
+1
>
> 5) We need someone to file Infra Jira’s to get repos. If someone can coach me on this I will do it.
> My guess is we can just file an infrastructure ticket to spawn some discussion.
>
Who did the original request for repo? Can someone point me to the Jira, I’ll take it from there
>
> This might only add a week or so to the release date. If we don’t do it I bet it will be much more time spent in support and fixing later.
> Agree. If we all agree let's make this the final major thing to do before 0.10.0 release to avoid feature creep.
>
+1, with the possible exception of fixing install.sh https://issues.apache.org/jira/browse/PIO-22 <https://issues.apache.org/jira/browse/PIO-22> One option is to remove it from the release, which I favor, discussion on the jira.
Re: 0.10.0 release
Posted by Chan Lee <ch...@gmail.com>.
I've changed the namespace for all repos marked "official" except for
Universal Recommender and is running integration tests on them.
Also, I believe the sbt plugin for pio-build needs to be updated.
On Tue, Aug 16, 2016 at 12:50 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> Let me know if anything is missing: https://issues.
> apache.org/jira/browse/PIO-24
>
>
> On Aug 16, 2016, at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> +1
>
>
> On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org> wrote:
>
> 1) I’ll volunteer to take a couple templates and put them in their own
>> repos if we can get some created.
>>
> Sure. I believe Chan might have some converted repos as well.
>
>
>
>> 2) do we have a gallery page yet? we had a good proposal, is it
>> implemented?
>>
> It's already been merged in develop. Once we release the old template
> gallery will become a redirection to the new static page.
>
>
> This is needed only for historical reasons, right? The big blue Template
> button will go there directly after release, I assume.
>
>
>
>> 3) What templates are worth inclusion? Seems like some of the ALS
>> recommender ones are supersets of others do we need them all?
>>
> We should start with a core set of templates and one or a couple that
> focuses on a use case (since they are popular): vanilla, recommendation
> (both Scala and Java), similar product, classification, e-commerce, and
> text classification.
>
>
> sounds good, that is 7. @chan have you scrubbed any of these?
>
>
>
>> 4) do we need “release” of these except through Apache git and Github?
>> Since they are all built by users I suspect the normal Apache release
>> process can be avoided for them, the full push to maven, binary hosting,
>> etc.
>>
> I vote for maintaining the above set of templates to be at least working
> and passing integration tests for the main release. They do not necessarily
> go into the final binary distribution, but they should all be tagged and
> tested against with every release of PredictionIO.
>
>
> +1
>
>
>
>> 5) We need someone to file Infra Jira’s to get repos. If someone can
>> coach me on this I will do it.
>>
> My guess is we can just file an infrastructure ticket to spawn some
> discussion.
>
>
>
> Who did the original request for repo? Can someone point me to the Jira,
> I’ll take it from there
>
>
>> This might only add a week or so to the release date. If we don’t do it I
>> bet it will be much more time spent in support and fixing later.
>>
> Agree. If we all agree let's make this the final major thing to do before
> 0.10.0 release to avoid feature creep.
>
>
> +1, with the possible exception of fixing install.sh https://issues.
> apache.org/jira/browse/PIO-22 One option is to remove it from the
> release, which I favor, discussion on the jira.
>
>
>
>
Re: 0.10.0 release
Posted by Pat Ferrel <pa...@occamsmachete.com>.
Let me know if anything is missing: https://issues.apache.org/jira/browse/PIO-24
On Aug 16, 2016, at 12:26 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
+1
> On Aug 16, 2016, at 11:35 AM, Donald Szeto <donald@apache.org <ma...@apache.org>> wrote:
>
> 1) I’ll volunteer to take a couple templates and put them in their own repos if we can get some created.
> Sure. I believe Chan might have some converted repos as well.
>
> 2) do we have a gallery page yet? we had a good proposal, is it implemented?
> It's already been merged in develop. Once we release the old template gallery will become a redirection to the new static page.
This is needed only for historical reasons, right? The big blue Template button will go there directly after release, I assume.
>
> 3) What templates are worth inclusion? Seems like some of the ALS recommender ones are supersets of others do we need them all?
> We should start with a core set of templates and one or a couple that focuses on a use case (since they are popular): vanilla, recommendation (both Scala and Java), similar product, classification, e-commerce, and text classification.
sounds good, that is 7. @chan have you scrubbed any of these?
>
> 4) do we need “release” of these except through Apache git and Github? Since they are all built by users I suspect the normal Apache release process can be avoided for them, the full push to maven, binary hosting, etc.
> I vote for maintaining the above set of templates to be at least working and passing integration tests for the main release. They do not necessarily go into the final binary distribution, but they should all be tagged and tested against with every release of PredictionIO.
+1
>
> 5) We need someone to file Infra Jira’s to get repos. If someone can coach me on this I will do it.
> My guess is we can just file an infrastructure ticket to spawn some discussion.
>
Who did the original request for repo? Can someone point me to the Jira, I’ll take it from there
>
> This might only add a week or so to the release date. If we don’t do it I bet it will be much more time spent in support and fixing later.
> Agree. If we all agree let's make this the final major thing to do before 0.10.0 release to avoid feature creep.
>
+1, with the possible exception of fixing install.sh https://issues.apache.org/jira/browse/PIO-22 <https://issues.apache.org/jira/browse/PIO-22> One option is to remove it from the release, which I favor, discussion on the jira.
Re: 0.10.0 release
Posted by Pat Ferrel <pa...@occamsmachete.com>.
+1
> On Aug 16, 2016, at 11:35 AM, Donald Szeto <do...@apache.org> wrote:
>
> 1) I’ll volunteer to take a couple templates and put them in their own repos if we can get some created.
> Sure. I believe Chan might have some converted repos as well.
>
> 2) do we have a gallery page yet? we had a good proposal, is it implemented?
> It's already been merged in develop. Once we release the old template gallery will become a redirection to the new static page.
This is needed only for historical reasons, right? The big blue Template button will go there directly after release, I assume.
>
> 3) What templates are worth inclusion? Seems like some of the ALS recommender ones are supersets of others do we need them all?
> We should start with a core set of templates and one or a couple that focuses on a use case (since they are popular): vanilla, recommendation (both Scala and Java), similar product, classification, e-commerce, and text classification.
sounds good, that is 7. @chan have you scrubbed any of these?
>
> 4) do we need “release” of these except through Apache git and Github? Since they are all built by users I suspect the normal Apache release process can be avoided for them, the full push to maven, binary hosting, etc.
> I vote for maintaining the above set of templates to be at least working and passing integration tests for the main release. They do not necessarily go into the final binary distribution, but they should all be tagged and tested against with every release of PredictionIO.
+1
>
> 5) We need someone to file Infra Jira’s to get repos. If someone can coach me on this I will do it.
> My guess is we can just file an infrastructure ticket to spawn some discussion.
>
Who did the original request for repo? Can someone point me to the Jira, I’ll take it from there
>
> This might only add a week or so to the release date. If we don’t do it I bet it will be much more time spent in support and fixing later.
> Agree. If we all agree let's make this the final major thing to do before 0.10.0 release to avoid feature creep.
>
+1, with the possible exception of fixing install.sh https://issues.apache.org/jira/browse/PIO-22 One option is to remove it from the release, which I favor, discussion on the jira.
Re: 0.10.0 release
Posted by Donald Szeto <do...@apache.org>.
>
> 1) I’ll volunteer to take a couple templates and put them in their own
> repos if we can get some created.
>
Sure. I believe Chan might have some converted repos as well.
> 2) do we have a gallery page yet? we had a good proposal, is it
> implemented?
>
It's already been merged in develop. Once we release the old template
gallery will become a redirection to the new static page.
> 3) What templates are worth inclusion? Seems like some of the ALS
> recommender ones are supersets of others do we need them all?
>
We should start with a core set of templates and one or a couple that
focuses on a use case (since they are popular): vanilla, recommendation
(both Scala and Java), similar product, classification, e-commerce, and
text classification.
> 4) do we need “release” of these except through Apache git and Github?
> Since they are all built by users I suspect the normal Apache release
> process can be avoided for them, the full push to maven, binary hosting,
> etc.
>
I vote for maintaining the above set of templates to be at least working
and passing integration tests for the main release. They do not necessarily
go into the final binary distribution, but they should all be tagged and
tested against with every release of PredictionIO.
> 5) We need someone to file Infra Jira’s to get repos. If someone can coach
> me on this I will do it.
>
My guess is we can just file an infrastructure ticket to spawn some
discussion.
>
> This might only add a week or so to the release date. If we don’t do it I
> bet it will be much more time spent in support and fixing later.
>
Agree. If we all agree let's make this the final major thing to do before
0.10.0 release to avoid feature creep.
Re: 0.10.0 release
Posted by Pat Ferrel <pa...@occamsmachete.com>.
BTW the infra Jiras to get repos created is probably critical path so can someone coach me on what to ask for?
On Aug 16, 2016, at 11:16 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
I’ve been talking abut this issue since before we were in the incubator, probably because I maintain one of the most used templates. My vote is to get it right, then release otherwise we create a lot of headaches and ramifications that may never get solved. So in the do-ocracy I’ll volunteer for some of the work below if we decide to go with separate repos.
1) I’ll volunteer to take a couple templates and put them in their own repos if we can get some created.
2) do we have a gallery page yet? we had a good proposal, is it implemented?
3) What templates are worth inclusion? Seems like some of the ALS recommender ones are supersets of others do we need them all?
4) do we need “release” of these except through Apache git and Github? Since they are all built by users I suspect the normal Apache release process can be avoided for them, the full push to maven, binary hosting, etc.
5) We need someone to file Infra Jira’s to get repos. If someone can coach me on this I will do it.
This might only add a week or so to the release date. If we don’t do it I bet it will be much more time spent in support and fixing later.
Who was converting package names in the templates? If that is done adding them to a repo will be easy
On Aug 15, 2016, at 5:01 PM, Donald Szeto <do...@apache.org> wrote:
I think the problem with templates in examples is that they are already
modified and it will be hard to merge any upstream template changes back to
these examples. We need a method to consistently test and support official
templates. We can probably use separate repositories, but I am not sure if
we have enough time if we are planning to release 0.10.0 this week. We
probably want GitHub integration for all these official template repos as
well.
I do not have a strong opinion in mandating one engine one repo, but I
think otherwise it would be hard for customized engines to merge upstream
official changes.
On Mon, Aug 15, 2016 at 3:05 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> Possible but we have template in examples/ for testing and that’s ok imo.
> If we think separate repos is the way to go why not ask?
>
> @mentors how hard would it be to get say 5 new repos tied to github
> mirrors?
>
>
> On Aug 15, 2016, at 1:47 PM, Chan Lee <ch...@gmail.com> wrote:
>
> Regarding 1), I agree with Pat's points for the need to maintain a
> separate repository and release cycle for templates. But for the purpose of
> making the donation process simple and ensuring consistency of templates
> with each new release of PIO, I think having the code reside inside PIO
> repo would be the cleanest solution.
>
> How about creating a separate "apache" branch on each official template
> repo that is consistent with PIO release? So before every PIO release, we
> will merge changes into this "apache" branch, merge them into the main PIO
> repo, and run rigorous tests for each template to ensure that they're
> compatible.
>
> That way people can continue to clone/fork templates as before, it will be
> easy to tag/track template versions compatible with each PIO release, and
> we can ensure that all official engines work with each new PIO release
> which I feel is most important. Also, as Marcin mentioned, we can expand
> tests to keep track of performance changes as well.
>
> Also, I think we should consider merging the current examples/ directory
> with the templates/ directory.
>
> Thanks,
> Chan
>
>
> On Sun, Aug 14, 2016 at 8:30 AM, Pat Ferrel <pat@occamsmachete.com
> <ma...@occamsmachete.com>> wrote:
> Important things unresolved for release:
>
> 1) What to do with Apache templates—my suggestion is separate repos for
> the 3 reasons below.
> 2) We need a Gallery page listing at least a couple converted tested
> templates—couldn’t find this in the site but maybe I missed it. The UR is
> now converted and tested as are the examples.
> 3) AML fork healed, should be pushed this afternoon.
> 4) the rest of the release magic
>
> PIO is rather moot without templates but if they are on a separate release
> schedule like the doc site (which also needs work) we could release without
> 1 & 2. I’d favor that rather than releasing with templates in a templates/
> directory.
>
> Anything else? How are people feeling about release?
>
>
> On Aug 12, 2016, at 10:18 AM, Pat Ferrel <pat@occamsmachete.com <mailto:
> pat@occamsmachete.com>> wrote:
>
> Independent of Apache I’d suggest each template have their own git repo as
> they do now. Is this practically possible in ASF (another example of my
> infrastructure rant but leave that for now). The semantics of this make
> sense. The requirements for all apache or non-apache templates seem to be:
>
> 1) They need to be allowed to have separate release cycles.
> 2) There should be only one way to install templates apache or non-apache
> 3) This method should support tags and branches, and separate PRs
>
> Practically speaking for independent ones (the Universal Recommender will
> remain independent until the issues above are resolved) the templates
> *will* be a separate repo and `git pull` *will* be the method of download.
> To me this implies the Apache ones should use the same pattern.
>
> The separate issue of rules for inclusion in Apache should include a test
> requirement IMO. But inclusion in the Gallery seems a looser attachment to
> the project—just one persons opinion
>
>
> On Aug 11, 2016, at 3:42 PM, Chan Lee <chanlee514@gmail.com <mailto:
> chanlee514@gmail.com>> wrote:
>
> I've begun working on migrating official PredictionIO templates into the
> main apache repository, and there are a few points I'd like to bring to
> attention.
>
> 1) Template code will be merged under templates/ directory, and all commit
> history and authorship will be preserved.
>
> 2) Organization namespace will change in the template code from
> "io.prediction" to "org.apache.predictionio".
>
> 3) In order to download an engine template, users could (1) git clone the
> entire repo and copy the files in templates/<some-template>, or (2) use
> something like svn to download only the necessary subdirectory. I'd like to
> ask what everyone thinks should be the recommended approach. The
> documentation should be updated accordingly (instead of `pio template get`).
>
> 4) I'd like to ask if there are any ActionML/outside templates that should
> be included or updated. For instance, template-scala-parallel-universal-recommendation
> in PredictionIO repo seems outdate compared to one in actionml repo.
>
>
> Thanks,
> Chan
>
>
>
> On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński <zieminm@gmail.com
> <ma...@gmail.com>> wrote:
> I think that this is a very good idea. Obviously it would require
> configuring more concurrent builds to finish in reasonable time, what
> should not be a problem. Besides, it would make the official templates be
> consistent with every next release of PredictionIO and what is very
> important - it would provide many different tests for the repository.
> Having working templates of different types could give us more material to
> test not only the reliability of PredictionIO, but also its performance
> with every change. It would require adding different types of tests and
> tools to gather runtime statistics, but this is something I would like to
> take a look at in the future.
>
> niedz., 7.08.2016 o 10:21 użytkownik Donald Szeto <donald@apache.org
> <ma...@apache.org>>
> napisał:
>
>> We can also make these templates part of the integration test that Chan
> and
>> Marcin just submitted (
>> https://github.com/apache/incubator-predictionio/pull/267 <
> https://github.com/apache/incubator-predictionio/pull/267>). That way we
>> can
>> make commitment to included templates be part of every committer's
> effort.
>> Just my 2c.
>>
>> On Sun, Aug 7, 2016 at 9:47 AM, Pat Ferrel <pat@occamsmachete.com
> <ma...@occamsmachete.com>> wrote:
>>
>>> If this sound ok, I propose the process be:
>>> 1) inclusion in the gallery is a PR to the yaml gallery file. This is
>>> reviewable by all but takes only one committer to approve and merge.
>>> 2) submission for inclusion in the project can be a PR to the new
>>> templates directory as Simon suggests. But this may require a more
> formal
>>> vote, and come with some commitment for support and possibly
>> consideration
>>> of the author for committer status.
>>>
>>> Someone who knows Apache rules better than me may know the type of vote
>> to
>>> have for #2, maybe this is only informal review and single committer
>>> acceptance too as long as the committer is willing to support the
>> template.
>>>
>>> As far as the Salesforce templates marked official, I’d hope that most
>>> would be donated. According to the proposed rules all we need is a PR
> for
>>> each. And again a big thanks to Salesforce!
>>>
>>>
>>> On Aug 4, 2016, at 2:55 PM, Pat Ferrel <pat@occamsmachete.com <mailto:
> pat@occamsmachete.com>> wrote:
>>>
>>> Actually this is mostly a fine idea but I think the bigger question is
>> how
>>> do we treat templates in general.
>>>
>>> IMO the maintaining author can decide to contribute them or not and the
>>> committers can decide to accept or not. For example in the case of the
>> UR I
>>> may decide to support and maintain it outside of Apache while some from
>>> Salesforce might be submitted as donations. Donation comes at some
>>> obligation. There are lots of examples in Mahout of algorithms whose
>>> authors no longer support them. These are slowly being deprecated and
>>> removed so I’d like to see a method that avoids this issue.
>>>
>>> If we allow maintainers to submit templates to the Gallery with a link
> to
>>> code as well as support then donating the template code to Apache is
>>> independent of acceptance to the Gallery. Any template donated to
> Apache
>>> should come with some commitment by the author to support it there
>>> indefinitely and perhaps even acceptance as a PIO committer—and if they
>>> disappear or don’t support the template it is easy to deprecate/remove.
>>>
>>> That means if Salesforce wants to donate the templates it
>> maintains—great.
>>> Personally I'd would vote for acceptance of most of them. Then the
>> support
>>> link can be to the Apache user list or instructions for joining it. If
> a
>>> maintainer wants to stay out of the Apache repo and support separately
>> then
>>> this is possible also. With all templates treated equally—official or
>>> not—and there is a route to becoming official for non-official ones.
>>>
>>> BTW it might be good to remove the “official” designation in favor of
>>> “Apache supported” or the PredictionIO logo or something like that. We
>>> really need to encourage template development even if they are not code
>>> contributions.
>>>
>>>
>>> On Aug 3, 2016, at 3:32 PM, Simon Chan <simon@salesforce.com <mailto:
> simon@salesforce.com>> wrote:
>>>
>>> Hey guys,
>>>
>>> I just want to start the discussion about moving previously "official"
>>> PredictionIO engine templates into Apache.
>>>
>>> Official templates are those marked "Official" here:
>>> http://templates.prediction.io/ <http://templates.prediction.io/>
>>>
>>> In order to move them to ASF Git, would the best way be creating
>>> sub-directory under PredictionIO repo?
>>>
>>> Simon
Re: 0.10.0 release
Posted by Pat Ferrel <pa...@occamsmachete.com>.
I’ve been talking abut this issue since before we were in the incubator, probably because I maintain one of the most used templates. My vote is to get it right, then release otherwise we create a lot of headaches and ramifications that may never get solved. So in the do-ocracy I’ll volunteer for some of the work below if we decide to go with separate repos.
1) I’ll volunteer to take a couple templates and put them in their own repos if we can get some created.
2) do we have a gallery page yet? we had a good proposal, is it implemented?
3) What templates are worth inclusion? Seems like some of the ALS recommender ones are supersets of others do we need them all?
4) do we need “release” of these except through Apache git and Github? Since they are all built by users I suspect the normal Apache release process can be avoided for them, the full push to maven, binary hosting, etc.
5) We need someone to file Infra Jira’s to get repos. If someone can coach me on this I will do it.
This might only add a week or so to the release date. If we don’t do it I bet it will be much more time spent in support and fixing later.
Who was converting package names in the templates? If that is done adding them to a repo will be easy
On Aug 15, 2016, at 5:01 PM, Donald Szeto <do...@apache.org> wrote:
I think the problem with templates in examples is that they are already
modified and it will be hard to merge any upstream template changes back to
these examples. We need a method to consistently test and support official
templates. We can probably use separate repositories, but I am not sure if
we have enough time if we are planning to release 0.10.0 this week. We
probably want GitHub integration for all these official template repos as
well.
I do not have a strong opinion in mandating one engine one repo, but I
think otherwise it would be hard for customized engines to merge upstream
official changes.
On Mon, Aug 15, 2016 at 3:05 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> Possible but we have template in examples/ for testing and that’s ok imo.
> If we think separate repos is the way to go why not ask?
>
> @mentors how hard would it be to get say 5 new repos tied to github
> mirrors?
>
>
> On Aug 15, 2016, at 1:47 PM, Chan Lee <ch...@gmail.com> wrote:
>
> Regarding 1), I agree with Pat's points for the need to maintain a
> separate repository and release cycle for templates. But for the purpose of
> making the donation process simple and ensuring consistency of templates
> with each new release of PIO, I think having the code reside inside PIO
> repo would be the cleanest solution.
>
> How about creating a separate "apache" branch on each official template
> repo that is consistent with PIO release? So before every PIO release, we
> will merge changes into this "apache" branch, merge them into the main PIO
> repo, and run rigorous tests for each template to ensure that they're
> compatible.
>
> That way people can continue to clone/fork templates as before, it will be
> easy to tag/track template versions compatible with each PIO release, and
> we can ensure that all official engines work with each new PIO release
> which I feel is most important. Also, as Marcin mentioned, we can expand
> tests to keep track of performance changes as well.
>
> Also, I think we should consider merging the current examples/ directory
> with the templates/ directory.
>
> Thanks,
> Chan
>
>
> On Sun, Aug 14, 2016 at 8:30 AM, Pat Ferrel <pat@occamsmachete.com
> <ma...@occamsmachete.com>> wrote:
> Important things unresolved for release:
>
> 1) What to do with Apache templates—my suggestion is separate repos for
> the 3 reasons below.
> 2) We need a Gallery page listing at least a couple converted tested
> templates—couldn’t find this in the site but maybe I missed it. The UR is
> now converted and tested as are the examples.
> 3) AML fork healed, should be pushed this afternoon.
> 4) the rest of the release magic
>
> PIO is rather moot without templates but if they are on a separate release
> schedule like the doc site (which also needs work) we could release without
> 1 & 2. I’d favor that rather than releasing with templates in a templates/
> directory.
>
> Anything else? How are people feeling about release?
>
>
> On Aug 12, 2016, at 10:18 AM, Pat Ferrel <pat@occamsmachete.com <mailto:
> pat@occamsmachete.com>> wrote:
>
> Independent of Apache I’d suggest each template have their own git repo as
> they do now. Is this practically possible in ASF (another example of my
> infrastructure rant but leave that for now). The semantics of this make
> sense. The requirements for all apache or non-apache templates seem to be:
>
> 1) They need to be allowed to have separate release cycles.
> 2) There should be only one way to install templates apache or non-apache
> 3) This method should support tags and branches, and separate PRs
>
> Practically speaking for independent ones (the Universal Recommender will
> remain independent until the issues above are resolved) the templates
> *will* be a separate repo and `git pull` *will* be the method of download.
> To me this implies the Apache ones should use the same pattern.
>
> The separate issue of rules for inclusion in Apache should include a test
> requirement IMO. But inclusion in the Gallery seems a looser attachment to
> the project—just one persons opinion
>
>
> On Aug 11, 2016, at 3:42 PM, Chan Lee <chanlee514@gmail.com <mailto:
> chanlee514@gmail.com>> wrote:
>
> I've begun working on migrating official PredictionIO templates into the
> main apache repository, and there are a few points I'd like to bring to
> attention.
>
> 1) Template code will be merged under templates/ directory, and all commit
> history and authorship will be preserved.
>
> 2) Organization namespace will change in the template code from
> "io.prediction" to "org.apache.predictionio".
>
> 3) In order to download an engine template, users could (1) git clone the
> entire repo and copy the files in templates/<some-template>, or (2) use
> something like svn to download only the necessary subdirectory. I'd like to
> ask what everyone thinks should be the recommended approach. The
> documentation should be updated accordingly (instead of `pio template get`).
>
> 4) I'd like to ask if there are any ActionML/outside templates that should
> be included or updated. For instance, template-scala-parallel-universal-recommendation
> in PredictionIO repo seems outdate compared to one in actionml repo.
>
>
> Thanks,
> Chan
>
>
>
> On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński <zieminm@gmail.com
> <ma...@gmail.com>> wrote:
> I think that this is a very good idea. Obviously it would require
> configuring more concurrent builds to finish in reasonable time, what
> should not be a problem. Besides, it would make the official templates be
> consistent with every next release of PredictionIO and what is very
> important - it would provide many different tests for the repository.
> Having working templates of different types could give us more material to
> test not only the reliability of PredictionIO, but also its performance
> with every change. It would require adding different types of tests and
> tools to gather runtime statistics, but this is something I would like to
> take a look at in the future.
>
> niedz., 7.08.2016 o 10:21 użytkownik Donald Szeto <donald@apache.org
> <ma...@apache.org>>
> napisał:
>
>> We can also make these templates part of the integration test that Chan
> and
>> Marcin just submitted (
>> https://github.com/apache/incubator-predictionio/pull/267 <
> https://github.com/apache/incubator-predictionio/pull/267>). That way we
>> can
>> make commitment to included templates be part of every committer's
> effort.
>> Just my 2c.
>>
>> On Sun, Aug 7, 2016 at 9:47 AM, Pat Ferrel <pat@occamsmachete.com
> <ma...@occamsmachete.com>> wrote:
>>
>>> If this sound ok, I propose the process be:
>>> 1) inclusion in the gallery is a PR to the yaml gallery file. This is
>>> reviewable by all but takes only one committer to approve and merge.
>>> 2) submission for inclusion in the project can be a PR to the new
>>> templates directory as Simon suggests. But this may require a more
> formal
>>> vote, and come with some commitment for support and possibly
>> consideration
>>> of the author for committer status.
>>>
>>> Someone who knows Apache rules better than me may know the type of vote
>> to
>>> have for #2, maybe this is only informal review and single committer
>>> acceptance too as long as the committer is willing to support the
>> template.
>>>
>>> As far as the Salesforce templates marked official, I’d hope that most
>>> would be donated. According to the proposed rules all we need is a PR
> for
>>> each. And again a big thanks to Salesforce!
>>>
>>>
>>> On Aug 4, 2016, at 2:55 PM, Pat Ferrel <pat@occamsmachete.com <mailto:
> pat@occamsmachete.com>> wrote:
>>>
>>> Actually this is mostly a fine idea but I think the bigger question is
>> how
>>> do we treat templates in general.
>>>
>>> IMO the maintaining author can decide to contribute them or not and the
>>> committers can decide to accept or not. For example in the case of the
>> UR I
>>> may decide to support and maintain it outside of Apache while some from
>>> Salesforce might be submitted as donations. Donation comes at some
>>> obligation. There are lots of examples in Mahout of algorithms whose
>>> authors no longer support them. These are slowly being deprecated and
>>> removed so I’d like to see a method that avoids this issue.
>>>
>>> If we allow maintainers to submit templates to the Gallery with a link
> to
>>> code as well as support then donating the template code to Apache is
>>> independent of acceptance to the Gallery. Any template donated to
> Apache
>>> should come with some commitment by the author to support it there
>>> indefinitely and perhaps even acceptance as a PIO committer—and if they
>>> disappear or don’t support the template it is easy to deprecate/remove.
>>>
>>> That means if Salesforce wants to donate the templates it
>> maintains—great.
>>> Personally I'd would vote for acceptance of most of them. Then the
>> support
>>> link can be to the Apache user list or instructions for joining it. If
> a
>>> maintainer wants to stay out of the Apache repo and support separately
>> then
>>> this is possible also. With all templates treated equally—official or
>>> not—and there is a route to becoming official for non-official ones.
>>>
>>> BTW it might be good to remove the “official” designation in favor of
>>> “Apache supported” or the PredictionIO logo or something like that. We
>>> really need to encourage template development even if they are not code
>>> contributions.
>>>
>>>
>>> On Aug 3, 2016, at 3:32 PM, Simon Chan <simon@salesforce.com <mailto:
> simon@salesforce.com>> wrote:
>>>
>>> Hey guys,
>>>
>>> I just want to start the discussion about moving previously "official"
>>> PredictionIO engine templates into Apache.
>>>
>>> Official templates are those marked "Official" here:
>>> http://templates.prediction.io/ <http://templates.prediction.io/>
>>>
>>> In order to move them to ASF Git, would the best way be creating
>>> sub-directory under PredictionIO repo?
>>>
>>> Simon
Re: 0.10.0 release
Posted by Donald Szeto <do...@apache.org>.
I think the problem with templates in examples is that they are already
modified and it will be hard to merge any upstream template changes back to
these examples. We need a method to consistently test and support official
templates. We can probably use separate repositories, but I am not sure if
we have enough time if we are planning to release 0.10.0 this week. We
probably want GitHub integration for all these official template repos as
well.
I do not have a strong opinion in mandating one engine one repo, but I
think otherwise it would be hard for customized engines to merge upstream
official changes.
On Mon, Aug 15, 2016 at 3:05 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> Possible but we have template in examples/ for testing and that’s ok imo.
> If we think separate repos is the way to go why not ask?
>
> @mentors how hard would it be to get say 5 new repos tied to github
> mirrors?
>
>
> On Aug 15, 2016, at 1:47 PM, Chan Lee <ch...@gmail.com> wrote:
>
> Regarding 1), I agree with Pat's points for the need to maintain a
> separate repository and release cycle for templates. But for the purpose of
> making the donation process simple and ensuring consistency of templates
> with each new release of PIO, I think having the code reside inside PIO
> repo would be the cleanest solution.
>
> How about creating a separate "apache" branch on each official template
> repo that is consistent with PIO release? So before every PIO release, we
> will merge changes into this "apache" branch, merge them into the main PIO
> repo, and run rigorous tests for each template to ensure that they're
> compatible.
>
> That way people can continue to clone/fork templates as before, it will be
> easy to tag/track template versions compatible with each PIO release, and
> we can ensure that all official engines work with each new PIO release
> which I feel is most important. Also, as Marcin mentioned, we can expand
> tests to keep track of performance changes as well.
>
> Also, I think we should consider merging the current examples/ directory
> with the templates/ directory.
>
> Thanks,
> Chan
>
>
> On Sun, Aug 14, 2016 at 8:30 AM, Pat Ferrel <pat@occamsmachete.com
> <ma...@occamsmachete.com>> wrote:
> Important things unresolved for release:
>
> 1) What to do with Apache templates—my suggestion is separate repos for
> the 3 reasons below.
> 2) We need a Gallery page listing at least a couple converted tested
> templates—couldn’t find this in the site but maybe I missed it. The UR is
> now converted and tested as are the examples.
> 3) AML fork healed, should be pushed this afternoon.
> 4) the rest of the release magic
>
> PIO is rather moot without templates but if they are on a separate release
> schedule like the doc site (which also needs work) we could release without
> 1 & 2. I’d favor that rather than releasing with templates in a templates/
> directory.
>
> Anything else? How are people feeling about release?
>
>
> On Aug 12, 2016, at 10:18 AM, Pat Ferrel <pat@occamsmachete.com <mailto:
> pat@occamsmachete.com>> wrote:
>
> Independent of Apache I’d suggest each template have their own git repo as
> they do now. Is this practically possible in ASF (another example of my
> infrastructure rant but leave that for now). The semantics of this make
> sense. The requirements for all apache or non-apache templates seem to be:
>
> 1) They need to be allowed to have separate release cycles.
> 2) There should be only one way to install templates apache or non-apache
> 3) This method should support tags and branches, and separate PRs
>
> Practically speaking for independent ones (the Universal Recommender will
> remain independent until the issues above are resolved) the templates
> *will* be a separate repo and `git pull` *will* be the method of download.
> To me this implies the Apache ones should use the same pattern.
>
> The separate issue of rules for inclusion in Apache should include a test
> requirement IMO. But inclusion in the Gallery seems a looser attachment to
> the project—just one persons opinion
>
>
> On Aug 11, 2016, at 3:42 PM, Chan Lee <chanlee514@gmail.com <mailto:
> chanlee514@gmail.com>> wrote:
>
> I've begun working on migrating official PredictionIO templates into the
> main apache repository, and there are a few points I'd like to bring to
> attention.
>
> 1) Template code will be merged under templates/ directory, and all commit
> history and authorship will be preserved.
>
> 2) Organization namespace will change in the template code from
> "io.prediction" to "org.apache.predictionio".
>
> 3) In order to download an engine template, users could (1) git clone the
> entire repo and copy the files in templates/<some-template>, or (2) use
> something like svn to download only the necessary subdirectory. I'd like to
> ask what everyone thinks should be the recommended approach. The
> documentation should be updated accordingly (instead of `pio template get`).
>
> 4) I'd like to ask if there are any ActionML/outside templates that should
> be included or updated. For instance, template-scala-parallel-universal-recommendation
> in PredictionIO repo seems outdate compared to one in actionml repo.
>
>
> Thanks,
> Chan
>
>
>
> On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński <zieminm@gmail.com
> <ma...@gmail.com>> wrote:
> I think that this is a very good idea. Obviously it would require
> configuring more concurrent builds to finish in reasonable time, what
> should not be a problem. Besides, it would make the official templates be
> consistent with every next release of PredictionIO and what is very
> important - it would provide many different tests for the repository.
> Having working templates of different types could give us more material to
> test not only the reliability of PredictionIO, but also its performance
> with every change. It would require adding different types of tests and
> tools to gather runtime statistics, but this is something I would like to
> take a look at in the future.
>
> niedz., 7.08.2016 o 10:21 użytkownik Donald Szeto <donald@apache.org
> <ma...@apache.org>>
> napisał:
>
> > We can also make these templates part of the integration test that Chan
> and
> > Marcin just submitted (
> > https://github.com/apache/incubator-predictionio/pull/267 <
> https://github.com/apache/incubator-predictionio/pull/267>). That way we
> > can
> > make commitment to included templates be part of every committer's
> effort.
> > Just my 2c.
> >
> > On Sun, Aug 7, 2016 at 9:47 AM, Pat Ferrel <pat@occamsmachete.com
> <ma...@occamsmachete.com>> wrote:
> >
> > > If this sound ok, I propose the process be:
> > > 1) inclusion in the gallery is a PR to the yaml gallery file. This is
> > > reviewable by all but takes only one committer to approve and merge.
> > > 2) submission for inclusion in the project can be a PR to the new
> > > templates directory as Simon suggests. But this may require a more
> formal
> > > vote, and come with some commitment for support and possibly
> > consideration
> > > of the author for committer status.
> > >
> > > Someone who knows Apache rules better than me may know the type of vote
> > to
> > > have for #2, maybe this is only informal review and single committer
> > > acceptance too as long as the committer is willing to support the
> > template.
> > >
> > > As far as the Salesforce templates marked official, I’d hope that most
> > > would be donated. According to the proposed rules all we need is a PR
> for
> > > each. And again a big thanks to Salesforce!
> > >
> > >
> > > On Aug 4, 2016, at 2:55 PM, Pat Ferrel <pat@occamsmachete.com <mailto:
> pat@occamsmachete.com>> wrote:
> > >
> > > Actually this is mostly a fine idea but I think the bigger question is
> > how
> > > do we treat templates in general.
> > >
> > > IMO the maintaining author can decide to contribute them or not and the
> > > committers can decide to accept or not. For example in the case of the
> > UR I
> > > may decide to support and maintain it outside of Apache while some from
> > > Salesforce might be submitted as donations. Donation comes at some
> > > obligation. There are lots of examples in Mahout of algorithms whose
> > > authors no longer support them. These are slowly being deprecated and
> > > removed so I’d like to see a method that avoids this issue.
> > >
> > > If we allow maintainers to submit templates to the Gallery with a link
> to
> > > code as well as support then donating the template code to Apache is
> > > independent of acceptance to the Gallery. Any template donated to
> Apache
> > > should come with some commitment by the author to support it there
> > > indefinitely and perhaps even acceptance as a PIO committer—and if they
> > > disappear or don’t support the template it is easy to deprecate/remove.
> > >
> > > That means if Salesforce wants to donate the templates it
> > maintains—great.
> > > Personally I'd would vote for acceptance of most of them. Then the
> > support
> > > link can be to the Apache user list or instructions for joining it. If
> a
> > > maintainer wants to stay out of the Apache repo and support separately
> > then
> > > this is possible also. With all templates treated equally—official or
> > > not—and there is a route to becoming official for non-official ones.
> > >
> > > BTW it might be good to remove the “official” designation in favor of
> > > “Apache supported” or the PredictionIO logo or something like that. We
> > > really need to encourage template development even if they are not code
> > > contributions.
> > >
> > >
> > > On Aug 3, 2016, at 3:32 PM, Simon Chan <simon@salesforce.com <mailto:
> simon@salesforce.com>> wrote:
> > >
> > > Hey guys,
> > >
> > > I just want to start the discussion about moving previously "official"
> > > PredictionIO engine templates into Apache.
> > >
> > > Official templates are those marked "Official" here:
> > > http://templates.prediction.io/ <http://templates.prediction.io/>
> > >
> > > In order to move them to ASF Git, would the best way be creating
> > > sub-directory under PredictionIO repo?
> > >
> > > Simon
> > >
> > >
> > >
> >
>
>
>
>
>
>
Re: 0.10.0 release
Posted by Pat Ferrel <pa...@occamsmachete.com>.
Possible but we have template in examples/ for testing and that’s ok imo. If we think separate repos is the way to go why not ask?
@mentors how hard would it be to get say 5 new repos tied to github mirrors?
On Aug 15, 2016, at 1:47 PM, Chan Lee <ch...@gmail.com> wrote:
Regarding 1), I agree with Pat's points for the need to maintain a separate repository and release cycle for templates. But for the purpose of making the donation process simple and ensuring consistency of templates with each new release of PIO, I think having the code reside inside PIO repo would be the cleanest solution.
How about creating a separate "apache" branch on each official template repo that is consistent with PIO release? So before every PIO release, we will merge changes into this "apache" branch, merge them into the main PIO repo, and run rigorous tests for each template to ensure that they're compatible.
That way people can continue to clone/fork templates as before, it will be easy to tag/track template versions compatible with each PIO release, and we can ensure that all official engines work with each new PIO release which I feel is most important. Also, as Marcin mentioned, we can expand tests to keep track of performance changes as well.
Also, I think we should consider merging the current examples/ directory with the templates/ directory.
Thanks,
Chan
On Sun, Aug 14, 2016 at 8:30 AM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
Important things unresolved for release:
1) What to do with Apache templates—my suggestion is separate repos for the 3 reasons below.
2) We need a Gallery page listing at least a couple converted tested templates—couldn’t find this in the site but maybe I missed it. The UR is now converted and tested as are the examples.
3) AML fork healed, should be pushed this afternoon.
4) the rest of the release magic
PIO is rather moot without templates but if they are on a separate release schedule like the doc site (which also needs work) we could release without 1 & 2. I’d favor that rather than releasing with templates in a templates/ directory.
Anything else? How are people feeling about release?
On Aug 12, 2016, at 10:18 AM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
Independent of Apache I’d suggest each template have their own git repo as they do now. Is this practically possible in ASF (another example of my infrastructure rant but leave that for now). The semantics of this make sense. The requirements for all apache or non-apache templates seem to be:
1) They need to be allowed to have separate release cycles.
2) There should be only one way to install templates apache or non-apache
3) This method should support tags and branches, and separate PRs
Practically speaking for independent ones (the Universal Recommender will remain independent until the issues above are resolved) the templates *will* be a separate repo and `git pull` *will* be the method of download. To me this implies the Apache ones should use the same pattern.
The separate issue of rules for inclusion in Apache should include a test requirement IMO. But inclusion in the Gallery seems a looser attachment to the project—just one persons opinion
On Aug 11, 2016, at 3:42 PM, Chan Lee <chanlee514@gmail.com <ma...@gmail.com>> wrote:
I've begun working on migrating official PredictionIO templates into the main apache repository, and there are a few points I'd like to bring to attention.
1) Template code will be merged under templates/ directory, and all commit history and authorship will be preserved.
2) Organization namespace will change in the template code from "io.prediction" to "org.apache.predictionio".
3) In order to download an engine template, users could (1) git clone the entire repo and copy the files in templates/<some-template>, or (2) use something like svn to download only the necessary subdirectory. I'd like to ask what everyone thinks should be the recommended approach. The documentation should be updated accordingly (instead of `pio template get`).
4) I'd like to ask if there are any ActionML/outside templates that should be included or updated. For instance, template-scala-parallel-universal-recommendation in PredictionIO repo seems outdate compared to one in actionml repo.
Thanks,
Chan
On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński <zieminm@gmail.com <ma...@gmail.com>> wrote:
I think that this is a very good idea. Obviously it would require
configuring more concurrent builds to finish in reasonable time, what
should not be a problem. Besides, it would make the official templates be
consistent with every next release of PredictionIO and what is very
important - it would provide many different tests for the repository.
Having working templates of different types could give us more material to
test not only the reliability of PredictionIO, but also its performance
with every change. It would require adding different types of tests and
tools to gather runtime statistics, but this is something I would like to
take a look at in the future.
niedz., 7.08.2016 o 10:21 użytkownik Donald Szeto <donald@apache.org <ma...@apache.org>>
napisał:
> We can also make these templates part of the integration test that Chan and
> Marcin just submitted (
> https://github.com/apache/incubator-predictionio/pull/267 <https://github.com/apache/incubator-predictionio/pull/267>). That way we
> can
> make commitment to included templates be part of every committer's effort.
> Just my 2c.
>
> On Sun, Aug 7, 2016 at 9:47 AM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
>
> > If this sound ok, I propose the process be:
> > 1) inclusion in the gallery is a PR to the yaml gallery file. This is
> > reviewable by all but takes only one committer to approve and merge.
> > 2) submission for inclusion in the project can be a PR to the new
> > templates directory as Simon suggests. But this may require a more formal
> > vote, and come with some commitment for support and possibly
> consideration
> > of the author for committer status.
> >
> > Someone who knows Apache rules better than me may know the type of vote
> to
> > have for #2, maybe this is only informal review and single committer
> > acceptance too as long as the committer is willing to support the
> template.
> >
> > As far as the Salesforce templates marked official, I’d hope that most
> > would be donated. According to the proposed rules all we need is a PR for
> > each. And again a big thanks to Salesforce!
> >
> >
> > On Aug 4, 2016, at 2:55 PM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
> >
> > Actually this is mostly a fine idea but I think the bigger question is
> how
> > do we treat templates in general.
> >
> > IMO the maintaining author can decide to contribute them or not and the
> > committers can decide to accept or not. For example in the case of the
> UR I
> > may decide to support and maintain it outside of Apache while some from
> > Salesforce might be submitted as donations. Donation comes at some
> > obligation. There are lots of examples in Mahout of algorithms whose
> > authors no longer support them. These are slowly being deprecated and
> > removed so I’d like to see a method that avoids this issue.
> >
> > If we allow maintainers to submit templates to the Gallery with a link to
> > code as well as support then donating the template code to Apache is
> > independent of acceptance to the Gallery. Any template donated to Apache
> > should come with some commitment by the author to support it there
> > indefinitely and perhaps even acceptance as a PIO committer—and if they
> > disappear or don’t support the template it is easy to deprecate/remove.
> >
> > That means if Salesforce wants to donate the templates it
> maintains—great.
> > Personally I'd would vote for acceptance of most of them. Then the
> support
> > link can be to the Apache user list or instructions for joining it. If a
> > maintainer wants to stay out of the Apache repo and support separately
> then
> > this is possible also. With all templates treated equally—official or
> > not—and there is a route to becoming official for non-official ones.
> >
> > BTW it might be good to remove the “official” designation in favor of
> > “Apache supported” or the PredictionIO logo or something like that. We
> > really need to encourage template development even if they are not code
> > contributions.
> >
> >
> > On Aug 3, 2016, at 3:32 PM, Simon Chan <simon@salesforce.com <ma...@salesforce.com>> wrote:
> >
> > Hey guys,
> >
> > I just want to start the discussion about moving previously "official"
> > PredictionIO engine templates into Apache.
> >
> > Official templates are those marked "Official" here:
> > http://templates.prediction.io/ <http://templates.prediction.io/>
> >
> > In order to move them to ASF Git, would the best way be creating
> > sub-directory under PredictionIO repo?
> >
> > Simon
> >
> >
> >
>
Re: 0.10.0 release
Posted by Chan Lee <ch...@gmail.com>.
Regarding 1), I agree with Pat's points for the need to maintain a separate
repository and release cycle for templates. But for the purpose of making
the donation process simple and ensuring consistency of templates with each
new release of PIO, I think having the code reside inside PIO repo would be
the cleanest solution.
How about creating a separate "apache" branch on each official template
repo that is consistent with PIO release? So before every PIO release, we
will merge changes into this "apache" branch, merge them into the main PIO
repo, and run rigorous tests for each template to ensure that they're
compatible.
That way people can continue to clone/fork templates as before, it will be
easy to tag/track template versions compatible with each PIO release, and
we can ensure that all official engines work with each new PIO release
which I feel is most important. Also, as Marcin mentioned, we can expand
tests to keep track of performance changes as well.
Also, I think we should consider merging the current examples/ directory
with the templates/ directory.
Thanks,
Chan
On Sun, Aug 14, 2016 at 8:30 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> Important things unresolved for release:
>
> 1) What to do with Apache templates—my suggestion is separate repos for
> the 3 reasons below.
> 2) We need a Gallery page listing at least a couple converted tested
> templates—couldn’t find this in the site but maybe I missed it. The UR is
> now converted and tested as are the examples.
> 3) AML fork healed, should be pushed this afternoon.
> 4) the rest of the release magic
>
> PIO is rather moot without templates but if they are on a separate release
> schedule like the doc site (which also needs work) we could release without
> 1 & 2. I’d favor that rather than releasing with templates in a templates/
> directory.
>
> Anything else? How are people feeling about release?
>
>
> On Aug 12, 2016, at 10:18 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> Independent of Apache I’d suggest each template have their own git repo as
> they do now. Is this practically possible in ASF (another example of my
> infrastructure rant but leave that for now). The semantics of this make
> sense. The requirements for all apache or non-apache templates seem to be:
>
> 1) They need to be allowed to have separate release cycles.
> 2) There should be only one way to install templates apache or non-apache
> 3) This method should support tags and branches, and separate PRs
>
> Practically speaking for independent ones (the Universal Recommender will
> remain independent until the issues above are resolved) the templates
> *will* be a separate repo and `git pull` *will* be the method of download.
> To me this implies the Apache ones should use the same pattern.
>
> The separate issue of rules for inclusion in Apache should include a test
> requirement IMO. But inclusion in the Gallery seems a looser attachment to
> the project—just one persons opinion
>
>
> On Aug 11, 2016, at 3:42 PM, Chan Lee <ch...@gmail.com> wrote:
>
> I've begun working on migrating official PredictionIO templates into the
> main apache repository, and there are a few points I'd like to bring to
> attention.
>
> 1) Template code will be merged under templates/ directory, and all commit
> history and authorship will be preserved.
>
> 2) Organization namespace will change in the template code from
> "io.prediction" to "org.apache.predictionio".
>
> 3) In order to download an engine template, users could (1) git clone the
> entire repo and copy the files in templates/<some-template>, or (2) use
> something like svn to download only the necessary subdirectory. I'd like to
> ask what everyone thinks should be the recommended approach. The
> documentation should be updated accordingly (instead of `pio template get`).
>
> 4) I'd like to ask if there are any ActionML/outside templates that should
> be included or updated. For instance, template-scala-parallel-universal-recommendation
> in PredictionIO repo seems outdate compared to one in actionml repo.
>
>
> Thanks,
> Chan
>
>
>
> On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński <zi...@gmail.com>
> wrote:
>
>> I think that this is a very good idea. Obviously it would require
>> configuring more concurrent builds to finish in reasonable time, what
>> should not be a problem. Besides, it would make the official templates be
>> consistent with every next release of PredictionIO and what is very
>> important - it would provide many different tests for the repository.
>> Having working templates of different types could give us more material to
>> test not only the reliability of PredictionIO, but also its performance
>> with every change. It would require adding different types of tests and
>> tools to gather runtime statistics, but this is something I would like to
>> take a look at in the future.
>>
>> niedz., 7.08.2016 o 10:21 użytkownik Donald Szeto <do...@apache.org>
>> napisał:
>>
>> > We can also make these templates part of the integration test that Chan
>> and
>> > Marcin just submitted (
>> > https://github.com/apache/incubator-predictionio/pull/267). That way we
>> > can
>> > make commitment to included templates be part of every committer's
>> effort.
>> > Just my 2c.
>> >
>> > On Sun, Aug 7, 2016 at 9:47 AM, Pat Ferrel <pa...@occamsmachete.com>
>> wrote:
>> >
>> > > If this sound ok, I propose the process be:
>> > > 1) inclusion in the gallery is a PR to the yaml gallery file. This is
>> > > reviewable by all but takes only one committer to approve and merge.
>> > > 2) submission for inclusion in the project can be a PR to the new
>> > > templates directory as Simon suggests. But this may require a more
>> formal
>> > > vote, and come with some commitment for support and possibly
>> > consideration
>> > > of the author for committer status.
>> > >
>> > > Someone who knows Apache rules better than me may know the type of
>> vote
>> > to
>> > > have for #2, maybe this is only informal review and single committer
>> > > acceptance too as long as the committer is willing to support the
>> > template.
>> > >
>> > > As far as the Salesforce templates marked official, I’d hope that most
>> > > would be donated. According to the proposed rules all we need is a PR
>> for
>> > > each. And again a big thanks to Salesforce!
>> > >
>> > >
>> > > On Aug 4, 2016, at 2:55 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>> > >
>> > > Actually this is mostly a fine idea but I think the bigger question is
>> > how
>> > > do we treat templates in general.
>> > >
>> > > IMO the maintaining author can decide to contribute them or not and
>> the
>> > > committers can decide to accept or not. For example in the case of the
>> > UR I
>> > > may decide to support and maintain it outside of Apache while some
>> from
>> > > Salesforce might be submitted as donations. Donation comes at some
>> > > obligation. There are lots of examples in Mahout of algorithms whose
>> > > authors no longer support them. These are slowly being deprecated and
>> > > removed so I’d like to see a method that avoids this issue.
>> > >
>> > > If we allow maintainers to submit templates to the Gallery with a
>> link to
>> > > code as well as support then donating the template code to Apache is
>> > > independent of acceptance to the Gallery. Any template donated to
>> Apache
>> > > should come with some commitment by the author to support it there
>> > > indefinitely and perhaps even acceptance as a PIO committer—and if
>> they
>> > > disappear or don’t support the template it is easy to
>> deprecate/remove.
>> > >
>> > > That means if Salesforce wants to donate the templates it
>> > maintains—great.
>> > > Personally I'd would vote for acceptance of most of them. Then the
>> > support
>> > > link can be to the Apache user list or instructions for joining it.
>> If a
>> > > maintainer wants to stay out of the Apache repo and support separately
>> > then
>> > > this is possible also. With all templates treated equally—official or
>> > > not—and there is a route to becoming official for non-official ones.
>> > >
>> > > BTW it might be good to remove the “official” designation in favor of
>> > > “Apache supported” or the PredictionIO logo or something like that. We
>> > > really need to encourage template development even if they are not
>> code
>> > > contributions.
>> > >
>> > >
>> > > On Aug 3, 2016, at 3:32 PM, Simon Chan <si...@salesforce.com> wrote:
>> > >
>> > > Hey guys,
>> > >
>> > > I just want to start the discussion about moving previously "official"
>> > > PredictionIO engine templates into Apache.
>> > >
>> > > Official templates are those marked "Official" here:
>> > > http://templates.prediction.io/
>> > >
>> > > In order to move them to ASF Git, would the best way be creating
>> > > sub-directory under PredictionIO repo?
>> > >
>> > > Simon
>> > >
>> > >
>> > >
>> >
>>
>
>
>
>
Re: 0.10.0 release
Posted by Pat Ferrel <pa...@occamsmachete.com>.
When I say infrastructure I am by no means talking about the Apache Infra *people* who are asked to do an awful lot of work and they do it well. They are asked to create and maintain the equivalent of Github, Gmail, Google Forums, and other tools. It might be time for Apache to re-think this but it is a bit off subject for this thread so I’ll save it for infrastructure@. Unfortunately we can’t wait for something to come out of that discussion to decide what we do for our first Apache release.
If we remove the question of how much work it is to create a new Apache git repo what would we do? PIO (Tappingstone), Salesforce, and ActionML chose a template per repo and users who make simple mods follow this model for the reasons I listed below. Let’s not forget we’ll be talking about this again when we get to SDKs, maybe containers, and microservice refactoring as well. All of which seem natural to think of as separate repos.
Let’s start the discussion with what is easier for maintainers and users? What fits current best practice better? What method fits the practical needs for releasing code best? What method scales and fits future needs better? What method will encourage 3rd party extensions like templates and sdks? What is easiest to document or automate?
If we decide to have a monolithic repo, let's do it because it’s the best thing for the project. What do others think?
On Aug 14, 2016, at 11:02 AM, Andrew Purtell <an...@gmail.com> wrote:
Interesting idea to try separate repos for landing to-be-donated templates. On GitHub repositories are cheap and, though not necessarily at this moment at Apache, easy to provision. If you think separate repo and lifecycle is the best way to manage templates then we PPMC plus mentors should make that happen here.
I would think if the project comes to have a set of core templates used for such things as integration testing and good out of the box experience, these will in fact be coupled with changes to framework and having both in the same repo would seem like a fine idea. Just a thought. Not sure how useful it is, FWIW
Anyway, rather than rant at infrastructure (or suppress one (smile)) I'd encourage you to engage in a proactive manner. Everything self service we have at the foundation today has stemmed from a pain point and constructive proposal. So if you'd like to have a repo per template and anticipate frequent repo provisioning requests to be a problem, start a discussion about self service repo provisioning (or whatever you think will work) on infrastructure@. Podlings are meant to stretch and grow the foundation as much as assimilate IP and governance practice.
> On Aug 14, 2016, at 8:30 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> Important things unresolved for release:
>
> 1) What to do with Apache templates—my suggestion is separate repos for the 3 reasons below.
> 2) We need a Gallery page listing at least a couple converted tested templates—couldn’t find this in the site but maybe I missed it. The UR is now converted and tested as are the examples.
> 3) AML fork healed, should be pushed this afternoon.
> 4) the rest of the release magic
>
> PIO is rather moot without templates but if they are on a separate release schedule like the doc site (which also needs work) we could release without 1 & 2. I’d favor that rather than releasing with templates in a templates/ directory.
>
> Anything else? How are people feeling about release?
>
>
> On Aug 12, 2016, at 10:18 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> Independent of Apache I’d suggest each template have their own git repo as they do now. Is this practically possible in ASF (another example of my infrastructure rant but leave that for now). The semantics of this make sense. The requirements for all apache or non-apache templates seem to be:
>
> 1) They need to be allowed to have separate release cycles.
> 2) There should be only one way to install templates apache or non-apache
> 3) This method should support tags and branches, and separate PRs
>
> Practically speaking for independent ones (the Universal Recommender will remain independent until the issues above are resolved) the templates *will* be a separate repo and `git pull` *will* be the method of download. To me this implies the Apache ones should use the same pattern.
>
> The separate issue of rules for inclusion in Apache should include a test requirement IMO. But inclusion in the Gallery seems a looser attachment to the project—just one persons opinion
>
>
> On Aug 11, 2016, at 3:42 PM, Chan Lee <chanlee514@gmail.com <ma...@gmail.com>> wrote:
>
> I've begun working on migrating official PredictionIO templates into the main apache repository, and there are a few points I'd like to bring to attention.
>
> 1) Template code will be merged under templates/ directory, and all commit history and authorship will be preserved.
>
> 2) Organization namespace will change in the template code from "io.prediction" to "org.apache.predictionio".
>
> 3) In order to download an engine template, users could (1) git clone the entire repo and copy the files in templates/<some-template>, or (2) use something like svn to download only the necessary subdirectory. I'd like to ask what everyone thinks should be the recommended approach. The documentation should be updated accordingly (instead of `pio template get`).
>
> 4) I'd like to ask if there are any ActionML/outside templates that should be included or updated. For instance, template-scala-parallel-universal-recommendation in PredictionIO repo seems outdate compared to one in actionml repo.
>
>
> Thanks,
> Chan
>
>
>
> On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński <zieminm@gmail.com <ma...@gmail.com>> wrote:
> I think that this is a very good idea. Obviously it would require
> configuring more concurrent builds to finish in reasonable time, what
> should not be a problem. Besides, it would make the official templates be
> consistent with every next release of PredictionIO and what is very
> important - it would provide many different tests for the repository.
> Having working templates of different types could give us more material to
> test not only the reliability of PredictionIO, but also its performance
> with every change. It would require adding different types of tests and
> tools to gather runtime statistics, but this is something I would like to
> take a look at in the future.
>
> niedz., 7.08.2016 o 10:21 użytkownik Donald Szeto <donald@apache.org <ma...@apache.org>>
> napisał:
>
>> We can also make these templates part of the integration test that Chan and
>> Marcin just submitted (
>> https://github.com/apache/incubator-predictionio/pull/267 <https://github.com/apache/incubator-predictionio/pull/267>). That way we
>> can
>> make commitment to included templates be part of every committer's effort.
>> Just my 2c.
>>
>>> On Sun, Aug 7, 2016 at 9:47 AM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
>>>
>>> If this sound ok, I propose the process be:
>>> 1) inclusion in the gallery is a PR to the yaml gallery file. This is
>>> reviewable by all but takes only one committer to approve and merge.
>>> 2) submission for inclusion in the project can be a PR to the new
>>> templates directory as Simon suggests. But this may require a more formal
>>> vote, and come with some commitment for support and possibly
>> consideration
>>> of the author for committer status.
>>>
>>> Someone who knows Apache rules better than me may know the type of vote
>> to
>>> have for #2, maybe this is only informal review and single committer
>>> acceptance too as long as the committer is willing to support the
>> template.
>>>
>>> As far as the Salesforce templates marked official, I’d hope that most
>>> would be donated. According to the proposed rules all we need is a PR for
>>> each. And again a big thanks to Salesforce!
>>>
>>>
>>> On Aug 4, 2016, at 2:55 PM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
>>>
>>> Actually this is mostly a fine idea but I think the bigger question is
>> how
>>> do we treat templates in general.
>>>
>>> IMO the maintaining author can decide to contribute them or not and the
>>> committers can decide to accept or not. For example in the case of the
>> UR I
>>> may decide to support and maintain it outside of Apache while some from
>>> Salesforce might be submitted as donations. Donation comes at some
>>> obligation. There are lots of examples in Mahout of algorithms whose
>>> authors no longer support them. These are slowly being deprecated and
>>> removed so I’d like to see a method that avoids this issue.
>>>
>>> If we allow maintainers to submit templates to the Gallery with a link to
>>> code as well as support then donating the template code to Apache is
>>> independent of acceptance to the Gallery. Any template donated to Apache
>>> should come with some commitment by the author to support it there
>>> indefinitely and perhaps even acceptance as a PIO committer—and if they
>>> disappear or don’t support the template it is easy to deprecate/remove.
>>>
>>> That means if Salesforce wants to donate the templates it
>> maintains—great.
>>> Personally I'd would vote for acceptance of most of them. Then the
>> support
>>> link can be to the Apache user list or instructions for joining it. If a
>>> maintainer wants to stay out of the Apache repo and support separately
>> then
>>> this is possible also. With all templates treated equally—official or
>>> not—and there is a route to becoming official for non-official ones.
>>>
>>> BTW it might be good to remove the “official” designation in favor of
>>> “Apache supported” or the PredictionIO logo or something like that. We
>>> really need to encourage template development even if they are not code
>>> contributions.
>>>
>>>
>>> On Aug 3, 2016, at 3:32 PM, Simon Chan <simon@salesforce.com <ma...@salesforce.com>> wrote:
>>>
>>> Hey guys,
>>>
>>> I just want to start the discussion about moving previously "official"
>>> PredictionIO engine templates into Apache.
>>>
>>> Official templates are those marked "Official" here:
>>> http://templates.prediction.io/ <http://templates.prediction.io/>
>>>
>>> In order to move them to ASF Git, would the best way be creating
>>> sub-directory under PredictionIO repo?
>>>
>>> Simon
Re: 0.10.0 release
Posted by Andrew Purtell <an...@gmail.com>.
Interesting idea to try separate repos for landing to-be-donated templates. On GitHub repositories are cheap and, though not necessarily at this moment at Apache, easy to provision. If you think separate repo and lifecycle is the best way to manage templates then we PPMC plus mentors should make that happen here.
I would think if the project comes to have a set of core templates used for such things as integration testing and good out of the box experience, these will in fact be coupled with changes to framework and having both in the same repo would seem like a fine idea. Just a thought. Not sure how useful it is, FWIW
Anyway, rather than rant at infrastructure (or suppress one (smile)) I'd encourage you to engage in a proactive manner. Everything self service we have at the foundation today has stemmed from a pain point and constructive proposal. So if you'd like to have a repo per template and anticipate frequent repo provisioning requests to be a problem, start a discussion about self service repo provisioning (or whatever you think will work) on infrastructure@. Podlings are meant to stretch and grow the foundation as much as assimilate IP and governance practice.
> On Aug 14, 2016, at 8:30 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> Important things unresolved for release:
>
> 1) What to do with Apache templates—my suggestion is separate repos for the 3 reasons below.
> 2) We need a Gallery page listing at least a couple converted tested templates—couldn’t find this in the site but maybe I missed it. The UR is now converted and tested as are the examples.
> 3) AML fork healed, should be pushed this afternoon.
> 4) the rest of the release magic
>
> PIO is rather moot without templates but if they are on a separate release schedule like the doc site (which also needs work) we could release without 1 & 2. I’d favor that rather than releasing with templates in a templates/ directory.
>
> Anything else? How are people feeling about release?
>
>
> On Aug 12, 2016, at 10:18 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> Independent of Apache I’d suggest each template have their own git repo as they do now. Is this practically possible in ASF (another example of my infrastructure rant but leave that for now). The semantics of this make sense. The requirements for all apache or non-apache templates seem to be:
>
> 1) They need to be allowed to have separate release cycles.
> 2) There should be only one way to install templates apache or non-apache
> 3) This method should support tags and branches, and separate PRs
>
> Practically speaking for independent ones (the Universal Recommender will remain independent until the issues above are resolved) the templates *will* be a separate repo and `git pull` *will* be the method of download. To me this implies the Apache ones should use the same pattern.
>
> The separate issue of rules for inclusion in Apache should include a test requirement IMO. But inclusion in the Gallery seems a looser attachment to the project—just one persons opinion
>
>
> On Aug 11, 2016, at 3:42 PM, Chan Lee <chanlee514@gmail.com <ma...@gmail.com>> wrote:
>
> I've begun working on migrating official PredictionIO templates into the main apache repository, and there are a few points I'd like to bring to attention.
>
> 1) Template code will be merged under templates/ directory, and all commit history and authorship will be preserved.
>
> 2) Organization namespace will change in the template code from "io.prediction" to "org.apache.predictionio".
>
> 3) In order to download an engine template, users could (1) git clone the entire repo and copy the files in templates/<some-template>, or (2) use something like svn to download only the necessary subdirectory. I'd like to ask what everyone thinks should be the recommended approach. The documentation should be updated accordingly (instead of `pio template get`).
>
> 4) I'd like to ask if there are any ActionML/outside templates that should be included or updated. For instance, template-scala-parallel-universal-recommendation in PredictionIO repo seems outdate compared to one in actionml repo.
>
>
> Thanks,
> Chan
>
>
>
> On Mon, Aug 8, 2016 at 9:16 AM, Marcin Ziemiński <zieminm@gmail.com <ma...@gmail.com>> wrote:
> I think that this is a very good idea. Obviously it would require
> configuring more concurrent builds to finish in reasonable time, what
> should not be a problem. Besides, it would make the official templates be
> consistent with every next release of PredictionIO and what is very
> important - it would provide many different tests for the repository.
> Having working templates of different types could give us more material to
> test not only the reliability of PredictionIO, but also its performance
> with every change. It would require adding different types of tests and
> tools to gather runtime statistics, but this is something I would like to
> take a look at in the future.
>
> niedz., 7.08.2016 o 10:21 użytkownik Donald Szeto <donald@apache.org <ma...@apache.org>>
> napisał:
>
>> We can also make these templates part of the integration test that Chan and
>> Marcin just submitted (
>> https://github.com/apache/incubator-predictionio/pull/267 <https://github.com/apache/incubator-predictionio/pull/267>). That way we
>> can
>> make commitment to included templates be part of every committer's effort.
>> Just my 2c.
>>
>>> On Sun, Aug 7, 2016 at 9:47 AM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
>>>
>>> If this sound ok, I propose the process be:
>>> 1) inclusion in the gallery is a PR to the yaml gallery file. This is
>>> reviewable by all but takes only one committer to approve and merge.
>>> 2) submission for inclusion in the project can be a PR to the new
>>> templates directory as Simon suggests. But this may require a more formal
>>> vote, and come with some commitment for support and possibly
>> consideration
>>> of the author for committer status.
>>>
>>> Someone who knows Apache rules better than me may know the type of vote
>> to
>>> have for #2, maybe this is only informal review and single committer
>>> acceptance too as long as the committer is willing to support the
>> template.
>>>
>>> As far as the Salesforce templates marked official, I’d hope that most
>>> would be donated. According to the proposed rules all we need is a PR for
>>> each. And again a big thanks to Salesforce!
>>>
>>>
>>> On Aug 4, 2016, at 2:55 PM, Pat Ferrel <pat@occamsmachete.com <ma...@occamsmachete.com>> wrote:
>>>
>>> Actually this is mostly a fine idea but I think the bigger question is
>> how
>>> do we treat templates in general.
>>>
>>> IMO the maintaining author can decide to contribute them or not and the
>>> committers can decide to accept or not. For example in the case of the
>> UR I
>>> may decide to support and maintain it outside of Apache while some from
>>> Salesforce might be submitted as donations. Donation comes at some
>>> obligation. There are lots of examples in Mahout of algorithms whose
>>> authors no longer support them. These are slowly being deprecated and
>>> removed so I’d like to see a method that avoids this issue.
>>>
>>> If we allow maintainers to submit templates to the Gallery with a link to
>>> code as well as support then donating the template code to Apache is
>>> independent of acceptance to the Gallery. Any template donated to Apache
>>> should come with some commitment by the author to support it there
>>> indefinitely and perhaps even acceptance as a PIO committer—and if they
>>> disappear or don’t support the template it is easy to deprecate/remove.
>>>
>>> That means if Salesforce wants to donate the templates it
>> maintains—great.
>>> Personally I'd would vote for acceptance of most of them. Then the
>> support
>>> link can be to the Apache user list or instructions for joining it. If a
>>> maintainer wants to stay out of the Apache repo and support separately
>> then
>>> this is possible also. With all templates treated equally—official or
>>> not—and there is a route to becoming official for non-official ones.
>>>
>>> BTW it might be good to remove the “official” designation in favor of
>>> “Apache supported” or the PredictionIO logo or something like that. We
>>> really need to encourage template development even if they are not code
>>> contributions.
>>>
>>>
>>> On Aug 3, 2016, at 3:32 PM, Simon Chan <simon@salesforce.com <ma...@salesforce.com>> wrote:
>>>
>>> Hey guys,
>>>
>>> I just want to start the discussion about moving previously "official"
>>> PredictionIO engine templates into Apache.
>>>
>>> Official templates are those marked "Official" here:
>>> http://templates.prediction.io/ <http://templates.prediction.io/>
>>>
>>> In order to move them to ASF Git, would the best way be creating
>>> sub-directory under PredictionIO repo?
>>>
>>> Simon
>
>
>