Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
On 8/25/06, Wendy Smoak [EMAIL PROTECTED] wrote: I'd be thrilled to have every commit reference a JIRA issue, but that's probably too much to ask all at once. For now I'll be happy with seeing more of them, and maybe we can move closer to 'all' at some point in the future. I am also strongly in favor of having every change accompanied by a JIRA issue. Eventually we're going to have to do this to have professional change logs and release notes. In addition to JIRA issues, we still need descriptive commit messages. More than Fixes MYFACES-123 Thanks Bob! for example. ;) For my commit messages, I typically use Fix for MyFaces-XYZ -- [subject of the Jira issue] This gives an easy way to know what was being fixed without having to pull up the issue tracker.Also, if somehow I mistyped the jira identifier, it'd still be clear what was really being fixed.
[jira] Created: (TOMAHAWK-618) Partial Page Rendering for tomahawk
Partial Page Rendering for tomahawk --- Key: TOMAHAWK-618 URL: http://issues.apache.org/jira/browse/TOMAHAWK-618 Project: MyFaces Tomahawk Issue Type: New Feature Components: New Component Affects Versions: 1.1.5-SNAPSHOT Reporter: Ernst Fastl Priority: Minor Fix For: 1.1.5-SNAPSHOT Attachments: pprPanelGroupPatch.zip, pprPanelGroupPatch.zip With this component you can souround areas of a page which you want to be updated by AJAX calls. You just specify in the partialTriggers-Attribute a comma-seperated List of Ids of componenst (e.g. buttons) which trigger this partial update. This is a initial commit so it is not yet well tested and there are still a lot of things to do, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
This is not the first time that the use of JIRA for tracking changes has come up. http://www.mail-archive.com/dev@myfaces.apache.org/msg13737.html Every commit has the possibility of breaking the codebase or changing expected behavior, and having JIRA issues helps to know why and how these changes happened. On 8/23/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: yeah same for fixing typos or else ;) I had your stuff in mind, when I wrote these emails I quoted some threads On 8/23/06, Cagatay Civici [EMAIL PROTECTED] wrote: In my case, JIRA helps me to keep track of things I'm working on. For example I've created issues for stuff like security resolver, excel exporter, client side validation and assigned these to myself. Of course this seems unnecessary for minor commits. On 8/23/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: almost all ;) wendy pointed out more detailed, what I was thinking about :) On 8/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, but that's a far cry from Matze's for all commits. For all major enhancements, I'm absolutely d'accord. regards, Martin On 8/23/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: I really don't see the necessity for MyFaces committers to do all extensions of MyFaces through jira, if sufficient communication has happened on the developer list first. Why do you think that opening a jira-issue and adding patches will make us more efficient in the development process? Patches from committers don't need to go through JIRA, but IMO there ought to be an issue corresponding to every major change in functionality or addition. Commit messages that clearly explain what is being added or changed, and that refer to a JIRA issue, make life much easier when trying to track down problems, construct release notes, or just learn about the codebase. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Updated: (TOMAHAWK-618) Partial Page Rendering for tomahawk
[ http://issues.apache.org/jira/browse/TOMAHAWK-618?page=all ] Catalin Kormos updated TOMAHAWK-618: Status: Patch Available (was: Open) Partial Page Rendering for tomahawk --- Key: TOMAHAWK-618 URL: http://issues.apache.org/jira/browse/TOMAHAWK-618 Project: MyFaces Tomahawk Issue Type: New Feature Components: New Component Affects Versions: 1.1.5-SNAPSHOT Reporter: Ernst Fastl Assigned To: Catalin Kormos Priority: Minor Fix For: 1.1.5-SNAPSHOT Attachments: pprPanelGroupPatch.zip, pprPanelGroupPatch.zip With this component you can souround areas of a page which you want to be updated by AJAX calls. You just specify in the partialTriggers-Attribute a comma-seperated List of Ids of componenst (e.g. buttons) which trigger this partial update. This is a initial commit so it is not yet well tested and there are still a lot of things to do, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Partial Page Rendering for tomahawk
Hi,Well, sandbox or not. I missed the discussion. Remember client sidevalidation stuff? That was a good thread. Or the s:secureTag thread? These two weremuch more open development than here, I guess. Maybe that's all Imissed here. But to me this particular commit *smells*. Sorry, but that's my point.As the guy who started these discussions, I also believe that open discussions are very important before deciding an action. Other than the vital points already mentioned in this thread, open discussions is a nice way to get the ideas of other committers about the design, code and etc. CagatayOn 8/23/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Martin,glad to hear that you are concerned about that too.We should ensure for the future, that the new developers understandhow the ASF works and that they should consult the the list, in caseof... ;) I fixed the svn props and build now the codefor a quick review.I think Ernst / Catalin learned their lection.Finally thx for the contribution.and let's move over to a pure discussion thread, if needed ;) -MatthiasOn 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: Matthias, you're absolutely right - I'm just as concerned as you about offline development, and asked Ernst several times to engage in an discussion on the mailing list. He did so in the beginning, but then ended up going back to his desk to finish off his first draft of what the PPR support could look like client-side (with a very small server side implementation alongside). This is what was committed to the sandbox just now. My personal best plan would have been to start a discussion again on these accomplishments as soon as he had them done and ready for a review, and well, I wasn't asked (nor could be asked, cause I am offline for giving a JSF training) before the commit happened. Shortly from wanting to excuse the guys, I'll offer some further explanation - the Google SoC program is about to end shortly, and this is why Ernst and Catalin might have time-pressured to get the code in the sandbox to be able to discuss on it. In any case, I think that both Catalin and Ernst will have enough to read about in this thread, and will make sure that something like this will not happen in the future again. Especially Catalin needs to take more care here - as a committer, you are the gatekeeper for what foreign code enters the source base and what not. Catalin, can you make sure that all of Wendy's objections are addressed? I tried to address some of them, but didn't get to propstyle-settings, e.g. And, Ernst, fax your ICLA out - ASAP. And now, one final statement: Ernst, thank you very much for your efforts with regards to AJAX and PPR in tomahawk. I strongly believe this will be an important, much used feature of tomahawk many users will just love, and I do think your implementation is very good, but let's carry on the discussion on this on another thread. regards, Martin On 8/23/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 8/22/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Matthias!The sort of offline development. Sending offline a patch to acommitter for letting him commit the stuff is to me a -1. Looks like a bypass. Do you propose to use jira as mini-incubator? I am not sure this is what it is meant for. na, that's not the idea behind this mail. What I miss in this case is the openess of the discussion. There was no. Maybe sb of us here had been interested. Maybe not! Not a big deal to start a thread and upload new features (or new components) to jira. Lot's of users do that.In this case it was committed to the sandbox, no? I like the idea to see the sandbox as incubator even more, we are still free to remove stuff, so this is not against open development Well, sandbox or not. I missed the discussion. Remember client side validation stuff? That was a good thread. Or the s:secureTag thread? These two were much more open development than here, I guess. Maybe that's all I missed here. But to me this particular commit *smells*. Sorry, but that's my point. If you compare sandbox w/ incubator you should say, that there (incubator) is also a PMC behind which decides what should go into the incubator or not. Sure, we can remove that afterwards, but that's not needed if the community process is working. Like incubator I am speaking here of the development community.I think, for this (Google SoC) project, where Ernst worked together closely with Martin it is good enough, and that way it is easier to check the code quality AND if it works. If I had to trash my trunk with its patch I suspect I'd check this code (given the pressure I currently have) Yes, that's for the Google SoC. It is cool that he worked closely with Martin. I like that. But I don't see the point why using jira is a show stopper. With a patch to jira it's also possible to look at the quality and the component itself. I don't doubt about the quality. I am
Re: Partial Page Rendering for tomahawk
Hi all! This is a initial commit so it is not yet well tested and there are still a lot of things to do, but if anyone wants to start playing around with it and making suggestions for improvements I would be thankful for some feedback. JFYI - I've started to try to use it in our application, still, there are some problems I try to figure out and send a patch to Ernst through pm then. Ciao, Mario
Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
Ok, but that's a far cry from Matze's for all commits. For all major enhancements, I'm absolutely d'accord. regards, Martin On 8/23/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: I really don't see the necessity for MyFaces committers to do all extensions of MyFaces through jira, if sufficient communication has happened on the developer list first. Why do you think that opening a jira-issue and adding patches will make us more efficient in the development process? Patches from committers don't need to go through JIRA, but IMO there ought to be an issue corresponding to every major change in functionality or addition. Commit messages that clearly explain what is being added or changed, and that refer to a JIRA issue, make life much easier when trying to track down problems, construct release notes, or just learn about the codebase. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
almost all ;) wendy pointed out more detailed, what I was thinking about :) On 8/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, but that's a far cry from Matze's for all commits. For all major enhancements, I'm absolutely d'accord. regards, Martin On 8/23/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: I really don't see the necessity for MyFaces committers to do all extensions of MyFaces through jira, if sufficient communication has happened on the developer list first. Why do you think that opening a jira-issue and adding patches will make us more efficient in the development process? Patches from committers don't need to go through JIRA, but IMO there ought to be an issue corresponding to every major change in functionality or addition. Commit messages that clearly explain what is being added or changed, and that refer to a JIRA issue, make life much easier when trying to track down problems, construct release notes, or just learn about the codebase. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
In my case, JIRA helps me to keep track of things I'm working on. For example I've created issues for stuff like security resolver, excel exporter, client side validation and assigned these to myself. Of course this seems unnecessary for minor commits. On 8/23/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: almost all ;)wendy pointed out more detailed, what I was thinking about :)On 8/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, but that's a far cry from Matze's for all commits. For all major enhancements, I'm absolutely d'accord. regards, Martin On 8/23/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote:I really don't see the necessity for MyFaces committers to do all extensions of MyFaces through jira, if sufficient communication has happened on the developer list first. Why do you think that opening a jira-issue and adding patches will make us more efficient in the development process? Patches from committers don't need to go through JIRA, but IMO there ought to be an issue corresponding to every major change in functionality or addition. Commit messages that clearly explain what is being added or changed, and that refer to a JIRA issue, make life much easier when trying to track down problems, construct release notes, or just learn about the codebase. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces--Matthias Wessendorffurther stuff:blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
yeah same for fixing typos or else ;) I had your stuff in mind, when I wrote these emails I quoted some threads On 8/23/06, Cagatay Civici [EMAIL PROTECTED] wrote: In my case, JIRA helps me to keep track of things I'm working on. For example I've created issues for stuff like security resolver, excel exporter, client side validation and assigned these to myself. Of course this seems unnecessary for minor commits. On 8/23/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: almost all ;) wendy pointed out more detailed, what I was thinking about :) On 8/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok, but that's a far cry from Matze's for all commits. For all major enhancements, I'm absolutely d'accord. regards, Martin On 8/23/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: I really don't see the necessity for MyFaces committers to do all extensions of MyFaces through jira, if sufficient communication has happened on the developer list first. Why do you think that opening a jira-issue and adding patches will make us more efficient in the development process? Patches from committers don't need to go through JIRA, but IMO there ought to be an issue corresponding to every major change in functionality or addition. Commit messages that clearly explain what is being added or changed, and that refer to a JIRA issue, make life much easier when trying to track down problems, construct release notes, or just learn about the codebase. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Partial Page Rendering for tomahawk
Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. With this component you can souround areas of a page which you want to be updated by AJAX calls. You just specify in the partialTriggers-Attribute a comma-seperated List of Ids of componenst (e.g. buttons) which trigger this partial update. This is a initial commit so it is not yet well tested and there are still a lot of things to do, but if anyone wants to start playing around with it and making suggestions for improvements I would be thankful for some feedback. kind regards Ernst
Re: Partial Page Rendering for tomahawk
After verifying the patches I send him Catalin was so kind and commited the which patches? what is the Jira issue number for that? new sandbox component called PPRPanelGroup to the sandbox. With this component you can souround areas of a page which you want to be updated by AJAX calls. You just specify in the partialTriggers-Attribute a comma-seperated List of Ids of componenst (e.g. buttons) which trigger this partial update. This is a initial commit so it is not yet well tested and there are still a lot of things to do, but if anyone wants to start playing around with it and making suggestions for improvements I would be thankful for some feedback. kind regards Ernst -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Partial Page Rendering for tomahawk
On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there! I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy
Re: Partial Page Rendering for tomahawk
For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). regards, Martin On 8/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there! I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Partial Page Rendering for tomahawk
I am not concerned about the icla or not I am more concerned about the fact that patches sent offline and not through Jira. I mean, why ? On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). regards, Martin On 8/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there! I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Proposal Jira (was Re: Partial Page Rendering for tomahawk)
what about using Jira first. for almost all commits ? I mean this makes us more efficent to follow the development process ;) So each change to API, non trivial enhancement, etc must! go through jira. WDYT ? -Matthias On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am not concerned about the icla or not I am more concerned about the fact that patches sent offline and not through Jira. I mean, why ? On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). regards, Martin On 8/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there! I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Partial Page Rendering for tomahawk
On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am not concerned about the icla or notAs a PMC member for Apache MyFaces, you *should* be concerned about this.Part of the responsibility that the ASF Board delegates to each PMC is to ensure that all code ultimately included in the project is covered by appropriate licensing, so that downstream users of Apache software can be assured that this is the case. For patches included as attachments on a JIRA issue, we provide a convenient way for the poster to grant a license specifically for this patch. Therefore, sending all patches from non-committers through JIRA helps create an audit trail, and is therefore a Good Thing. However, this will not be considered sufficient for large contributions, where the contributor is also asked to sign an Individual CLA[1]. How large is large? Clearly, we shouldn't need this for for a three-line patch submitted through JIRA with the appropriate radio button granting a license attrached. But would it have been OK to accept all of Trinidad as a humongous patch, simply by having someone have checked the button? Nope ... that is definitely large enough to require more. A contribution of this size (multiple source files and associated resources) is definitely at the point where the should in the page referenced below means REALLY REALLY should.Is the original author of these classes willing to sign and fax in a CLA[2]? If so, that gets us over the first hurdle. If not, the files should definitely be removed. The second problem is one that Wendy pointed out ... lack of license headers on the source files. While the details of this policy are currently being reviewed, standing practice is to use the complete header that you'll see on all the other MyFaces source files, in its entirety, at the top of every source file. As committers, this is something we should look for on incoming new source files before adding them to the source code repository. Because these files do not have such headers, they should be removed, and not re-added until both issues (CLA and license headers) have been addressed. The line-endings issue is something that should also be fixed, but it's not make-or-break to have source code in the repository. But having these broken means you'll have to answer to people like Wendy :-). I am more concerned about the fact that patches sent offlineand not through Jira.Even if they had been, that would not have been sufficient in this case, for the reasons outlined above. I mean, why ?Craig McClanahan [1] http://www.apache.org/licenses/[2] http://www.apache.org/licenses/icla.txt On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). regards, Martin On 8/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote:Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there!I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces --Matthias Wessendorffurther stuff:blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Partial Page Rendering for tomahawk
Hi Matthias! The sort of offline development. Sending offline a patch to a committer for letting him commit the stuff is to me a -1. Looks like a bypass. Do you propose to use jira as mini-incubator? I am not sure this is what it is meant for. In this case it was committed to the sandbox, no? I like the idea to see the sandbox as incubator even more, we are still free to remove stuff, so this is not against open development I think, for this (Google SoC) project, where Ernst worked together closely with Martin it is good enough, and that way it is easier to check the code quality AND if it works. If I had to trash my trunk with its patch I suspect I'd check this code (given the pressure I currently have) For sure, it was not the best way how this code found its way into myfaces, but let it be and we'll ensure for the future that it will go better. Beside this: I have a bad need for such a kind of stuff currently (so I am biased ;-) ), so I'll check it before I go on with ajax4jsf or ajaxAnywhere - I'll start in the next two days. (maybe today) Ciao, Mario
Re: Partial Page Rendering for tomahawk
On 8/22/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Matthias! The sort of offline development. Sending offline a patch to a committer for letting him commit the stuff is to me a -1. Looks like a bypass. Do you propose to use jira as mini-incubator? I am not sure this is what it is meant for. na, that's not the idea behind this mail. What I miss in this case is the openess of the discussion. There was no. Maybe sb of us here had been interested. Maybe not! Not a big deal to start a thread and upload new features (or new components) to jira. Lot's of users do that. In this case it was committed to the sandbox, no? I like the idea to see the sandbox as incubator even more, we are still free to remove stuff, so this is not against open development Well, sandbox or not. I missed the discussion. Remember client side validation stuff? That was a good thread. Or the s:secureTag thread? These two were much more open development than here, I guess. Maybe that's all I missed here. But to me this particular commit *smells*. Sorry, but that's my point. If you compare sandbox w/ incubator you should say, that there (incubator) is also a PMC behind which decides what should go into the incubator or not. Sure, we can remove that afterwards, but that's not needed if the community process is working. Like incubator I am speaking here of the development community. I think, for this (Google SoC) project, where Ernst worked together closely with Martin it is good enough, and that way it is easier to check the code quality AND if it works. If I had to trash my trunk with its patch I suspect I'd check this code (given the pressure I currently have) Yes, that's for the Google SoC. It is cool that he worked closely with Martin. I like that. But I don't see the point why using jira is a show stopper. With a patch to jira it's also possible to look at the quality and the component itself. I don't doubt about the quality. I am just worried about the process ;) For sure, it was not the best way how this code found its way into myfaces, but let it be and we'll ensure for the future that it will go better. I hope so. I am not planing to remove this. Just giving a heads-up about the totaly wrong way (IMO). -Matthias
Re: Partial Page Rendering for tomahawk
Matthias, you're absolutely right - I'm just as concerned as you about offline development, and asked Ernst several times to engage in an discussion on the mailing list. He did so in the beginning, but then ended up going back to his desk to finish off his first draft of what the PPR support could look like client-side (with a very small server side implementation alongside). This is what was committed to the sandbox just now. My personal best plan would have been to start a discussion again on these accomplishments as soon as he had them done and ready for a review, and well, I wasn't asked (nor could be asked, cause I am offline for giving a JSF training) before the commit happened. Shortly from wanting to excuse the guys, I'll offer some further explanation - the Google SoC program is about to end shortly, and this is why Ernst and Catalin might have time-pressured to get the code in the sandbox to be able to discuss on it. In any case, I think that both Catalin and Ernst will have enough to read about in this thread, and will make sure that something like this will not happen in the future again. Especially Catalin needs to take more care here - as a committer, you are the gatekeeper for what foreign code enters the source base and what not. Catalin, can you make sure that all of Wendy's objections are addressed? I tried to address some of them, but didn't get to propstyle-settings, e.g. And, Ernst, fax your ICLA out - ASAP. And now, one final statement: Ernst, thank you very much for your efforts with regards to AJAX and PPR in tomahawk. I strongly believe this will be an important, much used feature of tomahawk many users will just love, and I do think your implementation is very good, but let's carry on the discussion on this on another thread. regards, Martin On 8/23/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 8/22/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Matthias! The sort of offline development. Sending offline a patch to a committer for letting him commit the stuff is to me a -1. Looks like a bypass. Do you propose to use jira as mini-incubator? I am not sure this is what it is meant for. na, that's not the idea behind this mail. What I miss in this case is the openess of the discussion. There was no. Maybe sb of us here had been interested. Maybe not! Not a big deal to start a thread and upload new features (or new components) to jira. Lot's of users do that. In this case it was committed to the sandbox, no? I like the idea to see the sandbox as incubator even more, we are still free to remove stuff, so this is not against open development Well, sandbox or not. I missed the discussion. Remember client side validation stuff? That was a good thread. Or the s:secureTag thread? These two were much more open development than here, I guess. Maybe that's all I missed here. But to me this particular commit *smells*. Sorry, but that's my point. If you compare sandbox w/ incubator you should say, that there (incubator) is also a PMC behind which decides what should go into the incubator or not. Sure, we can remove that afterwards, but that's not needed if the community process is working. Like incubator I am speaking here of the development community. I think, for this (Google SoC) project, where Ernst worked together closely with Martin it is good enough, and that way it is easier to check the code quality AND if it works. If I had to trash my trunk with its patch I suspect I'd check this code (given the pressure I currently have) Yes, that's for the Google SoC. It is cool that he worked closely with Martin. I like that. But I don't see the point why using jira is a show stopper. With a patch to jira it's also possible to look at the quality and the component itself. I don't doubt about the quality. I am just worried about the process ;) For sure, it was not the best way how this code found its way into myfaces, but let it be and we'll ensure for the future that it will go better. I hope so. I am not planing to remove this. Just giving a heads-up about the totaly wrong way (IMO). -Matthias -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
I really don't see the necessity for MyFaces committers to do all extensions of MyFaces through jira, if sufficient communication has happened on the developer list first. Why do you think that opening a jira-issue and adding patches will make us more efficient in the development process? regards, Martin On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: what about using Jira first. for almost all commits ? I mean this makes us more efficent to follow the development process ;) So each change to API, non trivial enhancement, etc must! go through jira. WDYT ? -Matthias On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am not concerned about the icla or not I am more concerned about the fact that patches sent offline and not through Jira. I mean, why ? On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). regards, Martin On 8/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there! I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
One clarification: For external contributions, a jira-issue definitely makes sense. regards, Martin On 8/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: I really don't see the necessity for MyFaces committers to do all extensions of MyFaces through jira, if sufficient communication has happened on the developer list first. Why do you think that opening a jira-issue and adding patches will make us more efficient in the development process? regards, Martin On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: what about using Jira first. for almost all commits ? I mean this makes us more efficent to follow the development process ;) So each change to API, non trivial enhancement, etc must! go through jira. WDYT ? -Matthias On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am not concerned about the icla or not I am more concerned about the fact that patches sent offline and not through Jira. I mean, why ? On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). regards, Martin On 8/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there! I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: One clarification: For external contributions, a jira-issue definitelymakes sense.A behavior that both the Struts and Shale communities have adopted (albeit recently in the case of Shale :-) is to have a JIRA issue for pretty much any non-trivial change to the codebase. It's not necessarily that committers need to flow their proposed commits through attachments to those issues; it's more about being able to associate a commit with a particular issue (simply done by putting the appropriate MYFACES-x issue number somewhere in the text, and JIRA will notice that and add the commit log to the history of the issue). Whoever is release manager, and therefore is responsible for assembling the release notes, might actually get persuaded to do it for more than one release if this habit is followed, because JIRA will very nicely accumulate all the issues that have been tagged to be fixed in that release. Separately, I think there's a couple of lessons here for how Apache projects interact with Google Summer of Code participants:* Get the participants to sign an iCLA early on, so that their ultimate contributions won't have to go through a bunch of bureaucratic red tape at the last minute.* Develop a mini-guide to what is expected of GSoC code contributions (such as the license headers, setting up SVN properties correctly, and the like). * Make sure that new committers clearly understand the rules too.Regarding sandbox code, I can sympathize with Mario's point that this is somehow different than regular commits. BUT ... even sandbox project commits are done with an ultimate goal in mind. Even if it's an omnibus issue like add partial page refresh support to Tomahawk, it will help improve the overall discipline if we deal with sandbox commits according to the same process requirements as everything else. After all, the rest of the world might not understand the subtle differences that we (knowledgeable participants in the process) might take for granted. regards,MartinCraig On 8/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: I really don't see the necessity for MyFaces committers to do all extensions of MyFaces through jira, if sufficient communication has happened on the developer list first. Why do you think that opening a jira-issue and adding patches will make us more efficient in the development process? regards, Martin On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: what about using Jira first. for almost all commits ? I mean this makes us more efficent to follow the development process ;) So each change to API, non trivial enhancement, etc must! go through jira. WDYT ? -Matthias On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am not concerned about the icla or not I am more concerned about the fact that patches sent offline and not through Jira. I mean, why ? On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote:For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). regards, Martin On 8/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there!I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development andCourses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces--http://www.irian.at Your JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
