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 Thu, 28 Sep 2006 06:49:28 GMT
On 9/28/06, Geir Magnusson Jr. wrote:

> On Sep 27, 2006, at 10:53 PM, Stepan Mishura wrote:
> > t is great that you've created guides and put references to them at
> > top. So
> > now it is clear for newcomer what the next step is. And I'd like to
> > suggest
> > the following improvement for contributors guide: the page contains
> > only few
> > words about projects parts and it may create impression that
> > Harmony is a
> > one big/complex piece of software that has a lot of dependencies to
> > download. I think that it is important to say clearly in the
> > beginning of
> > the page that the project consists of many quite independent parts.
> > And the
> > newcomer has a choice to work with whole code base (a.k.a.
> > federated build)
> > or with a part of the project. So the top of the page should
> > contain two
> > references to federated build and to a description of the project's
> > components.
> I understand.  Remember, this is targetted for newbies - people who
> don't know anything yet, and what it tries to do is find the fastest
> path to getting working code from a single checkout.

Yes, I remember that and I wanted to share my view what the fastest way is.

> >
> > We have instructions for federated build. It looks OK for me. And the
> > description of components should give detailed picture of all
> > components not
> > just mention VM and Classlib. And the components' description
> > should points
> > to components' homepages.
> Good point.  But what other components right now would you point to?

A structure can be
-  Classlib
   .....   <= pointers to subcomponents
- Tools
    .....   <= pointers to subcomponents
    .....   <= pointers to subcomponents

> >
> > BTW, just random idea. I'd let each module to live by its own life
> > by having
> > its own homepage, releases, mailing list and JIRA component, like
> > we have
> > for ORB module (Apache Yoko project). Does this make sense?
> No.  There no sense in releasing just a classlibrary or a virtual
> machine.  Or a toolset.  You need the whole pile.

Sometimes it is hard to swallow a whole pile. J2SE implementation is a big
 I don't see anything wrong here why not to suggest the newbie to try a
piece of the pile.

For example, what the problem with releasing  'keytool' or 'beans
Why these parts should wait until we complete full toolset of classlib?

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

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


As for homepages, we already have that - basic pages for each major
> component.
> geir
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