imho there needs to be an orchestrated collaboration b/n:
1. mp, rob and andrea wrt a number of similar widgets
2. mp and jason on style
3. george & ash on gwt/spring
4. mp & ash on splitter (duplicate functionality - different designs)
5. rob & ash on pngimage (duplicate functionality - different designs)
6. jason & ash on effects
7. anyone + ash on (google themed widgets)
8. (sub-team) on core/jre
mp, rob:
u guys and your lack of commits in the sandbox are a concern for me.
clearly there is something blocking u both even from committing the
most basic of contributions. please make the effort to migrate one
widget at a time, if you still struggle then raise the issues so we try
and resolve them and progress.
rgds ash
http://www,gworks.com.au
The difficulty for me is that I am already trying to manage 2
full-time jobs plus be a father. I will contribute what I can, and I
fully support this project, but I have almost no free time right now
unless I start not sleeping.
Rob
So i decided to contribute with some code I've been working or code
that I needed to my currently development. So feel free to drop any
code I uploaded if you think there is an earlier and/or better
implementation.
I think we should discuss how we are going to collaborate and what
will be our priorities and what rules should be followed. The real
question is: Are we ready to gave up some of our programming styles
and adopt what the group decide? As an example take the name space
discussion you had this week. There was no decision about it. Another
example, should we use tabed/3 spaced/4 spaced indentation? Another
one, should we jump in to Java5 or stick to 1.4 ? Are we going to vote
about those things, and more important, who will have the wright to
vote!
Regards,
Andre
On 12/1/06, ash <ash...@gmail.com> wrote:
>
What Ash has mentioned in his post is what I believe should happen
first before we attempt to throw everything in and attempt to make
sense of it.
We have a lot of features & duplication and need to make sense of it
before we attempt to pull out the good bits. By not self examining and
being critical of each and every bit we will end up accepting
incomplete or crap. Stuff without demos/tests falls into the former
category.
Lets start...
Ive spent most of today getting some kool done.
WebMode(pure javascript) stacktraces/ aka Throwable.getStackTrace() ->
returns real StackTraceElements and not an empty StackTraceElement()
array.
After all that works i need to create Throwable.fieldserializers or at
least StackTrace Field serializers.
sorry about the delayed response, there is a lot going on at this time
of year.
Robert Hanson wrote:
> The difficulty for me is ...
thx for sharing this. i sympathize with and share your situation.
i was actually concerned that you may be blocked more by specific
issues related to the commons iniitiative. doing all that u can manage
is the best all of us can hope of each other.
---
mP,
unlike robs situation, i suspect various forces related to commons is
blocking you. there is no doubt in my mind that you at this current
point in time have the most time, energy and motivation. pls help us
channel this energy most effectively to benefit this initiative.
i committed and did as much as i could in the early stages knowing that
as christmas approaches my ability to contribute diminishes due to
family obligations (i got 2 kids). i also have some planned vacation in
the new year.
mP, pls share u thoughts...
rgds ash
http://www.gworks.com.au
I think i said it before but we should not be accepting anything
without accompanying tests. There are too many components that dont
have tests in the sandbox.
mP wrote:
> I believe the mistake is we have created the sandbox and just dropped
> stuff there without planning and some quality control. I notice a lot
that was actually the purpose of the sandbox. there shouldnt be any
quality control on something i am brainstorming and working through. i
can collaborate and evolve an idea without affecting the commons trunk.
these are private branches.
> of classes are missing tests. I know the sandbox is easy but it skips
> the important question should X be included or not. I realise that its
its good that u bring this up. this begs the question - "what are the
requirements for commons?". this is actually a difficult question b/c
we all see different requirements. mP recently would not have invested
so much effort into stack traces in web mode if he didnt have a
requirement.
however, my preference is to start with a reference. i declared that
gwt-petstore be the reference example. the petstore can take advantage
of many of the assets we have collectively created, incl mP's recent
comet impl, jasons mods to effects etc. clearly we should not be
limited with just have one reference example, there can be several of
them to exercise specific patterns & practices that we endorse.
therefore, i assert it is the reference applications that dictates what
should be in or out of our initial release to get us started.
> hard to coordinate so that everyone gets round to having a discussion
> about whatever. But i am not convinced there is any other way.
talent within this group is one thing. cohesion within this team is
another story. i know that collaboration is currently difficult but i
am reminded of jason frieds mantra of "embrace constraints".
hence, if having a discussion about this stuff is what is needed, then
lets find a way to do it.
> I think i said it before but we should not be accepting anything
> without accompanying tests. There are too many components that dont
> have tests in the sandbox.
yes, this is true mP, there are bugger all test-cases in my stuff. im
guilty as charged. but understand that i am motivated by different
software engineering methods than you. however, rather than debate our
conflict in engineering methods, why not instead collaborate with me to
address the void.
rgds ash
http://www.gworks.com.au
This has nothing to do with how we go about doing things, but without
tests / doco how is anyone but the original author supposed to figure
anything out ? It becomes a very costly exercise to have many ppl
analysing / testing that have the author do half the work (tests/demos)
once.