[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ormf-dev] The way forward
|
Hi Achim, Joel,
after some thoughts I must admit, the original idea of going into the
architecture directly was too demanding.
Currently I am painfully reminded of the fact that I also must earn a
living, which costs me more hours a day than expected, so Achim's
remarks on team availability are perfectly justified.
Given the fact, that most team members have never met (or even
seen/talked to/etc.) each other, Joel's approach is probably the only
one feasible.
I for myself will check out Useme and start getting familiar with the
concept and the code, ready to be tasked by Joel with whatever seems
appropriate. As an aside, I am also digging into the details of
EclipseLink, which Joel proposed for persistency in ORMF.
Kind regards,
Wolfgang
Joel Rosi-Schwartz schrieb:
I agree totally about the lack of team and frankly B. and I have got
to the point that we don't much care; the team will either come
together and contribute or we will move forward at the [snails;-] pace
that we are able. Your support is very much appreciated and we
certainly hope that it will continue whether or not the rest of the
team decides to come to the party or not.
That said, B. and I have decided to move forward with the
reengineering. We can see no good reason to do a hand holding exercise
that costs yet another two months. We simply do not believe that is
going to be the difference of people getting on board or not.
Franks enough :-)
Cheers,
Joel
On 26 Aug 2008, at 08:01, Achim Loerke wrote:
Hi all,
I'd like to clarify my position on the work ahead. I have to
distinguish between to opinions, both my own:
a) What would be the best from a technical point of view? Of course
we should go for the necessary changes and work on an improved
architecture. We should replace all sub-optimal components and create
the greatest tool/API ever.
b) What will work? I've once told Joel not to be polite when clear
words are needed, so I will do it myself: I don't think there is a
team yet. B. and Joel have done a great amount of work, I myself have
contributed some time, Wolfgang has shared some thoughts. That's it,
no other participation I have noticed. From my experience a group of
people working together in the same location need a few weeks to form
a "team". Since most of us haven't met in person I thing it will take
some more time before we should approach some big challenges. I would
invest a month or two on "wasted development" to get the team working
and to get to know the initial ORMF contribution (a.k.a. Useme).
As an alternative B. and Joel (as the only ones with an in-depth
knowledge of ORMF) could make some proposals and the rest of us could
work out the details and start the implementation. This would place a
great burden on our Etish committers who also have to earn a living.
I can certainly live with (and actually like) the approach favored by
B., Joel and Wolfgang. I just don't believe it will work with the
amount of commitment shown by the team so far.
Achim
P.S.: I think the above is also a rational for my proposal of
replacing Jaxen instead of going for EMF. I'd love to do the latter
but I'm not sure if we would ever reach this goal.
Joel Rosi-Schwartz wrote:
We do not have unanimous agreement on the direction forward.
Barbara, Wolfgang and I are of the opinion that we should dive in
and create the long term architecture immediately. Achim is for the
more gradual approach of first completing Useme "as is" then taking
on a gradual re-engineering. Ben and Vasile have not expressed
opinions. Under normal circumstances I would be tempted to simply
call for a vote, but there are two good reasons that I would prefer
if we could discuss this out until we have everyone in agreement:
1. There are good sound reasons (arguments) for both approaches
and I think that all of us have come to our conclusions after
pondering the pros and cons.
2. This decision will obviously drive the deliverables for the
project for the foreseeable future, so it will have a
significant overall impact. I do not think we need to
reiterate all of the points here. I do want to state, though, that
we really do understand Achim's point /For the time being I'd
prefer that we start doing minor tasks until
a "real team" is established. I'd like to see some initial version
in the SVN repository. We should start making this version work (by
replacing invalid parts and fixing bugs). This should train the team
using distributed development tools and methods and to know each
others strength and weaknesses./
We simply do not believe that there is any long term value in doing
that work. Wolfgang's remark to the extent that the community is
unlikely to spend any time looking at (no less really using) a tool
that will not be supported in the near future is accurate. So what
does the project gain from releasing this? I would like to point out
the even the ORMF team has not seen the value in exercising Useme.
The smallest hurdle of having to install another JRE stopped
everyone :-( We also have had several other interested parties who
requested access, but as soon as they understood it would not be
released "as-is" their interest dissipated and they never tried it.
I am anxious to get out a minimal release based on an architecture
that will evolve.
Achim, I am also curious as to to why you changed you mind about
Jaxen vs. EMF. At first you stated "switch to EMF (which I would
prefer)", but now you seem to have turned 180. We look forward to
everyone's thoughts and comments.
All the best,
B. & me
------------------------------------------------------------------------
_______________________________________________
ormf-dev mailing list
ormf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ormf-dev
--
BREDEX GmbH
Mauernstr. 33
38100 Braunschweig
Tel.: +49-531-24330-0
Fax: +49-531-24330-99
http: www.bredex.de
Geschäftsführer: Hans-J. Brede, Achim Lörke, Ulrich Obst
Amtsgericht Braunschweig HRB 2450
<Achim_Loerke.vcf>_______________________________________________
ormf-dev mailing list
ormf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ormf-dev
_______________________________________________
ormf-dev mailing list
ormf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ormf-dev
