I totally agree with that Donald :), but now its been weeks discussing the same subject and nothing changed. This is what I am talking about.
On Wed, Nov 4, 2009 at 4:32 PM, Donald Woods <dwo...@apache.org> wrote: > Apache is built upon open collaboration within a community. > > Here, we have a significant code donation being offered, which would save us > months or years in jump starting a JSR-303 implementation at Apache. > Therefore, I believe the only fair approach is one that allows the code > contributor commit karma from day one, which would be he Podling route. > > We need to build a community around any JSR-303 implementation we create and > having someone join from day one who has been working on JSR-303 since April > 2008, would be a great asset to have on-board. > > > -Donald > > > Mohammad Nour El-Din wrote: >> >> Hi... >> >> IMO, and sorry for saying that, now we've been transformed from >> thinking about the project on how to get Roman involved in code >> submission. IMO if this has no solution to be taken to get things up >> and running fast enough so either Ron accepts that situation, or we >> start doing it the way Nial started. >> >> On Wed, Nov 4, 2009 at 3:31 PM, Niall Pemberton >> <niall.pember...@gmail.com> wrote: >>> >>> On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods <dwo...@apache.org> wrote: >>>> >>>> Niall Pemberton wrote: >>>>> >>>>> On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods <dwo...@apache.org> >>>>> wrote: >>>>>> >>>>>> Niall Pemberton wrote: >>>>>>> >>>>>>> On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods <dwo...@apache.org> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Nail. I'm the one who created that copy of 1.4, so it's fine if >>>>>>>> we >>>>>>>> repurpose it, see VALIDATOR-279. >>>>>>>> >>>>>>>> As far as the API, we already have a clean room copy of the 1.0 GA >>>>>>>> API >>>>>>>> created over in the Apache Geronimo Specs subproject [1], with the >>>>>>>> other >>>>>>>> Java EE spec APIs we ship, so I'd be -1 on creating another copy, >>>>>>>> see >>>>>>>> VALIDATOR-274 for history. >>>>>>>> >>>>>>>> As far as the provider implementation, I've been working with the >>>>>>>> Agimatec-Validation project [2] currently hosted on Google Code >>>>>>>> which >>>>>>>> is >>>>>>>> ASL >>>>>>>> 2.0 licensed to bring it over to Apache. >>>>>>> >>>>>>> Cool :) >>>>>>> >>>>>>>> I have a completed SGA from the >>>>>>>> company (Agimatec Gmbh) that developed the code, but was working >>>>>>>> with >>>>>>>> some >>>>>>>> other ASF members on how we should bring the code into the ASF, so >>>>>>>> guess >>>>>>>> it's time to start discussing that here. >>>>>>> >>>>>>> Has the SGA been recorded at the ASF? >>>>>> >>>>>> No, as I was waiting to see if we were going the Podling or >>>>>> sub-project >>>>>> route. >>>>>> >>>>>>>> Currently, our thoughts were to >>>>>>>> bring it in as a subproject to an existing TLP (like Commons, >>>>>>>> OpenJPA >>>>>>>> or >>>>>>>> Geronimo) and not create a new Incubator Podling, since we have >>>>>>>> committers >>>>>>>> from multiple projects interested in working on a JSR-303 >>>>>>>> implementation >>>>>>>> (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only >>>>>>>> complication, >>>>>>>> is that we would need to offer committership to Roman from Agimatec >>>>>>>> as >>>>>>>> soon >>>>>>>> as the Incubator IP clearance is finished, as he would need to be >>>>>>>> the >>>>>>>> one >>>>>>>> to >>>>>>>> remove the existing Agimatec copyright statements. Thoughts? >>>>>>> >>>>>>> If we have an SGA from the Agimatec then I think anyone can remove >>>>>>> their copyright statements from the source code. However its not nice >>>>>>> IMO to take someones code and then expect them(Roman) to start >>>>>>> submitting patches and not give them access. If we did this in the >>>>>>> Commons Sandbox, then all the existing ASF committers can have access >>>>>>> straight away - but I think its unlikely that the Commons PMC will >>>>>>> grant Roman access from day one (I can ask though). If that is the >>>>>>> case then it would be better to do it as an incubator podling. We >>>>>>> have >>>>>>> done that recently when commons accepted Sanselan from the incubator >>>>>>> and graduating should be relatively easy since Commons's requirements >>>>>>> for a component to be part of "proper" are usually 1) is it ready to >>>>>>> release and 2) does it have 3+ committers. >>>>>> >>>>>> Either a Podling or sub-project works for me. The only complication >>>>>> with >>>>>> a >>>>>> sub-project, is I'd need a Commons PMC member to work with me to >>>>>> submit >>>>>> the >>>>>> initial Agimatec code snapshot, IP clearance form and SGA to the >>>>>> Incubator >>>>>> for me. >>>>> >>>>> I can do that. >>>>> >>>>>> Can you start a discussion on priv...@commons about accepting the >>>>>> codebase >>>>>> and which method the community would like to follow? >>>>> >>>>> Already done. >>>> >>>> Any updates on this? >>> >>> Apologies for the delay in responding. I asked for opinions from the >>> PMC specifically on whether we could give access to the Sandbox to >>> someone who wasn't an ASF committer and didn't have a prior history of >>> contribution. Most of the PMC has been silent on this and the response >>> I did get was mixed (i.e. both for and against) so even if it was >>> possible to get a majority vote, I am not comfortable pushing for this >>> approach since I believe it would be divisive for Commons. >>> >>> This means that if we go the Commons Sandbox route, then Roman would >>> be left needing to submit patches to his own work until he'd earn't >>> enough Karma to be voted in. Personally I don't think that would be a >>> great situation unless he is completely happy doing that. So probably >>> the best approach would be to go the Incubator podling route. >>> >>> WDYT? >>> >>> Niall >>> >>>> -Donald >>>> >>>>> Niall >>>>> >>>>>> -Donald >>>>>> >>>>>>> Niall >>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-validation_1.0_spec >>>>>>>> >>>>>>>> [2] http://code.google.com/p/agimatec-validation/ >>>>>>>> >>>>>>>> >>>>>>>> -Donald >>>>>>>> >>>>>>>> >>>>>>>> Niall Pemberton wrote: >>>>>>>>> >>>>>>>>> The current trunk in the validator2 sandbox is a copy of the >>>>>>>>> Validator >>>>>>>>> 1.4 code from "commons proper" - but I think we should dump all the >>>>>>>>> existing validator framework code and just retain the "routines" >>>>>>>>> package. Trying to maintain any sort of compatibility with the >>>>>>>>> existing validator framework would be alot more work and code and >>>>>>>>> create a real mess IMO and I think it would be better to not to >>>>>>>>> even >>>>>>>>> try. The "routines" package was refactored realtively recently(!) >>>>>>>>> and >>>>>>>>> can stand on its own. >>>>>>>>> >>>>>>>>> So I would like to propose the following direction for a Validator2 >>>>>>>>> based on the Bean Validation Framework(JSR 303) - a project with >>>>>>>>> three >>>>>>>>> separate modules composing of: >>>>>>>>> >>>>>>>>> - The Bean Validation (JSR303) API - no dependencies >>>>>>>>> - Standalone Validation Routines (based on existing validator >>>>>>>>> routines package) - no dependencies including Bean Validation API >>>>>>>>> - Validation Framework - JSR303 implementation (depends on two >>>>>>>>> modules >>>>>>>>> above) >>>>>>>>> >>>>>>>>> I have created an alternative branch in the Validator sandbox >>>>>>>>> project >>>>>>>>> based on the above approach: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/ >>>>>>>>> >>>>>>>>> I have created a "clean room" implementation of the Bean Validation >>>>>>>>> API[1] which (hopefully) is complete except for JavaDocs. The only >>>>>>>>> real functionality is in javax.validation.Validation - the rest are >>>>>>>>> annotations, interfaces and exceptions. I have also copied the >>>>>>>>> "routines" package into a standalone module[2]. So the next thing >>>>>>>>> is >>>>>>>>> to start the actual framework implementation module. >>>>>>>>> >>>>>>>>> How does this sound as an approach? >>>>>>>>> >>>>>>>>> Niall >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-api/ >>>>>>>>> [2] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-routines/ >>>>>>>>> [3] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://svn.apache.org/viewvc/commons/sandbox/validator2/branches/alternative/validation-framework/ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thanks - Mohammad Nour - LinkedIn: http://www.linkedin.com/in/mnour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein "Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best." - Clean Code: A Handbook of Agile Software Craftsmanship --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
