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 <[EMAIL PROTECTED]> 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 <[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 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
