river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Apache River Roadmap
Date Mon, 12 Feb 2007 12:21:30 GMT
Mark Brouwer wrote:
> Dan Creswell wrote:
> 
>>> Also I refuse to let my need for features I require be based on how the
>>> outside world thinks of it. I can only hope it will be appreciated but
>>> that is not my main motivation for contributing here.
>>>
>>
>> Can you clarify that statement please?  From at least one viewpoint,
>> you've just said "I'm only interested in playing with my Jini and I
>> don't care what anyone else thinks".
> 
> I think I said or at least I meant to say was that my requirements for
> enhancements to the Jini technology are a function of my work with Jini
> and that my need is not a function of how this is going to be perceived
> by the larger outside world.
> 
> So if I want a change in PreferredClassLoader to solve a failure
> scenario but it doesn't qualify as a high sex-appeal feature on the
> changelist or won't make headlines then that doesn't matter to me, nor
> do I think it should. The right to propose and discuss that change here
> is important to me, regardless of whether it is going to make Jini more
> relevant to the world in the eyes of most. The process here at the ASF
> will ensure that people involved in the project will have their say
> based on (technical) merit and as such their opinion really matters to
> me, don't get that wrong. But I should not need to apply a 'relevance
> filter' on any of my thoughts before bringing it to the list here. I can
> live though with an answer "Not now, for it doesn't fit our roadmap, so
> please do it in your own copy of the code.".
> 
>>>> The kinds of minutae (e.g. PreferredClassLoader changes) we've talked
>>>> about thus far will not address any of these problems.  If River is not
>>> I would appreciate it if you stop labeling these discussions as being
>>> about minutiae. The last thing we need IMHO is people backing of
>>> discussion about code because it might not fit someones definition of
>>> relevance.
>>>
>>
>> I will not stop labelling it as such because I see no point in messing
>> around with this stuff unless there's a bigger context driving it.  And
>> for me at least that bigger context needs to be about a lot more than
>> just "it fixes a bug" or "it makes the code nicer" or "it makes the code
>> more perfect" etc.
> 
> I think in a collaborative project there is one thing that is very
> important: "respectful, honest, technical-based interaction".
>

Have to refine that some:

"respectful, honest, interaction"

Doesn't have to be (and IMHO shouldn't be just) technical-based
interaction because it's not just about technical issues (at least for
me) as I've been hinting.

> I have no problem with you saying "Maybe it is good idea to decide what
> we are going to do in the bigger context here as that would help a lot
> in going forward.", but your message to the participants on the list was
> "The river-dev list is full of minutae - discussion of coding standards,
> issues on nitty gritty bits of behaviour around locking or
> preferred-lists or when we might get the code drop or testing or
> checkins. But, I don't care about any of this stuff, why? Because it's
> irrelevant."
> 
> It is probably just me being overly sensitive to these kind or words,
> but I have problems seeing this and other remarks in "Drowning in the
> River" as paying respect to your fellow people here. They were certainly
> honest ;-) and your intentions were good I presume, but to me it didn't
> feel good.
> 

Not intending to offend at all - I simply needed to cite some examples
of the kind of stuff I was pointing a finger at otherwise there's no
context for discussion.

>> Maybe I do and maybe I'll get to talking about them one day but I'm much
>> more interested in hearing the "community view", people like Mike or
>> Sean for example and forming a roadmap from that.
>>
>> In absence of such feedback and if there's general interest from other
>> committers I will consider putting them forward.  Otherwise, I will
>> assume the project wants to focus on the kind of things you've put
>> forward in which case I will execute on my ideas elsewhere.
> 
> Dan isn't this project a summation of what people want to do and where
> they want to put their effort in? Maybe the things I want to focus on
> are not the things you or any of the other committers want to focus on,
> but that doesn't mean there is a problem or conflict by definition.
> 

Ah, but I think there is a conflict - as I keep saying (and I see no
consideration from you thus far):

River rightly or wrongly is viewed as being the public face of Jini and
we know that the starter kit/core dev is not a good public face.

That's not a problem so long as we as a group have a strategy for
pushing attention away from River to somewhere else that can be the
public face.

Thus far I see no one willing to discuss that issue.  I see plenty of
other stuff being kicked around but no addressing of this key issue
which IMHO will kill us unless we deal with it.  If we don't deal with
it we will confuse the audience.  Potential developers won't know where
to go nor will potential users.

You want to go one way and I have no problem with you going that way but
 I would like to know if you've spent some time thinking about the cost
of your choices (like what it does to the River image) and whether you
are prepared to help others work around those costs.

> You make it sound that I've decided what the project should or should
> not look like, I hope my postings should have made clear that I don't
> exactly know where the border is, where it should be or which way we

Personally, I'm not sure they have made that clear but thanks, now I get it.

> should go. A lot of that will be determined by those who bring in ideas
> and can back that up with time, therefore I find it strange that while
> you have ideas we have to keep asking for it. By showing your ideas, we
> can see whether we have a problem and if there appears to be a problem
> we can try to solve it.

After a number of years of participation, this is how I see much of the
Jini community - no offence is intended to anyone......

The Jini community is a high-friction community with a capacity for
endless debate that leads nowhere.  It has a tendency towards debating
the theoretical in an attempt to divine some perfect solution in the
absence of any real-world data.  It complains it gets little recognition
but does little to earn it.  It complains that nothing changes whilst
all the time arguing for everything to stay as it is.

Given I feel this way, why on earth would I communicate my ideas? It's
going to cost me too much and give me too little.  I'm looking to see if
River is going to change anything.  Thus far, it seems not and if that's
the case I'd rather put my energy elsewhere.

I want a Jini that is adopted broadly, takes the "art" a step forward
and yes, earns me a reasonable living.  I believe Jini would need to be
responding to users and real-world needs and whilst it would feature my
own innovations, those too would be aimed at the real-world.  I have a
collection of ideas on what those real-world needs are based on my
experience with building Jini systems in the enterprise.

I can certainly do this in a project or product outside of River as can
others but we need for River to support us in this if only by giving
crystal clarity to it's own mission which it has yet to do and seems
largely unconcerned about.

If River does not do this and it follows your favoured path all those
projects based on what's done here at River will likely be rendered
invisible, and die which will not be good for your grand vision a la
Linux kernel.

I hope this is clearer in some way,

Dan.

Mime
View raw message