myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Lessard" <>
Subject Re: JSF2.0 implementation
Date Thu, 28 Aug 2008 14:24:13 GMT
Hi Simon,

On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <>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 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.

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

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

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.


~ Simon

> Regards,
> Simon

View raw message