Larry +1 we need to be able to do both, and it's usually scenario driven at least in my experience.
Cheers, Chris On 3/22/13 1:38 PM, "larry mccay" <[email protected]> wrote: >I would certainly lean toward CTR while we are in the early stages of >the project and a small number of committers. >We can easily review changes that look interesting as they go by. > >As we get close to a release it may make sense to switch to RTC until it >ships. > >@Alan, do projects generally switch that way? > >Given half decent test coverage day to day changes shouldn't require RTC. >Any time you feel like changes could use another set of eyes just send >a review request. > >On Fri, Mar 22, 2013 at 4:11 PM, Kevin Minder <[email protected]> wrote: >> We'll first off I'd have created a Jira if Jira was setup. That is the >>last >> piece of infra that we don't have yet. >> >> Second wrt CRT/RTC, this is something we should probably discuss. It >>feels >> to me like RTC could really hamper productivity. The mentors probably >>have >> some strong opinions about this so I'd like to hear them. >> >> >> On 3/22/13 4:08 PM, Alan Gates wrote: >>> >>> A question first before I try to answer your question: Is Knox CTR or >>> RTC? CTR (commit then review) is committers are allowed to commit and >>>other >>> committers are expected to review within a few days if they have >>>concerns. >>> RTC (review then commit) is a committer needs a +1 from another >>>committer >>> before committing (or in this case pushing) their code. CTR lends >>>itself >>> better to projects that are more worried about speed and RTC works >>>well in >>> projects that want to be biased towards stability at the cost of speed. >>> >>> If Knox is CTR, then no problem. If it's RTC you technically should >>>pull >>> out the change and wait for a +1. Given that Larry has effectively >>>+1'd >>> your change by saying "leave it", even if it's RTC I'd probably leave >>>it at >>> this point. >>> >>> To answer the other question, coding changes like this don't generally >>> need an explicit vote. When you post the patch you're giving people a >>> chance to vote up or down on the change on the JIRA. And for code >>>changes >>> it's lazy consensus (that is, if someone doesn't vote then "silence >>>implies >>> consent"). >>> >>> Which leads me to another question. Is there a JIRA for this change? >>>I >>> am not sure how the projects using git are integrating with JIRA. But >>> having a JIRA ticket with code for the change posted on it is >>>invaluable for >>> allowing others to see what you're doing and give their feedback. >>> >>> Alan. >>> >>> On Mar 22, 2013, at 12:16 PM, Kevin Minder wrote: >>> >>>> Uh Oh. >>>> I pushed by accident. I know what you are all saying. Sure it was an >>>> accident... But it really was. >>>> What should I do now? Try to figure how to revert it or only attempt >>>> that if people object? >>>> Kevin. >>>> >>>> On 3/22/13 12:36 PM, Kevin Minder wrote: >>>>> >>>>> Thanks. Just feeling this out and trying to figure out how to go fast >>>>> without being ignoring the community. I'll be interested in what the >>>>> mentors have to say on the topic. >>>>> >>>>> On 3/22/13 12:25 PM, larry mccay wrote: >>>>>> >>>>>> I say make it so. >>>>>> >>>>>> Is this any different than a refactoring of the source, really? >>>>>> I think that votes are probably required for things that affect the >>>>>> community like a release which goes to the outside world. >>>>>> >>>>>> A change that fundamentally changes the architecture in such a way >>>>>> that existing extensions from outside the project will be affected >>>>>> would be another thing that we would need a vote for. >>>>>> >>>>>> A change in the charter and vision of the project would probably >>>>>> warrant a vote. >>>>>> >>>>>> IMHO - this is more of an internal change that doesn't affect the >>>>>> community or any existing extensions and shouldn't be slowed down >>>>>>by a >>>>>> vote. >>>>>> >>>>>> That said... >>>>>> >>>>>> +1 to the proposed layout and I suggest that you just commit it once >>>>>> done. >>>>>> If you are unsure about it a review request would suffice. >>>>>> >>>>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> So how does this work? >>>>>>> >>>>>>> I've spent the last 24 hours digging deep into Maven assemblies and >>>>>>> finally >>>>>>> have a working standalone prototype that can be used to implement >>>>>>>the >>>>>>> second >>>>>>> model described below. >>>>>>> Both Larry and I prefer this model instead of the current model. >>>>>>>This >>>>>>> preferred model has individual jars as opposed to creating large >>>>>>> executable >>>>>>> jars that contain all dependencies. >>>>>>> >>>>>>> So my question is how long should I wait to implement? >>>>>>> I don't really expect much of an opinion from anyone other that >>>>>>>Larry >>>>>>> at >>>>>>> this point BTW. >>>>>>> >>>>>>> Perhaps I'll do the work and submit a patch to the list for review >>>>>>>and >>>>>>> if >>>>>>> nobody has input by say Monday morning apply the patch? >>>>>>> >>>>>>> >>>>>>> On 3/21/13 3:26 PM, larry mccay wrote: >>>>>>>>> >>>>>>>>> The other option I can see is something like this where bin/ and >>>>>>>>> lib/ >>>>>>>>> would >>>>>>>>> change >>>>>>>>> >>>>>>>>> bin/ >>>>>>>>> gateway.jar - Empty executable jar with manifest main class >>>>>>>>> and >>>>>>>>> class >>>>>>>>> path referring to JARs in lib/ >>>>>>>>> ldap.jar - Empty executable jar with manifest main class >>>>>>>>>and >>>>>>>>> class >>>>>>>>> path >>>>>>>>> referring to JARs in lib/ >>>>>>>>> shell.jar - Empty executable jar with manifest main class >>>>>>>>>and >>>>>>>>> class >>>>>>>>> path >>>>>>>>> referring to JARs in lib/ >>>>>>>>> lib/ >>>>>>>>> gateway-server-0.2.0-SNAPSHOT.jar >>>>>>>>> gateway-test-ldap-0.2.0-SNAPSHOT.jar >>>>>>>>> gateway-shell-0.2.0-SNAPSHOT.jar >>>>>>>>> commons-io-2.4.jar >>>>>>>>> groovy-1.5.6.jar >>>>>>>>> jetty-6.1.26.jar >>>>>>>>> shiro-core-1.2.1.jar >>>>>>>>> ... many more ... >>>>>>>>> >>>>>>>> I believe that this is my preference. >>>>>>>> We may also want to add a gateway-common module that can be pulled >>>>>>>> out >>>>>>>> as a separate jar so that shell doesn't need to depend on all of >>>>>>>> server in order for them to share internal dependencies. >>>>>>>> >>>>>>>> Anyway - this approach gets my +1. >>>>>>>> >>>>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder >>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi Everyone, >>>>>>>>> >>>>>>>>> I want to raise an issue I been thinking about regarding the >>>>>>>>>layout >>>>>>>>> of >>>>>>>>> the >>>>>>>>> install. In particular the layout of the JARs. Currently the >>>>>>>>>build >>>>>>>>> is >>>>>>>>> using the Maven Shade plugin to create a single executable JARs >>>>>>>>>for >>>>>>>>> things >>>>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell >>>>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server >>>>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar) >>>>>>>>> >>>>>>>>> On one had I like this because it is neat and tidy. >>>>>>>>> >>>>>>>>> On the other hand wearing my potential RM has it raises some >>>>>>>>> concerns. >>>>>>>>> >>>>>>>>> 1) It complicates the LICENSE and NOTICE file generation since >>>>>>>>>it is >>>>>>>>> difficult to see what the dependencies are other than from >>>>>>>>>reports. >>>>>>>>> 2) The server and the shell likely share some dependencies. >>>>>>>>>Creating >>>>>>>>> self >>>>>>>>> contained JARs for each causes duplication and disk bloat. >>>>>>>>> 3) Does this cause or solve a patch issue? Is it easier for >>>>>>>>> customer to >>>>>>>>> be >>>>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of >>>>>>>>>potentially >>>>>>>>> a set >>>>>>>>> of >>>>>>>>> patched JARs? >>>>>>>>> 4) The Apache build env seems to be running Maven 2 and the shade >>>>>>>>> plugin >>>>>>>>> we >>>>>>>>> are using required Maven 3. >>>>>>>>> >>>>>>>>> So this is what the "install" looks like now >>>>>>>>> >>>>>>>>> bin/ >>>>>>>>> gateway-0.2.0-SNAPSHOT.jar >>>>>>>>> ldap-0.2.0-SNAPSHOT.jar >>>>>>>>> shell-0.2.0-SNAPSHOT.jar >>>>>>>>> lib/ - Empty but reserved for future use >>>>>>>>> ext/ - Empty but to be used by customers for custom extension >>>>>>>>> samples/ - Distributed sample files >>>>>>>>> templates/ - Distributed configuration templates >>>>>>>>> deployments/ - Location for customer topology deployments >>>>>>>>> >>>>>>>>> The other option I can see is something like this where bin/ and >>>>>>>>> lib/ >>>>>>>>> would >>>>>>>>> change >>>>>>>>> >>>>>>>>> bin/ >>>>>>>>> gateway.jar - Empty executable jar with manifest main class >>>>>>>>> and >>>>>>>>> class >>>>>>>>> path referring to JARs in lib/ >>>>>>>>> ldap.jar - Empty executable jar with manifest main class >>>>>>>>>and >>>>>>>>> class >>>>>>>>> path >>>>>>>>> referring to JARs in lib/ >>>>>>>>> shell.jar - Empty executable jar with manifest main class >>>>>>>>>and >>>>>>>>> class >>>>>>>>> path >>>>>>>>> referring to JARs in lib/ >>>>>>>>> lib/ >>>>>>>>> gateway-server-0.2.0-SNAPSHOT.jar >>>>>>>>> gateway-test-ldap-0.2.0-SNAPSHOT.jar >>>>>>>>> gateway-shell-0.2.0-SNAPSHOT.jar >>>>>>>>> commons-io-2.4.jar >>>>>>>>> groovy-1.5.6.jar >>>>>>>>> jetty-6.1.26.jar >>>>>>>>> shiro-core-1.2.1.jar >>>>>>>>> ... many more ... >>>>>>>>> >>>>>>>>> Kevin. >> >>
