On Fri, Aug 29, 2008 at 5:23 PM, Simon Lessard <[EMAIL PROTECTED]> wrote: > I think you can only assign tickets to known contributors, that is JIRA > users with some special permissions, which is not the case for some people > on my team.
correct. > Of course, in the best world, assigning the ticket to yourself and mark it > as "In progress" would be the best way to prevent clashes. perhaps adding a comment, like "I started to look at it" would help? -M > > > ~ Simon > > On Fri, Aug 29, 2008 at 1:18 AM, Matthias Wessendorf <[EMAIL PROTECTED]> > wrote: >> >> >> Sent from my iPod. >> Am 29.08.2008 um 01:53 schrieb "Simon Lessard" >> <[EMAIL PROTECTED]>: >> >> Ok, >> >> The branch is now compiling and TODOs of the following format were placed >> in the newly created methods : // TODO: JSF 2.0 #xx >> >> We also created a JIRA ticket of every of those TODOs, so if you feel like >> trying one, you can add a comment in JIRA saying that you're taking the >> ticker. Before taking a ticket, make sure that no one else is currently >> working on it to prevent clashes. >> >> That's why you can assign tickets. >> >> The next step on my side is to add more TODOs for the updated methods and >> create a JIRA ticket for them, then I'll get to coding myself. >> >> >> Thanks, >> >> ~ Simon >> >> >> On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard <[EMAIL PROTECTED]> >> wrote: >>> >>> Thank :) Although give me 10 minutes or so to fix something stupid I did >>> before doing a checkout. >>> >>> >>> Regards, >>> >>> ~ Simon >>> >>> On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote: >>>> >>>> Thank you Simon. I will join this soon. >>>> >>>> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard >>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Hi Bruno, >>>>> >>>>> So far my planing was: >>>>> >>>>> sequential >>>>> 1. Create all new API classes: done >>>>> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in >>>>> their body when they aren't abstract: in progress and I already found some >>>>> strange stuff that I might raise on the EG group discussions as for why >>>>> Application.getResourceHandler isn't abstract while all other get handler >>>>> methods are: in progress >>>>> >>>>> *** At that point, IMPL will no longer compile *** >>>>> >>>>> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment >>>>> in their body >>>>> >>>>> *** Everything should compile but don't work at all *** >>>>> >>>>> parallel >>>>> 4. Modify the build plugin to include jsf 2.0 changes >>>>> 5. Implement the API changes >>>>> 6. Implement the IMPL changes >>>>> 7. Implement the JS library >>>>> >>>>> I would really like to use Facelets code when required, but we'll have >>>>> to make sure it's alright with legal discuss first I think, I'm not well >>>>> versed enough in this kind of very specific issues. >>>>> >>>>> It's a very high level roadmap, We should probably use much finer >>>>> granularity for point 5 to 7, but I'm not there yet. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> ~ Simon >>>>> >>>>> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <[EMAIL PROTECTED]> >>>>> wrote: >>>>>> >>>>>> 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 >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Hazem Ahmed Saleh Ahmed >>>> http://www.jroller.com/page/HazemBlog >>>> >>>> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j : >>>> http://code.google.com/p/gmaps4jsf/ >>> >> > > -- 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
