Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 43152 invoked from network); 23 Aug 2006 11:42:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 Aug 2006 11:42:15 -0000 Received: (qmail 42543 invoked by uid 500); 23 Aug 2006 11:42:13 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 42490 invoked by uid 500); 23 Aug 2006 11:42:13 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 42479 invoked by uid 99); 23 Aug 2006 11:42:13 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Aug 2006 04:42:13 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of cagatay.civici@gmail.com designates 64.233.166.177 as permitted sender) Received: from [64.233.166.177] (HELO py-out-1112.google.com) (64.233.166.177) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Aug 2006 04:42:06 -0700 Received: by py-out-1112.google.com with SMTP id i75so141277pye for ; Wed, 23 Aug 2006 04:41:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=S72bC/6MPpDzc7Um779vn6jhm6PMEd0ogJGPcE5ppmKZN5FPiu+dZxNzefqTKw9r/QCoAC3/seNmcFIsi3LOIrksxLM4wVW9j3U6eOVSJEO6+PjoS9BiVWO4xu1KythKoP2hPtDL8EQ3F0GBETjCGupeovkIkOdYkHLgEBqXVZw= Received: by 10.35.127.7 with SMTP id e7mr379737pyn; Wed, 23 Aug 2006 04:41:45 -0700 (PDT) Received: by 10.35.118.9 with HTTP; Wed, 23 Aug 2006 04:41:44 -0700 (PDT) Message-ID: <8c9d4eaa0608230441u1de1d3d4u88a747c846b9922b@mail.gmail.com> Date: Wed, 23 Aug 2006 14:41:45 +0300 From: "Cagatay Civici" To: "MyFaces Development" Subject: Re: Partial Page Rendering for tomahawk In-Reply-To: <71235db40608222303n6aba5bd9l76497cd827ec75b3@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_121758_20867481.1156333305060" References: <6dda0b150608221359m110e88bagc2b633c27ef60693@mail.gmail.com> <5a99335f0608221546r30bbbcf9o720f27453a89bef@mail.gmail.com> <71235db40608221551s135def79o24433afa9ca9dabb@mail.gmail.com> <71235db40608221841p7cdcb595jac6b375e1785fa05@mail.gmail.com> <44EBD916.3030704@ops.co.at> <71235db40608222147w5ff17e3an2aee192f199a0623@mail.gmail.com> <5a99335f0608222209s43744714xffb0b6eff1d56c81@mail.gmail.com> <71235db40608222303n6aba5bd9l76497cd827ec75b3@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_121758_20867481.1156333305060 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, 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. 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. Cagatay On 8/23/06, Matthias Wessendorf wrote: > > Martin, > > glad to hear that you are concerned about that too. > We should ensure for the future, that the new developers understand > how the ASF works and that they should consult the the list, in case > of ... ;) > > I fixed the svn props and build now the code > for 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 ;) > > -Matthias > > On 8/22/06, Martin Marinschek 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 wrote: > > > On 8/22/06, Mario Ivankovits 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 > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://jroller.com/page/mwessendorf > mail: mwessendorf-at-gmail-dot-com > ------=_Part_121758_20867481.1156333305060 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

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.

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

On 8/23/06, Matthias Wessendorf <matzew@apache.org> wrote:
Martin,

glad to hear that you are concerned about that too.
We should ensure for the future, that the new developers understand
how the ASF works and that they should consult the the list, in case
of  ... ;)

I fixed the svn props and build now the code
for 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 ;)

-Matthias

On 8/22/06, Martin Marinschek <martin.marinschek@gmail.com> 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 <matzew@apache.org> wrote:
> > On 8/22/06, Mario Ivankovits < mario@ops.co.at> 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
>


--
Matthias Wessendorf

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

------=_Part_121758_20867481.1156333305060--