Well they asked IF it were time for attic after the last report I delivered..
On Fri, Jul 31, 2015, 18:02 Eric Charles <e...@apache.org> wrote: > On 2015-07-31 12:09, nino martinez wael wrote: > > I have no Hard feeling about this, both have pros and cons.. > > > > +0 > > > > Plus, because it's initiative, and we lack this very much, and board are > > pushing to send us to attic > > I didn't see board pushing for this but I may have missed this. > Can you give pointers? > > > > > On Fri, Jul 31, 2015, 10:45 Eric Charles <e...@apache.org> wrote: > > > >> I think it is more how we see onami. Are they independent modules that > >> live more or less independently and maintained by different people, or a > >> service for the application developer. > >> > >> If you have changes in only one module, the workload will be the same, > >> but if you have changes in multiple modules, you would have to release > >> multiple times instead of one. Of course, releasing one supposes the > >> timing is good to do it. > >> > >> On 2015-07-31 10:36, Stephan Classen wrote: > >>> decoupling will reduce the workload for releasing. because you only > >>> release one module and don't have to worry about all the rest. > >>> what increases a little is the work for the developer of a module since > >>> they have to maintain their dependencies and cannot rely to the parent > >>> because it would only contain the most basic/common dependencies > >>> > >>> > >>> > >>> > >>> On 07/31/2015 10:30 AM, Eric Charles wrote: > >>>> I see onami more like a platform, meaning that if a dev decides to use > >>>> onami-persist, it will potentially decides to use > onami-configuration... > >>>> > >>>> On my side I can invest to release if the workload is not high. Taking > >>>> the decoupling way is going to explode the needed work which I won't > >>>> be able to offer. > >>>> > >>>> On 2015-07-31 10:20, Stephan Classen wrote: > >>>>> OK, I see you point. > >>>>> > >>>>> Still i vote -1 > >>>>> > >>>>> There are currently so few commits that at most 2 modules will have > >>>>> changes in a release. > >>>>> This means that all other modules have a version released which is > >> equal > >>>>> to the previous one. > >>>>> In the end this makes it very confusing for the end user which > version > >>>>> they should choose. > >>>>> On the other hand it is hard for the developers to figure out which > >>>>> versions are affected by a bug. > >>>>> > >>>>> I would rather suggest going the other direction and decouple the > >> models > >>>>> more. > >>>>> Make them more like full projects and not part of a bigger one. > >>>>> This would mean > >>>>> - reduce the number common dependencies in the parent > >>>>> - have a repository per project and not a big repo for all > projects > >>>>> - decouple the builds -> don't build all modules but have a build > for > >>>>> every module > >>>>> - separate project/module for the homepage -> maybe move away from > >>>>> building the main page with maven to something more flexible and > >> include > >>>>> only sub pages from maven (like statistics, testcoverage, javadoc, > >>>>> dependencies, ...) > >>>>> > >>>>> My hopes with this approach would be > >>>>> - more up to date homepage > >>>>> - like onami-persist is still in 'sandbox' even though it is > >>>>> productive since over a year > >>>>> - maybe become a 'community' site for guice > >>>>> - easier to on-board new modules and developers > >>>>> - it is just a pain if it takes more than an hour to get > started > >>>>> - move to git > >>>>> - this is way simpler if we follow the default maven directory > >>>>> hierarchy, which is again simpler for single projects than for > >>>>> multi-projects > >>>>> > >>>>> I think this would address you first two points. What it cannot > address > >>>>> is you third point about incompatible module versions. > >>>>> But the question here is how interdependent are the modules? I don't > >>>>> know most of the modules but the ones I took a look at did not > interact > >>>>> with anything except guice. > >>>>> > >>>>> So what do you think? > >>>>> > >>>>> Stephan > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 07/31/2015 09:55 AM, Eric Charles wrote: > >>>>>> This would result in: > >>>>>> - less manual version maintenance in the pom for the developer > >>>>>> - less work to have module(s) released > >>>>>> - less risk to have users use non compatible modules > >>>>>> > >>>>>> On 2015-07-31 09:32, Stephan Classen wrote: > >>>>>>> What is the main goal of this? > >>>>>>> Releasing is currently not a pain. > >>>>>>> > >>>>>>> Do you want to clear the way for a migration to git? > >>>>>>> > >>>>>>> Stephan > >>>>>>> > >>>>>>> > >>>>>>> On 07/31/2015 09:04 AM, Eric Charles wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> To make it easier and lighter, I would like proposing having a > >> single > >>>>>>>> release for all onami modules/extensions. > >>>>>>>> > >>>>>>>> The downside is that we may have to release some modules even if > >>>>>>>> there > >>>>>>>> is no change for some of them. > >>>>>>>> > >>>>>>>> WDYT? > >>>>>>>> > >>>>>>>> Eric > >>>>>>> > >>>>> > >>> > >> > > >
