I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment?
Thanks! Bruno 2008/8/28 Matthias Wessendorf <[EMAIL PROTECTED]> > On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard > <[EMAIL PROTECTED]> wrote: > > > > > > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <[EMAIL PROTECTED] > > > > wrote: > >> > >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard > >> <[EMAIL PROTECTED]> wrote: > >> > Hi Simon, > >> > > >> > > >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <[EMAIL PROTECTED] > > > >> > wrote: > >> >> > >> >> I see from the commit list that a new JSF2.0 branch has been created. > >> >> > >> >> I don't remember seeing *any* kind of discussion or even announcement > >> >> about this. While I am happy to see JSF2.0 work going on, this kind > of > >> >> approach does not seem to be at all in the "community" spirit. IMO, > >> >> major > >> >> events like this should be discussed beforehand. > >> > > >> > As mentioned by other people, there was a vote about this a while back > . > >> > Why > >> > did I create it just now? Simply because my company agreed to provide > >> > some > >> > resource to help with the implementation and we were ready to get > >> > started. > >> > >> One might ask here for a CCLA ;-) > >> We did that for Oracle way back, and update once in a while all the > >> contributors, > >> that have signed the iCLA. > > > > Yeah, but Fujistu signed a CCLA already when I became commiter, so that's > a > > non issue as well. > > good. > > > > >> > >> > > >> >> > >> >> One issue, for example, is that the core-1.2 stuff is currently > >> >> half-way-converted from the trinidad plugins to the > >> >> myfaces-builder-plugin. > >> >> So now it is branched, any changes need to be applied in two places. > >> > > >> > To be honest, I find this irrelevant, it's a branch, not a trunk and > >> > I'll > >> > most likely do some branch merging when core 1.2.x get release and the > >> > plugin might have to change a little to support jsfVersion 2.0. > >> > > >> >> > >> >> In addition, a large amount of code has just been committed by > someone > >> >> (slessard) who is not a particularly regular contributor to myfaces. > >> > > >> > I see even less relevance in that statement. > >> > > >> >> > >> >> Where did this code come from? Do we need a code grant for it? Note > >> >> that > >> >> when code is developed iteratively on the dev list then there is no > >> >> need for > >> >> a grant. But a sudden code dump is different, even when contributed > by > >> >> someone who has signed a CLA. > >> > > >> > The code was coded just yesterday by me and is not much at all, > creating > >> > missing classes for the JavaDoc change log is in no matter a large > >> > amount in > >> > term of complexity. Also since I was the only author of it (my > teammates > >> > will wait until I have added the signatures). There's absolutely no > need > >> > of > >> > code grant either. > >> > >> I agree on the code grant, b/c of it is really pretty trivial to > >> create those API classes/interfaces > >> (based on the javadoc log, as I said before). > >> @signatures: you mean the iCLA / CCLA, aren't you ? > > > > nah, I meant method signatures, it will be easier for my teammates to > know > > what they have to do once there's a nice // TODO: Convert to JSF 2.0 > added > > in every new method's body. > > > > As far as I understand the legal issues (might have to fallback to > > [EMAIL PROTECTED] though), they won't need a CLA until they become > commiters. > > I don't know if I should have the company add their names to the CCLA > > no. wrong > cla == contributor license agreement. > I usually ask for that after one or two patches. Never been an issue at > all. > We (from ORA) add those contributors to our CCLA, and fax the update to > Sam Ruby (our ASF secretary). > > > however. Technically, we aren't bound contractualy by any intellectual > > property transfer with my employer and we're developping outside normal > > business hours so we aren't directly paid either for it so I don't know > if > > adding their name to the CCLA is even needed or not. > > that means, what you develop on your sparetime is yours... NO CCLA update > required. Cool > > -Matthias > > > > > > > ~ Simon > > > >> > >> > > >> >> > >> >> And with 3 branches to now maintain, we need to discuss whether and > >> >> when > >> >> we phase out maintenance of the jsf-1.1 branch. Currently when users > >> >> provide > >> >> patches in jira, they almost always provide a patch against only one > >> >> version > >> >> and the committer ports it, which does increase the load on existing > >> >> committers. When do we stop asking committers to do this when > patching > >> >> bugs? > >> > > >> > I can take care of the branch merging, this is how we handled the > >> > trinidad > >> > 1.2 branch at first, Adam would do the merging every now and then, so > >> > I'm > >> > not asking the committers to do some extra work. > >> > >> yup. not a big deal. Also I doubt that that many folks will work > >> there, on the branch. > >> If the branch needs some merging... fine as well, IMO. > >> > >> > > >> >> > >> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress, and > >> >> appreciate people contributing time to write an ASF-2.0-licensed > >> >> implementation. But it is a standard saying at Apache that > "community > >> >> is > >> >> more important than code", and the "community" aspect here seems to > >> >> have > >> >> been rather neglected... > >> > > >> > I don't agree at all here. Although it wasn't announced on the dev > list, > >> > the > >> > JIRA ticket created to attach patches was speciafically for the > >> > community. > >> > >> and the branch creation was also discussed. > >> > >> > Code provided by Fujitsu employees will never go through me with > direct > >> > commit, it will all be added as patches, even extra tests and > >> > documentation > >> > as we want them and everyone else willing to help get the credit for > it. > >> > >> we do the same. Folks provide patches and jira tickets to describe the > >> problem. > >> > >> > Furthermore, I personally didn't announce it because the branch will > be > >> > very > >> > instable for a week or two until we finish adding the missing > signatures > >> > (impl might not even always compile). > >> > >> dev@ is a developers community; so that would be fine :-) > >> > >> -Matthias > >> > >> > If community wasn't important in the process we would just have used a > >> > private repository at Fujitsu, worked on it for some time with my > team, > >> > then > >> > commit some very large amount of code (real large) that would have > >> > needed a > >> > code grant, prevented the people to see at what rythm things were > >> > progressing and contributing. The only point I *could* give you here > is > >> > that > >> > maybe I should have annouced the creation directly on the dev list and > >> > point > >> > on the JIRA ticket and SVN url rather than relying only on JIRA ticket > >> > report that get forwarded on the dev list. > >> > > >> > > >> > Regards, > >> > > >> > ~ Simon > >> > > >> >> > >> >> Regards, > >> >> Simon > >> >> > >> > > >> > > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> Need JSF and Web 2.0? > >> http://code.google.com/p/facesgoodies > >> > >> further stuff: > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> mail: matzew-at-apache-dot-org > > > > > > > > -- > Matthias Wessendorf > > Need JSF and Web 2.0? > http://code.google.com/p/facesgoodies > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org >
