RFC: fix typos in README file

[Mario Torre]

Il giorno mer, 23/01/2013 alle 10.09 -0800, Richard Bair ha scritto:
> Ah, well, ahem, you have discovered one of our deep dark secrets that
> we're working to fix ASAP (about the same time the majority of
> everything is open by end of next month), and that is that right now
> the team is working from a set of internal forests and change sets are
> pushed to the public repos immediately whenever they are pushed to a
>  private repo.

:)

> We need to instead start working out of the public repos directly so
> that folks like you would be able to push directly, rather than having
> to send us patches. There are a couple things we have to work through
> (freely plagiarized from internal email discussing the subject):
> 
> 
> 1) The current structure of the openjfx projects on hg.openjdk.org is
> not conducive to allowing external contributors (or internal for that
> matter) to directly push changes. The reason is that each release on
> openjfx is a forest, so all of openjfx/8 is one forest from the point
> of view of allowing forest commands to operate and for access control.
> This means there is no way to give a developer access to the team
> forests without also giving them access to master. I see this as a
> limitation of the openjfx infrastructure, and we will likely need some
> time from infrastructure team to discuss possible solutions.
> 
> 2) We have no way to lock our team forests or master for exclusive
> access. Once we can solve #1 we might be get away with not locking
> master if we can limit access to a limited number of team integrators
> (although for high-resistance I still think we need it), but in any
> case we need a solution or workaround for the team forests.
> 
> 3) We will need to decide how / whether to mirror the rt repo
> internally for Hudson builds, etc.
> 
> 4) We will need to fix a few things in the openjfx rt build system
> (which I would argue is a good thing anyway). Along with this we will
> need to rationalize the two different top-level "jfx" repos (open
> versus closed).
> 
> 
> (Obviously we will continue to have some code closed such as security
> vulnerability tests, customer specific proprietary tests, etc. As such
> we have to adjust our procedures so we pull from the open and then
> from a closed repo and the two can build together).

Unfortunately I don't have any ready answer to help out. I just can say
that any procedure ends up adding some overhead to developers, so in the
end what is best to smooth out the process and keep this overhead to a
minimum will likely make it easy for your side of the development and
also make our part easier as well.

OpenJDK has had external contributions since the beginning, but things
there have *high* overhead to both internal and external contributors,
but it's not that terrible as some people thinks. Part of the problem is
the bug database, which is still a pain to deal with.

Overall, I think OpenJFX is doing pretty well, I would like to see a
JIRA without required login, but otherwise is open and accessible. The
number of external contributors is still relatively small, but constant
and of good quality from what I've seen so far, so if you find a way to
allow for external committers I think you've already won most of the
challenge.

Probably restructuring the layout of the source is mandatory for this.

On the other end, the OpenJDK code is also a forest per se. Maybe I'm
getting the problem you mention wrong, but it seems to me that the
layout of OpenJFX is not that different than the layout of OpenJDK, and
having a gate repository for push only with a mandatory JIRA bug id
could be a good intermediate solution.

Everybody with the right credential could have access to the repository
that is the target of the bug, for example in my case that would be
master-gate, if I had done a fix in the control, that would have been
control-gate, and so forth. But I'm sure is not that simple or you would
have done it, besides this also have some drawbacks you likely
considered (more repositories to work with).

> I don't think any of these issues is really hard per-se but we are of
> course doing a bunch of other things at the same time (getting the
> remaining source code out there foremost among them).

Yes, this is rather important and deserves time and care.

> Its all rather embarrassing, but we'll get it sorted. The Danno / Tom
> solution of having a bitbucket repo and filing a JIRA with a link to
> the patch has been working really well and then I can apply the patch
> in the interim.

I'll try this with the next patch, if this is easier for you than the
webrev thing. I'm not that happy to use external tools, especially ones
that require logins and click through, but being an interim solution
that's not a big deal, beside, not everyone has access to cr.openjdk or
similar web space.

Cheers,
Mario