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. >>>> >> >
