harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [doc] new "Getting Started" guides
Date Fri, 29 Sep 2006 09:01:21 GMT
On 9/28/06, Geir Magnusson Jr. wrote:
> <SNIP>
> >
> > For example, what the problem with releasing  'keytool' or 'beans
> > framework'?
> > Why these parts should wait until we complete full toolset of
> > classlib?
> Maybe the problem is a simple confusion over the word "release". What
> do you mean here?  We'd have a download called "harmony-ketool-
> v1.0.tar.gz"?  I'm guessing that this isn't what you mean.  Sorry for
> me being dense :)

Yes, you are right about confusing "release" word. Let's forget about it and
start from the beginning. My point is that we should give clear message to a
newbie that the project consists of independent parts and we should provide
the newbie with a shortest path to a part where the newbie want to

For example, 3 steps:
Apache Harmony Home page
    ->Getting Started For Contributors page
        -> Component's homepage

The path shouldn't lead to nowhere, like saying: go to the dev-mail archive
or JIRA and search for [classlib][<module name>]. The path to a component
should end with component's status info – ideally it should give the newbie
enough info not to search though harmony-dev mail archive or JIRA at all. At
minimum the path should lead the newbie to the component's wiki page. Yes,
wiki pages are good but I think we need more. What the component's home page
should contain? From my point of view it should contain the following:
1) Doc: just brief overview and pointers to spec., docs, user's guides
2) Work with the component: how to build, deploy with Harmony JRE (or
another JRE if possible) and run with apps.
3) Status: in progress, no activity or done (that I mean by saying
"released", sorry for confusion)
4) Open issues: info from JIRA (we can fetch issues related only to the
component from JIRA)
5) Mailing list: I think we should let the newbie to be aware only about
exact part of the project.
6) Wiki page

For example, the newbie may be interesting in contributing to BEANS and
don't want to receive tons of messages about VM. We may let message pass
from component's mailing list to common mailing list. (Even more we may add
required prefix to subject automatically, for example, "problems with
Introspector" => "[classlib][beans] problems with Introspector")

Does this make sense?

> >
> >
> >> I think we need to continue to focus on our primary goal, java SE.
> >> I've also been concerned about having "subprojects" that are too
> >> independent, creating sub-communities.  I think that should be
> >> avoided at all cost.  Sure, we each have our focus and
> >> specialization, but we're one project, one community.
> >
> >
> >
> > IMHO, we unintentionally pushed idea of independency components to
> > project's
> > backyard. I think this is not good.
> Sorry - I don't understand either.

I just meant that we should start with description of independent parts.

>>> We have categories for JIRA - doesn't that work?  Mail list is busy,
>>> but right now we seem to be doing ok in terms of segmenting by
>>> subject line, and quite frankly, I still think that the benefits of
>>> intermixing currently outweigh the costs.  yes, we need a user list
>>> soon, and someday we'll split VM from classlib, but right now,
>>> there's such good collaboration...
>> Yes, high mail traffic might be a problem it constantly grows. And
>> subject's
>> line definitely helps now but I'm not sure about future.
>Oh, we're definitely going to split lists someday.

Mail traffic is going to exceed 2K message this month. Are you waiting for
10K messages? :-)

> > Also some parts of the project are indeed independent. For example,
> > it may
> > be possible to take some framework from classlib, say logging
> > framework, and
> > try it with another JRE. And the framework should work. This is true
> > independence. So it seems more natural for me to create a sub-
> > project for
> > the framework to let it be more attractive for users: has less
> > bugs, is
> > faster, follows the spec. and so on. Why not?
> First, classlib is modular so users can do that already.

I thought that it may be not quite clear for newbie how to use modularity.
May be I'm wrong.

  Second, the
> Java SE spec license doesn't allow independent releases as in "we are
> choosing to distribute this as shipping software", so we don't want
> to take on that issue.

Yes, I understood you point. I don't suggest delivering some framework or
a tool and announcing it as "piece of JAVA". IANAL, I just wonder if we can
suggest a user to try the following testing scenario: take some module's
jar, for example, sql.jar and try an app that depends on SQL API with JRE
that she/he usually uses. Is this restricted by the license?

Stepan Mishura
Intel Middleware Products Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message