harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [doc] new "Getting Started" guides
Date Thu, 28 Sep 2006 12:48:11 GMT

On Sep 28, 2006, at 2:49 AM, Stepan Mishura wrote:

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

Sure.  We should put something to indicate the parts then.  The  
federated checkout is nice because once you do it, you really do have  
two independent trees to work with, so you could simply just go into  
working_classlib and never come out :)

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

Oh, I see - yeah indeed.

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

I see what you mean now.

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

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

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

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

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

View raw message