+1 to JIRAsŠ +1 to being able to do both CTR and RTC. Cheers, Chris
P.S. Sorry have been behind on email :( On 3/22/13 1:36 PM, "Alan Gates" <[email protected]> wrote: > >On Mar 22, 2013, at 1:11 PM, Kevin Minder 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. > >Hmm, bummer. We definitely want JIRAs so we can track the changes. >Unless the git based projects don't do it that way. Any feedback from >mentors who've been on a git based project would be appreciated here. > >> >> 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. >The only strong opinion I have is that the project needs to pick one so >people know what to expect. My personal opinion is that CTR works better >when a project is young and needs to move quickly and RTC works better >when a project is mature and wants to guard against instability. But >this should be decided by the project committers more than then mentors. > >Alan. > >> >> 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. >> >
