How about folding them into one single repo with each template/examples as subprojects? Since we have retired the use of `pio template` command for a while, there is not really a hard requirement that each template has to be a git repo by itself.
On Fri, Sep 21, 2018 at 10:59 PM takako shimamoto <chiboch...@gmail.com> wrote: > I don’t think giter8 is the best solution. There's room for > improvement. To improve workability in maintaining 7 official > templates and 12 examples, it's a good idea to put them together into > a repository. Isn't that just one of the options as a solution to > PIO-128? > > On Sat, Sep 22, 2018 at 9:10 AM Naoki Takezoe <take...@gmail.com> wrote: > > > > Hi Donald, > > > > Thanks for your reply! > > > > > I think Giter8 is a nice idea, but my concern with it is its tight > coupling with sbt. > > > > Yes, giter8 templates changes user experience largely. This is my > > concern about it. > > > > > How about creating scripts that would make managing these templates > easier, despite they are in separate repos? > > > > Separated repositories are making situiation difficult. If all of them > > in a single repository, we can handle them easy. For example, we can > > commit and push modification for all templates at once. Even if > > repositories are separated, of course, it might be possible to create > > a script to automate these operation. But where should we put this > > script? But there is another problem. I don't know how users can clone > > a certain template if all templates are in a single repository. > > > > Also, we have to maintain examples in the PredictionIO repository. > > Currently, rhere are 12 example templates and need to be synchronized > > when original templates are updated. > > > > 2018年9月22日(土) 8:45 Donald Szeto <don...@apache.org>: > > > > > > Thanks for bringing this up, Naoki! > > > > > > I think Giter8 is a nice idea, but my concern with it is its tight > coupling > > > with sbt. It requires users to have access to sbt in their terminal > instead > > > of a simple git clone. How about creating scripts that would make > managing > > > these templates easier, despite they are in separate repos? I was > hoping > > > https://issues.apache.org/jira/projects/PIO/issues/PIO-128 would help > with > > > that. > > > > > > A counter-argument to the above would be due to > > > https://issues.apache.org/jira/projects/PIO/issues/PIO-81, users will > need > > > to have access to sbt to build official templates anyway (assuming we > > > continue using sbt as the build tool for official templates). > > > > > > I agree the quickstart can be moved to where the template is though. > > > > > > On Fri, Sep 21, 2018 at 1:02 AM Naoki Takezoe <take...@gmail.com> > wrote: > > > > > > > Hi all, > > > > > > > > I'd like to discuss about maintenance of the official templates. > > > > > > > > I updated all official templates for PredictionIO 0.13.0. There are 7 > > > > templates for now and I think it's too expensive to use our poor > > > > resource to maintain. So I'd like to propose something to reduce > > > > maintenance cost of these templates. > > > > > > > > For example, porting them to giter8 templates is one idea. Takako has > > > > worked on it before > > > > (https://github.com/shimamoto/predictionio-template.g8). It makes > > > > possible to aggregate multiple templates to a single project, and > also > > > > help to reduce duplication. or at least, we might be able to > aggregate > > > > them to a single project simply. > > > > > > > > Further, we need to maintain the quickstart document in the > > > > PredictionIO repository as well. I wonder if we can move these docs > > > > (and examples as well?) to corresponding template repositories. It > > > > would make the synchronization of templates and docs much easier. > > > > > > > > Anyway, every release of PredictionIO causes such extra and > > > > unessential costs. I really want to reduce them. It would help to > make > > > > more frequent development and releases in the future. I'd like to > hear > > > > your opinion or ideas. > > > > > > > > -- > > > > Naoki Takezoe > > > > > > > > > > > > -- > > Naoki Takezoe >
