You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Jim Hurley <Ji...@Sun.COM> on 2007/01/31 06:54:15 UTC
thoughts on River project organization...
Hi all-
We've had a lot of good discussion on the list over
the past month, but things haven't progressed as
much as I think they could have. That's certainly just
partly due to the nature of starting up a new project
in a new space (for some of us), as well as not
having the contributed block of code from the Starter
Kit, Service UI, and testing in the project yet. It also seems
to me, though, that some organization around the
project could help us focus and make some good
progress.
To that end, I've gone back through the ~200 list
messages, and tried to pull out a main list of topics.
Would it help to have this on a wiki to help us track?
If ya'll think this (organization) is a good idea -- I'd
like to agree on the initial list, where to put it, and
how best to attack it. Let me know what you think.
thanks -Jim
---------------------------------------------------------
Here are some of the topics/issues that have been
raised:
River-dev:
1) Accepting main initial contributions:
- Service UI code (vote needed?)
- Starter Kit code
- test code
2) Overall vision/characterization and goals of the project
- Continuation of what's been done, new
stuff, something else? If new stuff, expansion
of core (horizontal) or vertical?
- short term (e.g., plug replacable with existing release?
compatibility?) and longer term goals
- split the project in various pieces?
- define a platform?
- spec (in)compatibility goals
- deliverables? repackage? separate releases/distributions?
different services? core?
- how does Service UI fit in?
- still developing a "Starter Kit"?
3) Need TODO areas
- "I want to help in River, what do I do?"
4) Roadmap
- which version of J2SE?
- when to convert com.sun.jini to org.apache.river namespace
- support for "Jini across the firewall"
- replacement (if any) for the starterkit installer
- at what point do we force developers to change their
existing scripts (e.g., com.sun.jini.start, config files,
policy files)
- "Subcomponents"? Organizing the code repository and site
For separate releases, etc
- what kind of releases? and when?
5) Project organization and process guidelines/standards
- formation of PPMC?
- how to accept new committers?
- committers vs. non-committers?
- monthly incubator status reports
- status file <http://incubator.apache.org/projects/river.html>
page updates?
6) JIRA
- use of JIRA (for everything, for only 'significant' things)?
- use JIRA for site updates?
- defining the JIRA components (website/infrastructure/
contributions/serviceui/jtsk?) (java package names?)
- move bugs from Sun db over?
7) Javadoc / Specs / Documentation
- how/where host (Javadoc/specs/doc)
8) Testing
- what's needed/required?
- how to establish automated test execution?
9) Misc
- <http://incubator.apache.org/river/> page updates?
- project logo?
------------------------------------------------------------------------
--
Re: thoughts on River project organization...
Posted by Sean Landis <se...@gmail.com>.
I can't resist jumping into the WS wars :-)
First I should say that I use the style the company that signs my
checks tells me to. I am informed that the rulebook is "The Elements
of Java Style." Those sage purveyors of infinite wisdom chose their
very first code-specific topic to be indentation (there were 4
previous topics related to general issues). They recommend 2 SPACES
and so that's how my IDE is configured.
Personally, I prefer spaces to tabs as they lead to fewer surprises.
If I owned this company, I'd say 4 spaces, but I don't. Instead I
follow the rulebook. (Well, almost. I can't abide using a newline
after a "}" to start a catch or else block. A programmer has to draw
the line somewhere! :-)
Sean
Re: thoughts on River project organization...
Posted by Gregg Wonderly <ge...@cox.net>.
Dan Creswell wrote:
> I certainly suffer from the problem but in the most part, especially if
> I'm just reviewing, I'll use a code beautifier.
Since I use perforce for my SCM, all of these sources are read only, in my tree.
The IDE won't let me do anything to the file, without removing the readonly
attribute (by checking it out for edit or otherwise). This creates issues
because I then have to more thoroughly review what I am submitting to make sure
that I didn't beautify something and then edit it inadvertently.
This is mostly about the level of pain that I deal with, and thus, I'm just
whinning a bit, but also trying to suggest that something "better" probably
could be achieved.
Gregg Wonderly
Re: thoughts on River project organization...
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Gregg Wonderly wrote:
> Jim Hurley wrote:
>> If ya'll think this (organization) is a good idea -- I'd
>> like to agree on the initial list, where to put it, and
>> how best to attack it. Let me know what you think.
>
> One issue that I'd like to bring up, but which may create a lot of
> disagreement is the whitespace usage in the JTSK sources. I'd like, at
> some point, for all lines of code to have leading tabs only. Everyone
> seems to like different whitespace/columns for indentation and tabs only
> seems to provide the most flexability. It means that diffs have to be
> generated with -b, or in some way which removes whitespace from
> consideration for any updates people submit between the old code and
> their current code.
>
> Am I just retentive about this issue, or does anyone else have some
> problems poping the source up in an editor/ide with something besides 8
> char tabs?
>
> Gregg Wonderly
>
Hmmmm,
I certainly suffer from the problem but in the most part, especially if
I'm just reviewing, I'll use a code beautifier.
However, the Linux kernel certainly has a standard for this stuff and
that might be indicative of a need to satisfy a need ;)
Dan.
Re: thoughts on River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Bill Venners wrote:
> Hi Gregg,
>
> You realize of course this means war. I'm all for a style standard, so
> long as it is 4 *spaces* for each level of indentation.
I found the tab is 8 spaces and indentation level is 4 spaces indeed
hard to work with, especially when peeking into the source code when
you have a different number of spaces for your tab.
Although it requires tremendous thinking at some times we should keep
the 80 characters limit, which means people have to work with a fixed
'tab' size anyway.
> Actually, I usually have no problem adapting to whatever the style is of
> the project I'm working on.
Agreed, although the thing I would hate to see is a large numbers of
diffs just as result tab preferences. I have no problem replacing the
tabs in the JTSK code by 8 real spaces and continue with the 4 spaces
indentation, it will keep the formatting the same and will result in
less confusion for there are no tabs anymore. I will have to learn
working with the home key for navigation instead of using the cursor
keys but I think I can adapt to that.
--
Mark
Re: thoughts on River project organization...
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Gregg:
I'm with Bill on this one; also with Tor from JavaPosse.
http://blogs.sun.com/tor/entry/code_advice_3_no_tabs
Greg.
On Wed, 2007-01-31 at 23:13, Bill Venners wrote:
> Hi Gregg,
>
> You realize of course this means war. I'm all for a style standard,
> so long as it is 4 *spaces* for each level of indentation.
>
> Actually, I usually have no problem adapting to whatever the style is
> of the project I'm working on, but at home, at Artima, we use four
> spaces to indent Java.
>
> Bill
>
> On Jan 31, 2007, at 7:43 PM, Gregg Wonderly wrote:
>
> > Jim Hurley wrote:
> >> If ya'll think this (organization) is a good idea -- I'd
> >> like to agree on the initial list, where to put it, and
> >> how best to attack it. Let me know what you think.
> >
> > One issue that I'd like to bring up, but which may create a lot of
> > disagreement is the whitespace usage in the JTSK sources. I'd
> > like, at some point, for all lines of code to have leading tabs
> > only. Everyone seems to like different whitespace/columns for
> > indentation and tabs only seems to provide the most flexability.
> > It means that diffs have to be generated with -b, or in some way
> > which removes whitespace from consideration for any updates people
> > submit between the old code and their current code.
> >
> > Am I just retentive about this issue, or does anyone else have some
> > problems poping the source up in an editor/ide with something
> > besides 8 char tabs?
> >
> > Gregg Wonderly
> >
>
Re: thoughts on River project organization...
Posted by Gregg Wonderly <gr...@wonderly.org>.
Bill Venners wrote:
> Hi Gregg,
>
> You realize of course this means war. I'm all for a style standard, so
> long as it is 4 *spaces* for each level of indentation.
>
> Actually, I usually have no problem adapting to whatever the style is
> of the project I'm working on, but at home, at Artima, we use four
> spaces to indent Java.
War it is :-) I've always used tabs because that was the recommended style that
I learned at college from someone who as involved in a multi-content open source
project with 10 or so contributors. Some liked 4 char spacing, some 3 or even
2. So if everyone used tabs, then they could configure their editor to expand
to what made sense.
I could live with all spaces, but the JTSK source is mixed with lines of all
spaces, all tabs and mixed spaces and tabs. So it's difficult to look at unless
you reconfigure you editor to use 8 char expansion of tabs. It's been a long
time since I've encountered sources with this kind of indentation, so it really
surprised me, and to some degree it's not a big deal, but I am compelled to
realign the indentation so that I can read it with 4 char tabstops, rather than
change all of the settings on the IDE as I switch between JTSK source and my
sources while debugging or developing.
I don't really want to turn this into a big ordeal, I just think that if there
is some agreement, doing this sometime soon would create a much easier to work
with source base, especially for code trollers like me.
Gregg Wonderly
Re: thoughts on River tabs organization...
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
+1
On Feb 1, 2007, at 1:52 AM, Craig L Russell wrote:
> I've been through these wars a number of times and it seems that
> tabs just get in the way of productivity. If you want everything to
> look good and indent 4 spaces, then the usual tab 8 doesn't work,
> even though that's the standard tab. And then you end up with a
> mixture of tabs and spaces in each file, so everyone changes to 4
> space tabs but then people with no tab settings in their editor see
> that there is no spacing at all and put in 4 tabs thinking that
> this will fix things and then no one is happy.
>
> I think 4 space indentation and no tabs seems to be a universal
> solvent. At least very few people object strongly to it.
>
> Craig
>
> On Jan 31, 2007, at 8:13 PM, Bill Venners wrote:
>
>> Hi Gregg,
>>
>> You realize of course this means war. I'm all for a style
>> standard, so long as it is 4 *spaces* for each level of indentation.
>>
>> Actually, I usually have no problem adapting to whatever the style
>> is of the project I'm working on, but at home, at Artima, we use
>> four spaces to indent Java.
>>
>> Bill
>>
>> On Jan 31, 2007, at 7:43 PM, Gregg Wonderly wrote:
>>
>>> Jim Hurley wrote:
>>>> If ya'll think this (organization) is a good idea -- I'd
>>>> like to agree on the initial list, where to put it, and
>>>> how best to attack it. Let me know what you think.
>>>
>>> One issue that I'd like to bring up, but which may create a lot
>>> of disagreement is the whitespace usage in the JTSK sources. I'd
>>> like, at some point, for all lines of code to have leading tabs
>>> only. Everyone seems to like different whitespace/columns for
>>> indentation and tabs only seems to provide the most flexability.
>>> It means that diffs have to be generated with -b, or in some way
>>> which removes whitespace from consideration for any updates
>>> people submit between the old code and their current code.
>>>
>>> Am I just retentive about this issue, or does anyone else have
>>> some problems poping the source up in an editor/ide with
>>> something besides 8 char tabs?
>>>
>>> Gregg Wonderly
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: thoughts on River tabs organization...
Posted by Craig L Russell <Cr...@Sun.COM>.
I've been through these wars a number of times and it seems that tabs
just get in the way of productivity. If you want everything to look
good and indent 4 spaces, then the usual tab 8 doesn't work, even
though that's the standard tab. And then you end up with a mixture of
tabs and spaces in each file, so everyone changes to 4 space tabs but
then people with no tab settings in their editor see that there is no
spacing at all and put in 4 tabs thinking that this will fix things
and then no one is happy.
I think 4 space indentation and no tabs seems to be a universal
solvent. At least very few people object strongly to it.
Craig
On Jan 31, 2007, at 8:13 PM, Bill Venners wrote:
> Hi Gregg,
>
> You realize of course this means war. I'm all for a style standard,
> so long as it is 4 *spaces* for each level of indentation.
>
> Actually, I usually have no problem adapting to whatever the style
> is of the project I'm working on, but at home, at Artima, we use
> four spaces to indent Java.
>
> Bill
>
> On Jan 31, 2007, at 7:43 PM, Gregg Wonderly wrote:
>
>> Jim Hurley wrote:
>>> If ya'll think this (organization) is a good idea -- I'd
>>> like to agree on the initial list, where to put it, and
>>> how best to attack it. Let me know what you think.
>>
>> One issue that I'd like to bring up, but which may create a lot of
>> disagreement is the whitespace usage in the JTSK sources. I'd
>> like, at some point, for all lines of code to have leading tabs
>> only. Everyone seems to like different whitespace/columns for
>> indentation and tabs only seems to provide the most flexability.
>> It means that diffs have to be generated with -b, or in some way
>> which removes whitespace from consideration for any updates people
>> submit between the old code and their current code.
>>
>> Am I just retentive about this issue, or does anyone else have
>> some problems poping the source up in an editor/ide with something
>> besides 8 char tabs?
>>
>> Gregg Wonderly
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: thoughts on River project organization...
Posted by Bill Venners <bv...@artima.com>.
Hi Gregg,
You realize of course this means war. I'm all for a style standard,
so long as it is 4 *spaces* for each level of indentation.
Actually, I usually have no problem adapting to whatever the style is
of the project I'm working on, but at home, at Artima, we use four
spaces to indent Java.
Bill
On Jan 31, 2007, at 7:43 PM, Gregg Wonderly wrote:
> Jim Hurley wrote:
>> If ya'll think this (organization) is a good idea -- I'd
>> like to agree on the initial list, where to put it, and
>> how best to attack it. Let me know what you think.
>
> One issue that I'd like to bring up, but which may create a lot of
> disagreement is the whitespace usage in the JTSK sources. I'd
> like, at some point, for all lines of code to have leading tabs
> only. Everyone seems to like different whitespace/columns for
> indentation and tabs only seems to provide the most flexability.
> It means that diffs have to be generated with -b, or in some way
> which removes whitespace from consideration for any updates people
> submit between the old code and their current code.
>
> Am I just retentive about this issue, or does anyone else have some
> problems poping the source up in an editor/ide with something
> besides 8 char tabs?
>
> Gregg Wonderly
>
RE: thoughts on River project organization...
Posted by "Rollo, Dan" <DR...@ETS.ORG>.
Just to avoid easy consensus...
I prefer no tabs in source code, as it leads to really variable
indentations depending on one's editor. Having to customize your editor
settings according to the tab size of a given project just to get
If/else brackets to line up is not fun. At least with "no tabs", the
indent formatting is always consistent when opened in any editor.
Dan
-----Original Message-----
From: Jeff Ramsdale [mailto:jeff.ramsdale@gmail.com]
Sent: Monday, February 05, 2007 12:17 AM
To: river-dev@incubator.apache.org
Subject: Re: thoughts on River project organization...
Back when we used typewriters we were told to put two spaces between the
period at the end of one sentence and the first character of the next.
This was in order to add visual separation for readability. With the
advent of desktop computers most people continued to put two spaces even
though this actually removed the software's ability to fully and
accurately manage the distance between that period and the following
character.
Most of us use modern IDEs these days. Regardless of historical
precedent concerning spaces the use of tabs provides greater flexibility
within our tools. It's faster to navigate and allows every user to
display their preferred amount of indentation.
Similarly, 80 column line length is just goofy given screen real-estate
these days. I prefer 120. It's time to update the "standards." That
said, I'll go with the group consensus. :-)
Jeff
On 2/1/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Tabs?
>
> In source?
>
> geir
--------------------------------------------------
This e-mail and any files transmitted with it may contain privileged or confidential information.
It is solely for use by the individual for whom it is intended, even if addressed incorrectly.
If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute,
or take any action in reliance on the contents of this information; and delete it from
your system. Any other use of this e-mail is prohibited.
Thank you for your compliance.
--------------------------------------------------
Re: thoughts on River project organization...
Posted by Calum Shaw-Mackay <ca...@gmail.com>.
Hi all
'First time caller, long time listener......' :)
You can try to enforce code styles such as indentation through
pre-commit hooks in subversion, but this is generally frowned upon, as
ther's no way of getting the reformeted code back to the commiter and
forcing the file to refresh (aka commit and update in the same
operation).
As an aside this could be used for checking for the appropriate
preamble at the top of the file.
Does anyone know if there is a way of moderating commited files for
approval, and as part of this approval, handle the formatting
automatically?
I think the best thing may be get everyone to be fairly happy with the
style, and if someone varies wildly from it, and frown at them evilly
Cheers
--Calum
On 05/02/07, Gregg Wonderly <ge...@cox.net> wrote:
> Mark Brouwer wrote:
> > Jeff Ramsdale wrote:
> >
> >> Similarly, 80 column line length is just goofy given screen
> >> real-estate these days. I prefer 120. It's time to update the
> >> "standards." That said, I'll go with the group consensus. :-)
> >
> >
> > Go wash your mouth Jeff, anybody that performs three-way merges on a
> > regular basis will tell you 80 column width still rulezzzzz.
>
> When I'm doing three way merges, I reformat the affected lines as needed to make
> sense of what is there. Typically though, I don't have too many three way
> merges because we try hard to keep multiple people from working in the same
> areas of files.
>
> When you have to do it though, there are certainly many characteristics of the
> file which create issues for making the merge go fast and correctly.
>
> Gregg Wonderly
>
Re: thoughts on River project organization...
Posted by Gregg Wonderly <ge...@cox.net>.
Mark Brouwer wrote:
> Jeff Ramsdale wrote:
>
>> Similarly, 80 column line length is just goofy given screen
>> real-estate these days. I prefer 120. It's time to update the
>> "standards." That said, I'll go with the group consensus. :-)
>
>
> Go wash your mouth Jeff, anybody that performs three-way merges on a
> regular basis will tell you 80 column width still rulezzzzz.
When I'm doing three way merges, I reformat the affected lines as needed to make
sense of what is there. Typically though, I don't have too many three way
merges because we try hard to keep multiple people from working in the same
areas of files.
When you have to do it though, there are certainly many characteristics of the
file which create issues for making the merge go fast and correctly.
Gregg Wonderly
Re: thoughts on River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Jeff Ramsdale wrote:
> Similarly, 80 column line length is just goofy given screen
> real-estate these days. I prefer 120. It's time to update the
> "standards." That said, I'll go with the group consensus. :-)
Go wash your mouth Jeff, anybody that performs three-way merges on a
regular basis will tell you 80 column width still rulezzzzz.
--
Mark
Re: thoughts on River project organization...
Posted by Jeff Ramsdale <je...@gmail.com>.
Back when we used typewriters we were told to put two spaces between
the period at the end of one sentence and the first character of the
next. This was in order to add visual separation for readability. With
the advent of desktop computers most people continued to put two
spaces even though this actually removed the software's ability to
fully and accurately manage the distance between that period and the
following character.
Most of us use modern IDEs these days. Regardless of historical
precedent concerning spaces the use of tabs provides greater
flexibility within our tools. It's faster to navigate and allows every
user to display their preferred amount of indentation.
Similarly, 80 column line length is just goofy given screen
real-estate these days. I prefer 120. It's time to update the
"standards." That said, I'll go with the group consensus. :-)
Jeff
On 2/1/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Tabs?
>
> In source?
>
> geir
Re: thoughts on River project organization...
Posted by Gregg Wonderly <gr...@wonderly.org>.
Geir Magnusson Jr. wrote:
> Tabs?
>
> In source?
Well, for 20 years I've used tabs only, and worked in organizations, large at
that, where tabs only was the rule so that people could change the indentation
levels. One of the primary reasons, was reduction in disk space because it was
the 5ESS source tree, the largest in the world at that time. Today (and in this
project) total disk consumption is not an issue. I'm not aware of any widely
used editor which can't be configured to do this exactly right. Doing all
spaces, might be the other choice.
I guess it really depends on what you do every day. Everyday, I use tabs only.
It makes it very fast to move from indentation level to indentation level
using the cursor keys (as Mark alluded to).
I won't try and convince everyone that tabs are better. I'll stop here and just
suggest that either all spaces or all tabs would be better than a mixture.
Gregg Wonderly
Re: thoughts on River project organization...
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tabs?
In source?
geir
On Jan 31, 2007, at 10:43 PM, Gregg Wonderly wrote:
> Jim Hurley wrote:
>> If ya'll think this (organization) is a good idea -- I'd
>> like to agree on the initial list, where to put it, and
>> how best to attack it. Let me know what you think.
>
> One issue that I'd like to bring up, but which may create a lot of
> disagreement is the whitespace usage in the JTSK sources. I'd
> like, at some point, for all lines of code to have leading tabs
> only. Everyone seems to like different whitespace/columns for
> indentation and tabs only seems to provide the most flexability.
> It means that diffs have to be generated with -b, or in some way
> which removes whitespace from consideration for any updates people
> submit between the old code and their current code.
>
> Am I just retentive about this issue, or does anyone else have some
> problems poping the source up in an editor/ide with something
> besides 8 char tabs?
>
> Gregg Wonderly
Re: thoughts on River project organization...
Posted by Gregg Wonderly <ge...@cox.net>.
Jim Hurley wrote:
> If ya'll think this (organization) is a good idea -- I'd
> like to agree on the initial list, where to put it, and
> how best to attack it. Let me know what you think.
One issue that I'd like to bring up, but which may create a lot of disagreement
is the whitespace usage in the JTSK sources. I'd like, at some point, for all
lines of code to have leading tabs only. Everyone seems to like different
whitespace/columns for indentation and tabs only seems to provide the most
flexability. It means that diffs have to be generated with -b, or in some way
which removes whitespace from consideration for any updates people submit
between the old code and their current code.
Am I just retentive about this issue, or does anyone else have some problems
poping the source up in an editor/ide with something besides 8 char tabs?
Gregg Wonderly
Re: thoughts on River project organization...
Posted by Bob Scheifler <Bo...@Sun.COM>.
> To that end, I've gone back through the ~200 list
> messages, and tried to pull out a main list of topics.
> Would it help to have this on a wiki to help us track?
Somewhere on the site, yes, thanks. No personal preference as to
wiki vs other.
- Bob
Re: thoughts on River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Fabrizio Giudici wrote:
> For this reason, if "users" above means a restricted group, no problems
> (please forgive my ignorance but it's the first time I follow an
> incubator project). If it means the wolves, I'd be worried about
> "thrashable builds"...
Hi Fabrizio,
From what I understand incubation is all about attracting a developer
community and not a user community and that it is not expected to do a
'public' release while we are in incubation, so a marketing campaign
doesn't seem right. For that reason I also used internal between
brackets when mentioning the release.
I know there is a bunch of patches in Sun since the last public release
that are likely tested by them, so I don't worry these being integrated
and taken through the process if a complete test environment is not in
place.
I can be wrong but I don't think that there is a huge amount of
code waiting to be integrated at day one. And I have confidence that
those who know the test framework and the codebase can and will say "Hey
this is a tricky patch, please hold that one back until the test
framework is up and running.".
But without knowing what is required for hosting the test and in what
time it can be arranged this is all getting a bit hypothetical. So maybe
it would be nice if Nigal's question of January 6th gets answered:
"what hardware to we have available from Apache on which to run builds
and tests? How do other teams handle testing resources?"
Also did he ask "would Sun be willing to continue any testing or offer
hardware resources?"
On which Jim Hurley responded "We (Sun) have some testing/hardware
resources that we could probably contribute (it would be more of a short
term vs. long term thing, though). For example, if we (Apache River)
were to complete some bug fixes/rfes in the near term, Sun might be able
to do some testing to help get out a release. We need to discuss a
workable testing model that will work over the long term, though."
Maybe some others could shed some light on how they want to progress
with regard to this subject.
--
Mark
Re: thoughts on River project organization...
Posted by Fabrizio Giudici <Fa...@tidalwave.it>.
On Feb 1, 2007, at 16:38 , Dan Creswell wrote:
>>
>
> -1
>
> IMHO, we have a strong testing tradition that has lead to quality
> releases. The last thing we need is for an apparent simple first
> release to suffer an attendant reduction in quality.
>
Since we're talking about a user perspective, I take the chance of my
first post here :-)
+1 on Dan's quote.
Let's consider expectations about River. We all said that it's also a
great "marketing opportunity" to attract new attention on Jini. We
all know that one of the problems is that Jini requires a different
mental model, but it pays because it works - I mean, on a blog you
can give a bold answer and say: "ok, maybe it's not easy, but once
you've learnt it you can rely on it."
For this reason, if "users" above means a restricted group, no
problems (please forgive my ignorance but it's the first time I
follow an incubator project). If it means the wolves, I'd be worried
about "thrashable builds"...
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941
Re: thoughts on River project organization...
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Mark Brouwer wrote:
> Dan Creswell wrote:
>
>> -1
>>
>> IMHO, we have a strong testing tradition that has lead to quality
>> releases. The last thing we need is for an apparent simple first
>> release to suffer an attendant reduction in quality.
>
> I think you have misinterpreted my words Dan. Never did I say we should
> produce a release that was not tested. All I said is that I think that
> people should be able to start with working on issues and even checking
> in code in SVN when it takes too long to setup the complete test
> infrastructure.
In which case, I don't think I misunderstood your words at all! :)
If the problem is sorting the testing infrastructure that's where we put
our effort. It's got to be done at some point and the sooner the better.
For me it goes hand in hand with nightly builds and other things to
check that we're not gradually reducing the codebase to a pile of poop.
Linus has battled with this issue many a time, attempting to force
developers to focus on bug-fixing and testing because they'd rather
checkin more code (I'm not accusing you of such bad behaviour).
Dan.
Re: thoughts on River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Dan Creswell wrote:
> -1
>
> IMHO, we have a strong testing tradition that has lead to quality
> releases. The last thing we need is for an apparent simple first
> release to suffer an attendant reduction in quality.
I think you have misinterpreted my words Dan. Never did I say we should
produce a release that was not tested. All I said is that I think that
people should be able to start with working on issues and even checking
in code in SVN when it takes too long to setup the complete test
infrastructure.
--
Mark
Re: thoughts on River project organization...
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Mark Brouwer wrote:
> Brian Murphy wrote:
>> On 1/31/07, Mark Brouwer <ma...@cheiron.org> wrote:
>>
>>> 3) merge ServiceUI and JTSK for the time being so we have one build
>>> process,
>>
>>> 4) work towards an initial (internal) release that in all aspects
>>> compatible with the current JTSK
>>
>>> 5) setup of test infrastructure to validate the outcome of 4
>>
>> For what it's worth, in order to achieve 4) it would seem that
>> doing 5) before 3) might be advisable.
>
> You are right, my mistake, although I had in mind 5) is done in
> parallel with 3) and 4).
>
>> existing and somewhat complete set of tests, along with a harness
>> for running those tests, I would think that it might be desirable
>> to establish a baseline by first getting that mechanism set up
>> and running before combining or modifying the initial codebase.
>
> In case 5) can be done in a timely fashion I agree with you, I'm very
> worried that it won't be the case. I assume/hope a lot of eyes will be
> looking at the modifications that could compensate for the omission of a
> proper test framework for the initial period.
>
-1
IMHO, we have a strong testing tradition that has lead to quality
releases. The last thing we need is for an apparent simple first
release to suffer an attendant reduction in quality.
Unless of course, we want to start doing regular test builds which users
could thrash, we could fix and then produce a final release. But I
suspect this kind of rapid iterating might not fit with being in the
Incubator or other people's mindsets.
> Therefore if 5) can't be arranged in a timely fashion I still think
> we should start with 3) and 4) as the current immobility is rather
> frustrating from my perspective, although if I'm the only one there is
> nothing to worry about.
>
>> That way, when people do start changing the existing code,
>> they'll have a point of reference as well as a mechanism for
>> measuring the quality of their changes.
>
> I agree (and not just to be political correct).
Re: thoughts on River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Brian Murphy wrote:
> On 1/31/07, Mark Brouwer <ma...@cheiron.org> wrote:
>
>> 3) merge ServiceUI and JTSK for the time being so we have one build
>> process,
>
>> 4) work towards an initial (internal) release that in all aspects
>> compatible with the current JTSK
>
>> 5) setup of test infrastructure to validate the outcome of 4
>
> For what it's worth, in order to achieve 4) it would seem that
> doing 5) before 3) might be advisable.
You are right, my mistake, although I had in mind 5) is done in
parallel with 3) and 4).
> existing and somewhat complete set of tests, along with a harness
> for running those tests, I would think that it might be desirable
> to establish a baseline by first getting that mechanism set up
> and running before combining or modifying the initial codebase.
In case 5) can be done in a timely fashion I agree with you, I'm very
worried that it won't be the case. I assume/hope a lot of eyes will be
looking at the modifications that could compensate for the omission of a
proper test framework for the initial period.
Therefore if 5) can't be arranged in a timely fashion I still think
we should start with 3) and 4) as the current immobility is rather
frustrating from my perspective, although if I'm the only one there is
nothing to worry about.
> That way, when people do start changing the existing code,
> they'll have a point of reference as well as a mechanism for
> measuring the quality of their changes.
I agree (and not just to be political correct).
--
Mark
Re: thoughts on River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Brian Murphy wrote:
> I realize some folks are very anxious to start modifying the
> baseline JTSK codebase that was contributed as soon as
> possible; taking it in new directions and/or "fixing" all the
> problems they perceive it to have.
I taste some sentiment in the above and first I thought I'm going to
ignore that, but on second thought I think this is not right. If I'm
wrong this posting is probably stupid, if so please ignore this.
Maybe I'm wrong Brian, but I don't think the general sentiment of those
really willing to help out with this project is that a lot is 'broken'
or that it should be taken a *complete* new direction.
Ok, you hear stories about those awkward public fields in Entries, that
Outrigger is not so good, the JTSK is hard to fire up, etc. etc. and
that the River project is going to make Jini successful in a way that
those suckers at Sun were not able to do. For somebody who worked
tremendously hard on the Jini technology I can imagine this sucks a big
way. I personally don't agree with the sentiment, nor do most of the
others here I guess.
So cheer up and ignore the world, like we Jini people are good at (sorry
couldn't resist the last one :-)
--
Mark
Re: thoughts on River project organization...
Posted by Brian Murphy <bt...@gmail.com>.
On 1/31/07, Mark Brouwer <ma...@cheiron.org> wrote:
> 3) merge ServiceUI and JTSK for the time being so we have one build
> process,
> 4) work towards an initial (internal) release that in all aspects
> compatible with the current JTSK
> 5) setup of test infrastructure to validate the outcome of 4
For what it's worth, in order to achieve 4) it would seem that
doing 5) before 3) might be advisable.
I realize some folks are very anxious to start modifying the
baseline JTSK codebase that was contributed as soon as
possible; taking it in new directions and/or "fixing" all the
problems they perceive it to have. But given that there is an
existing and somewhat complete set of tests, along with a harness
for running those tests, I would think that it might be desirable
to establish a baseline by first getting that mechanism set up
and running before combining or modifying the initial codebase.
That way, when people do start changing the existing code,
they'll have a point of reference as well as a mechanism for
measuring the quality of their changes.
Just my 2 cents (euros?, rubels? ...),
Brian
Re: thoughts on River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> To that end, I've gone back through the ~200 list
> messages, and tried to pull out a main list of topics.
> Would it help to have this on a wiki to help us track?
I have no preference, a simple page with the items and the status would
do for me too, but if you think a Wiki is more handy I'm fine.
> If ya'll think this (organization) is a good idea -- I'd
Organization is a must, even if we do it a bit wrong the first time. We
have mentors that will keep us from screwing up totally I guess.
> like to agree on the initial list, where to put it, and
> how best to attack it. Let me know what you think.
The organizational guidelines (how thin they might be) should be on the
River website where people willing to participate can find them.
As you can see your/our list is rather large and will likely grow in the
future. I think we should pick the most important ones first so people
can start doing what they tend to like and that is coding and discussing
changes.
So I would suggest, get the code and issues in first. Steps required are:
0) policy of how to deal with code changes (as in RIVER-2), also I
think your point 5) should be discussed first;
1) setup of JIRA with components and proper permissions for developers,
at least to the extend it makes sense;
2) we have a group of people that have actual access to SVN, meaning
the ICLA and CCLA are fine and accounts are created;
3) merge ServiceUI and JTSK for the time being so we have one build
process, I agree with Bob that separation complicate things. Although
I hope this agreement only lasts for a few months ;-)
4) work towards an initial (internal) release that in all aspects
compatible with the current JTSK, this means that fixes from Sun
internally could get in as well as improvements lingering around
the world. This would mean we assign issues to a new version and
this allows those willing to participate to pick tasks in a way
that is beneficial to the whole community on the short term;
5) setup of test infrastructure to validate the outcome of 4
It is my expectation working towards an initial release takes at least a
few months, depending on how much improvements we want in it. This buys
us time to sort out the longer term roadmap issues, of which some of
them can have a huge impact. If some of the roadmap issues are tackled
in an early stage we could even start parallel development, although
given the fact SVN has no merge history tracking I'm personally very
reluctant to have any significant development going on in what is
not the trunk branch.
Thanks for picking up the gauntlet Jim!
--
Mark
Re: thoughts on River project organization...
Posted by Nigel Daley <nd...@mac.com>.
On Jan 30, 2007, at 9:54 PM, Jim Hurley wrote:
> Hi all-
>
> We've had a lot of good discussion on the list over
> the past month, but things haven't progressed as
> much as I think they could have. That's certainly just
> partly due to the nature of starting up a new project
> in a new space (for some of us), as well as not
> having the contributed block of code from the Starter
> Kit, Service UI, and testing in the project yet. It also seems
> to me, though, that some organization around the
> project could help us focus and make some good
> progress.
>
> To that end, I've gone back through the ~200 list
> messages, and tried to pull out a main list of topics.
> Would it help to have this on a wiki to help us track?
+1 for wiki
> If ya'll think this (organization) is a good idea -- I'd
> like to agree on the initial list, where to put it, and
> how best to attack it. Let me know what you think.
Thanks for pulling this together, Jim.
Re: getting back to River project organization...
Posted by Jim Hurley <Ji...@Sun.COM>.
On Feb 28, 2007, at 2:46 AM, Mark Brouwer wrote:
> Craig L Russell wrote:
>> Hi Mark,
>> JIRA is mostly self-serve, as opposed to the accounts that need to
>> be set up for committers on people.apache.org and the svn repos.
>> These need special permissions.
>> Everyone can create an account on JIRA. If you don't have
>> sufficient permissions, post to this alias with specific
>> complaints and one of the many JIRA admins can help out. If there
>> is someone with a keen interest in becoming a JIRA admin for the
>> River project let us know that as well, and 'twill be done.
>
> Thanks Craig,
>
> If nobody has a problem with it I'm volunteering to become JIRA admin
> for the River project. I have experience running a JIRA enterprise
> edition myself, so with some help of people who know the ASF
> particulars
> it should work out.
> --
> Mark
+1 (thanks Mark)
-Jim
Re: getting back to River project organization...
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Bob Scheifler wrote:
> Mark Brouwer wrote:
>> If nobody has a problem with it I'm volunteering to become JIRA admin
>> for the River project.
>
> Fine by me, thanks.
>
+1
> - Bob
>
Re: getting back to River project organization...
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> If nobody has a problem with it I'm volunteering to become JIRA admin
> for the River project.
Fine by me, thanks.
- Bob
Re: getting back to River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Craig L Russell wrote:
> Hi Mark,
>
> I've given you jira-administrator privileges. I notice that the River
> project has not really been set up (except for name, rank, and serial
> number ;-)
>
> Have fun.
Thanks.
--
Mark
Re: getting back to River project organization...
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Mark,
I've given you jira-administrator privileges. I notice that the River
project has not really been set up (except for name, rank, and serial
number ;-)
Have fun.
Craig
On Feb 27, 2007, at 11:46 PM, Mark Brouwer wrote:
> Craig L Russell wrote:
>> Hi Mark,
>> JIRA is mostly self-serve, as opposed to the accounts that need to
>> be set up for committers on people.apache.org and the svn repos.
>> These need special permissions.
>> Everyone can create an account on JIRA. If you don't have
>> sufficient permissions, post to this alias with specific
>> complaints and one of the many JIRA admins can help out. If there
>> is someone with a keen interest in becoming a JIRA admin for the
>> River project let us know that as well, and 'twill be done.
>
> Thanks Craig,
>
> If nobody has a problem with it I'm volunteering to become JIRA admin
> for the River project. I have experience running a JIRA enterprise
> edition myself, so with some help of people who know the ASF
> particulars
> it should work out.
> --
> Mark
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: getting back to River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Craig L Russell wrote:
> Hi Mark,
>
> JIRA is mostly self-serve, as opposed to the accounts that need to be
> set up for committers on people.apache.org and the svn repos. These need
> special permissions.
>
> Everyone can create an account on JIRA. If you don't have sufficient
> permissions, post to this alias with specific complaints and one of the
> many JIRA admins can help out. If there is someone with a keen interest
> in becoming a JIRA admin for the River project let us know that as well,
> and 'twill be done.
Thanks Craig,
If nobody has a problem with it I'm volunteering to become JIRA admin
for the River project. I have experience running a JIRA enterprise
edition myself, so with some help of people who know the ASF particulars
it should work out.
--
Mark
Re: getting back to River project organization...
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Mark,
JIRA is mostly self-serve, as opposed to the accounts that need to be
set up for committers on people.apache.org and the svn repos. These
need special permissions.
Everyone can create an account on JIRA. If you don't have sufficient
permissions, post to this alias with specific complaints and one of
the many JIRA admins can help out. If there is someone with a keen
interest in becoming a JIRA admin for the River project let us know
that as well, and 'twill be done.
Craig
On Feb 27, 2007, at 8:00 AM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>
>> Great. I'll send account requests.
>
> Geir, while you are busy requesting accounts could you also have a
> look whether the initial committers have developer privileges in JIRA,
> or why else we can't assign issues to others/ourselves or why the
> other
> workflow actions are not visible to committers. The strange thing is I
> seem to be able to resolve issues.
>
> Thanks,
> --
> Mark
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: getting back to River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
> Great. I'll send account requests.
Geir, while you are busy requesting accounts could you also have a
look whether the initial committers have developer privileges in JIRA,
or why else we can't assign issues to others/ourselves or why the other
workflow actions are not visible to committers. The strange thing is I
seem to be able to resolve issues.
Thanks,
--
Mark
Re: getting back to River project organization...
Posted by Nigel Daley <nd...@mac.com>.
On Feb 26, 2007, at 8:49 PM, Geir Magnusson Jr. wrote:
>
> On Feb 26, 2007, at 8:06 PM, Jim Hurley wrote:
>
>> Heeeeelllllpppp! :-o
>
> :)
>
>>
>> I may be just lost in how to proceed (please educate me),
>> but I'm not seeing any of the initial committers from the Proposal
>> actually set up.
>>
>> When I look at: <http://people.apache.org/~jim/committers.html>
>> it seems that Brouwer, Creswell, Daley, and Murphy have
>> acknowledged ICLAs, but aren't setup on River.
>
> Great. I'll send account requests.
>
> geir
Hi Geir,
My account is nigel at apache.org. Can you grant me karma for river?
Thanks,
Nige
Re: getting back to River project organization...
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 26, 2007, at 8:06 PM, Jim Hurley wrote:
> Heeeeelllllpppp! :-o
:)
>
> I may be just lost in how to proceed (please educate me),
> but I'm not seeing any of the initial committers from the Proposal
> actually set up.
>
> When I look at: <http://people.apache.org/~jim/committers.html>
> it seems that Brouwer, Creswell, Daley, and Murphy have
> acknowledged ICLAs, but aren't setup on River.
Great. I'll send account requests.
geir
>
> Geir (or Phil, Gianugo) -- can you help us through this?
>
> -Jim
>
> On Feb 23, 2007, at 4:36 PM, Jim Hurley wrote:
>> If we're going to be targeting March for Board status... then
>> it would be good to have some solid progress to report :-)
>>
>> Geir - can you help here so we can start the process of
>> getting the source from the Proposal into the project.
>> That sure seems like Step 0.
>>
>> thanks -Jim
>>
>>
>> Begin forwarded message:
>>> From: Jim Hurley <Ji...@Sun.COM>
>>> Date: February 20, 2007 10:57:16 PM EST
>>> To: river-dev@incubator.apache.org
>>> Subject: Re: getting back to River project organization...
>>>
>>> Geir-
>>>
>>> Are we set with all the initial committers from the Proposal?
>>> If so, does anything need to be done to setup the committers
>>> or the initial PPMC?
>>>
>>> thanks -Jim
>>>
>>>
>>> On Feb 17, 2007, at 12:36 AM, Jim Hurley wrote:
>>>> On Feb 16, 2007, at 2:32 AM, Mark Brouwer wrote:
>>>>> :
>>>>> BTW Geir what is the status with regard to the accounts, do you
>>>>> have all
>>>>> the required ICLAs and CCLAs in?
>>>>> --
>>>>> Mark
>>>>
>>>> I believe we're all set from the Sun initial committers -side, but
>>>> it would really help to get that confirmation. Geir- can you
>>>> confirm?
>>>>
>>>> thanks -Jim
>
Re: getting back to River project organization...
Posted by Jim Hurley <Ji...@Sun.COM>.
Heeeeelllllpppp! :-o
I may be just lost in how to proceed (please educate me),
but I'm not seeing any of the initial committers from the Proposal
actually set up.
When I look at: <http://people.apache.org/~jim/committers.html>
it seems that Brouwer, Creswell, Daley, and Murphy have
acknowledged ICLAs, but aren't setup on River.
Geir (or Phil, Gianugo) -- can you help us through this?
-Jim
On Feb 23, 2007, at 4:36 PM, Jim Hurley wrote:
> If we're going to be targeting March for Board status... then
> it would be good to have some solid progress to report :-)
>
> Geir - can you help here so we can start the process of
> getting the source from the Proposal into the project.
> That sure seems like Step 0.
>
> thanks -Jim
>
>
> Begin forwarded message:
>> From: Jim Hurley <Ji...@Sun.COM>
>> Date: February 20, 2007 10:57:16 PM EST
>> To: river-dev@incubator.apache.org
>> Subject: Re: getting back to River project organization...
>>
>> Geir-
>>
>> Are we set with all the initial committers from the Proposal?
>> If so, does anything need to be done to setup the committers
>> or the initial PPMC?
>>
>> thanks -Jim
>>
>>
>> On Feb 17, 2007, at 12:36 AM, Jim Hurley wrote:
>>> On Feb 16, 2007, at 2:32 AM, Mark Brouwer wrote:
>>>> :
>>>> BTW Geir what is the status with regard to the accounts, do you
>>>> have all
>>>> the required ICLAs and CCLAs in?
>>>> --
>>>> Mark
>>>
>>> I believe we're all set from the Sun initial committers -side, but
>>> it would really help to get that confirmation. Geir- can you
>>> confirm?
>>>
>>> thanks -Jim
Fwd: getting back to River project organization...
Posted by Jim Hurley <Ji...@Sun.COM>.
If we're going to be targeting March for Board status... then
it would be good to have some solid progress to report :-)
Geir - can you help here so we can start the process of
getting the source from the Proposal into the project.
That sure seems like Step 0.
thanks -Jim
Begin forwarded message:
> From: Jim Hurley <Ji...@Sun.COM>
> Date: February 20, 2007 10:57:16 PM EST
> To: river-dev@incubator.apache.org
> Subject: Re: getting back to River project organization...
> Reply-To: river-dev@incubator.apache.org
>
> Geir-
>
> Are we set with all the initial committers from the Proposal?
> If so, does anything need to be done to setup the committers
> or the initial PPMC?
>
> thanks -Jim
>
>
> On Feb 17, 2007, at 12:36 AM, Jim Hurley wrote:
>> On Feb 16, 2007, at 2:32 AM, Mark Brouwer wrote:
>>> :
>>> BTW Geir what is the status with regard to the accounts, do you
>>> have all
>>> the required ICLAs and CCLAs in?
>>> --
>>> Mark
>>
>> I believe we're all set from the Sun initial committers -side, but
>> it would really help to get that confirmation. Geir- can you
>> confirm?
>>
>> thanks -Jim
>
Re: getting back to River project organization...
Posted by Jim Hurley <Ji...@Sun.COM>.
Geir-
Are we set with all the initial committers from the Proposal?
If so, does anything need to be done to setup the committers
or the initial PPMC?
thanks -Jim
On Feb 17, 2007, at 12:36 AM, Jim Hurley wrote:
> On Feb 16, 2007, at 2:32 AM, Mark Brouwer wrote:
>> :
>> BTW Geir what is the status with regard to the accounts, do you
>> have all
>> the required ICLAs and CCLAs in?
>> --
>> Mark
>
> I believe we're all set from the Sun initial committers -side, but
> it would really help to get that confirmation. Geir- can you confirm?
>
> thanks -Jim
Re: getting back to River project organization...
Posted by Jim Hurley <Ji...@Sun.COM>.
On Feb 16, 2007, at 2:32 AM, Mark Brouwer wrote:
> :
> BTW Geir what is the status with regard to the accounts, do you
> have all
> the required ICLAs and CCLAs in?
> --
> Mark
I believe we're all set from the Sun initial committers -side, but
it would really help to get that confirmation. Geir- can you confirm?
thanks -Jim
Re: getting back to River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> I think the first small step(s) should be to get the source code
> in the project as our first milestone. Why don't we start with
> Service UI, and then focus on the Starter Kit. To that end... Bill
> has created a JIRA issue for the Service UI code contribution.
> Do we need to define a process in which to vote on accepting it?
> Let's work on getting that done.
As Geir mentioned in this posting
http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200701.mbox/%3c68E32F29-CEAC-468D-BAAA-7C00AAB1999D@pobox.com%3e
I think one of the mentors should start a vote [1] for accepting the
code, we can then check (or maybe should already have done that?)
whether it complies with the ASF requirements.
[1] so they can formulate in a way that won't result in a discussion
about whitespace and location in SVN, for it is very easy to end up
there. If that is the intention of such a vote than that is fine,
but I think it is better if the mentors are to blame for that ;-)
BTW Geir what is the status with regard to the accounts, do you have all
the required ICLAs and CCLAs in?
--
Mark
getting back to River project organization...
Posted by Jim Hurley <Ji...@Sun.COM>.
Since my original post on thoughts on River project organization,
the discussion on the list has veered back away from organization,
and dived down into various discussions (code whitespace,
testing, long term picture, etc). I know those are all important to
varying degrees, but I'd like to get us back to spending some time
organizing and on process (I know, a bad word ;-)), so that we
can make progress within the context of a step wise progression.
I feel like the project needs to make some small successful steps
in which we can build on.
In the next day or so, I'll start the wiki page I proposed below and
put some of these organizational elements in them. You're then
free to go in an modify at will :-)
Mark- I like your breakdown here (modulo the testing discussion
that happened), so I'll try to incorporate that somehow. Thanks.
I think the first small step(s) should be to get the source code
in the project as our first milestone. Why don't we start with
Service UI, and then focus on the Starter Kit. To that end... Bill
has created a JIRA issue for the Service UI code contribution.
Do we need to define a process in which to vote on accepting it?
Let's work on getting that done.
thanks -Jim
On Jan 31, 2007, at 2:42 AM, Mark Brouwer wrote:
> 0) policy of how to deal with code changes (as in RIVER-2), also I
> think your point 5) should be discussed first;
> 1) setup of JIRA with components and proper permissions for
> developers,
> at least to the extend it makes sense;
> 2) we have a group of people that have actual access to SVN, meaning
> the ICLA and CCLA are fine and accounts are created;
> 3) merge ServiceUI and JTSK for the time being so we have one build
> process, I agree with Bob that separation complicate things.
> Although
> I hope this agreement only lasts for a few months ;-)
> 4) work towards an initial (internal) release that in all aspects
> compatible with the current JTSK, this means that fixes from Sun
> internally could get in as well as improvements lingering around
> the world. This would mean we assign issues to a new version and
> this allows those willing to participate to pick tasks in a way
> that is beneficial to the whole community on the short term;
> 5) setup of test infrastructure to validate the outcome of 4
>
> It is my expectation working towards an initial release takes at
> least a
> few months, depending on how much improvements we want in it. This
> buys
> us time to sort out the longer term roadmap issues, of which some of
> them can have a huge impact. If some of the roadmap issues are tackled
> in an early stage we could even start parallel development, although
> given the fact SVN has no merge history tracking I'm personally very
> reluctant to have any significant development going on in what is
> not the trunk branch.
Begin forwarded message:
> From: Jim Hurley <Ji...@Sun.COM>
> To: river-dev@incubator.apache.org
> Subject: thoughts on River project organization...
>
> Hi all-
>
> We've had a lot of good discussion on the list over
> the past month, but things haven't progressed as
> much as I think they could have. That's certainly just
> partly due to the nature of starting up a new project
> in a new space (for some of us), as well as not
> having the contributed block of code from the Starter
> Kit, Service UI, and testing in the project yet. It also seems
> to me, though, that some organization around the
> project could help us focus and make some good
> progress.
>
> To that end, I've gone back through the ~200 list
> messages, and tried to pull out a main list of topics.
> Would it help to have this on a wiki to help us track?
>
> If ya'll think this (organization) is a good idea -- I'd
> like to agree on the initial list, where to put it, and
> how best to attack it. Let me know what you think.
>
> thanks -Jim
>
> ---------------------------------------------------------
>
> Here are some of the topics/issues that have been
> raised:
>
> River-dev:
>
> 1) Accepting main initial contributions:
> - Service UI code (vote needed?)
> - Starter Kit code
> - test code
>
> 2) Overall vision/characterization and goals of the project
> - Continuation of what's been done, new
> stuff, something else? If new stuff, expansion
> of core (horizontal) or vertical?
> - short term (e.g., plug replacable with existing release?
> compatibility?) and longer term goals
> - split the project in various pieces?
> - define a platform?
> - spec (in)compatibility goals
> - deliverables? repackage? separate releases/distributions?
> different services? core?
> - how does Service UI fit in?
> - still developing a "Starter Kit"?
>
> 3) Need TODO areas
> - "I want to help in River, what do I do?"
>
> 4) Roadmap
> - which version of J2SE?
> - when to convert com.sun.jini to org.apache.river namespace
> - support for "Jini across the firewall"
> - replacement (if any) for the starterkit installer
> - at what point do we force developers to change their
> existing scripts (e.g., com.sun.jini.start, config files,
> policy files)
> - "Subcomponents"? Organizing the code repository and site
> For separate releases, etc
> - what kind of releases? and when?
>
> 5) Project organization and process guidelines/standards
> - formation of PPMC?
> - how to accept new committers?
> - committers vs. non-committers?
> - monthly incubator status reports
> - status file <http://incubator.apache.org/projects/river.html>
> page updates?
>
> 6) JIRA
> - use of JIRA (for everything, for only 'significant' things)?
> - use JIRA for site updates?
> - defining the JIRA components (website/infrastructure/
> contributions/serviceui/jtsk?) (java package names?)
> - move bugs from Sun db over?
>
> 7) Javadoc / Specs / Documentation
> - how/where host (Javadoc/specs/doc)
>
> 8) Testing
> - what's needed/required?
> - how to establish automated test execution?
>
> 9) Misc
> - <http://incubator.apache.org/river/> page updates?
> - project logo?
>
> ----------------------------------------------------------------------
> ----