Hi all,
sorry for the silence in the past few weeks. I hope you all enjoyed the holiday season. :-)
As the migration to the Eclipse infrastructure is now finally complete, we can get back to work. But I guess before we start, we should talk about some organizational topics. I think this is very important, so we can be as productive as possible and finally deliver the spec and the reference implementation.
A few topics I would like to discuss:
- In the past we didn't have any well-defined code format rules. But EE4J recently defined common rules which _could_ be used by the various EE4J projects. You can find more information on this EE4J wiki page. If we decide to use this code format, we should do it as early as possible.
- Do we want to integrate all our work into the master branch via pull requests or do we allow direct pushes? I would be fine with the former. It would make tracking changes easier for everyone.
- Should we set up branch projection on GitHub for the master branch? This would allow us to enable additional checks before we can merge pull requests, like:
- At least X review approvals before a PR can be merged (Maybe with just one required reviewer?)
- Travis build must pass (Always a good choice?)
- Must be rebased against master before it can be merged (too much work if there are multiple PRs)
- Do we want to define any formal voting rules about key decision which we may need to decide on in the future? Please remember that although Ivar and I are the project leads, we don't have any special privileges over other committers in these cases. Please see the Eclipse Project Handbook for more details. But maybe we don't need such rules and can defer this to later.
Any thoughts are welcome!
Christian
