harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morozova, Nadezhda" <nadezhda.moroz...@intel.com>
Subject RE: [doc] new "Getting Started" guides
Date Fri, 29 Sep 2006 09:29:37 GMT
... My two cents: 

> 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. 
Good point, but am not sure we're ready for it just now. I haven't found
nice wiki pages for each modules/components. Things are sometimes quite
chaotic ;(
> 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
Again, nice idea, but not sure this is workable at the moment. We only
have >5 docs for API modules + ~3 DRLVM components + a couple more misc
docs.  
Do you think we can have sort of table in Classlib and VM component
pages: a list of modules with pointers to specs + Harmony-specific docs
+ status (done/missing/in progress/see JIRA/). This can give a pretty
clear picture of where we are :) 

> 2) Work with the component: how to build, deploy with Harmony JRE (or
> another JRE if possible) and run with apps.
Would that not be very similar (except for paths and similar) for the
majority of components? Don't think we need how-to build for each. 

> 3) Status: in progress, no activity or done (that I mean by saying
> "released", sorry for confusion)
Very important info. We have
http://incubator.apache.org/harmony/roadmap.html where major issues can
be listed, but probably component-wise info can also help. However, I am
not sure this is appropriate for newbies. Before deciding how they can
contribute, they'd rather have the code and run it. Also, this info can
be on Wiki page, where actual discussions/decisions run.

> 4) Open issues: info from JIRA (we can fetch issues related only to
the
> component from JIRA)
Can this be automated, at least to an extent? JIRAs seem to be a very
dynamic system. Otherwise, to keep the component page up-to-date and
with JIRA numbers would require frequent changes to the website. 

> 5) Mailing list: I think we should let the newbie to be aware only
about
> exact part of the project.
Specifying keywords by which to search on the mailing list? 


Best regards, 
Nadya Morozova
 

-----Original Message-----
From: Stepan Mishura [mailto:stepan.mishura@gmail.com] 
Sent: Friday, September 29, 2006 1:01 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] new "Getting Started" guides

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
contribute.

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?

Thanks,
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

---------------------------------------------------------------------
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


Mime
View raw message