Kohsuke Kawaguchi wrote:
> Aleksei Valikov wrote:
>
>> Having an extension/correction in mind,
>> 1. I file an issue (and observe the discussion on it).
>> 2. Add a new branch.
>> 3. Make my changes on this branch.
>> 4. Commit them.
>> 5. Post a comment that I'm finished.
>> 6. Someone from the project owners reviews my changes and
>> merges/denies them.
>
>
> That sounds good to me. Thank you for being very considerate.
>
> I don't mind quick changes like your codeModel change to go to the
> trunk, though.
>
I'm also comfortable with your proposal and second Kohsuke's
comment - if it isn't a major change, please feel free to
commit to the trunk. We don't want an overly complex process
for you to follow. In many cases, a simple discussion on the
dev alias will be sufficient.
I'd like to add a few additional things for you to keep in
mind when committing changes:
o Sun legal is *very* strict about 3rd party libraries. We
have to go through a detailed approval process before we
are allowed to introduce new 3rd party code. So, please
check with us before adding (or upgrading) any of the libs.
o Sun legal is also very strict concerning encryption related
code, so please do not make any changes related to that
without approval first (not that you would ;8-).
o When appropriate, please submit a test case for us to add
to our unit test framework. The unit test suite is private
for now (we're discussing how to split it up so you can have
access to the public portion). For now, we will continue
to run the tests internally and let you know if there are
any issues with your changes.
o We will keep you informed about internal project milestones
so that you know when certain branches/modules are frozen,
etc. For example, right now, the "jaxb-2_0-ea2" branch of
jaxb2-sources is frozen, but the trunk is open for commits.
o Spec / API related changes always require exchange(s) with
the spec guys. As I mentioned before, the javax.xml.bind
APIs are kept in a private CVS module and are manually
integrated as necessary. If there is something spec related
that you want to change, I think the right thing to do is
file an issue to start the discussion with the spec team
(like you did for your equals()/hashcode() proposal).
These are all rules that we follow internally as well. Let us
know if you have any questions or proposals for improving the
process.
That about it for now. Eventually, we will publish a governance
page outlining some of this process for other external committers.
Thanks,
--Ryan