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
-VM
   .....   <= 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
pile.
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
framework'?
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?

Thanks,
Stepan.

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to