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 10:20:42 GMT
On 9/29/06, Morozova, Nadezhda <nadezhda.morozova@intel.com> wrote:

> ... 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 ;(



I think we should try reduce a level of chaos.
BTW, how many steps are required to find very usefull LUNI'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
> 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 :)



Yes, this can be possible solution.

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



It may just contain a reference to common part + some component's specific
(that is optional)

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



Hm, check out 0.5Gb of code, build (there is a risk that the build may be
broken) it and realize that she/he want to contribute to some small module
:-)

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



Yes, I think this can be automated.

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



Well, if the newbie wants to find something very much she/he will definitely
find it. The question is how many efforts are required for searching. I just
want to work out a way how organize web-site to make it simple.

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

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