Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [krazo-dev] Eclipse Krazo rules and organization
Hello everyone,

I agree with what Florian said.

--
Daniel Dias dos Santos
Java Developer
SouJava & JCP Member
Linkedin: www.linkedin.com/in/danieldiasjava


Em dom, 20 de jan de 2019 às 15:53, Florian Hirsch <post@xxxxxxxxxxxxxxxx> escreveu:
Hi everybody,

Code format rules would really be great.

I'd also like PRs and a protected master branch but I think Christian as main committer should decide if this would help or slow him down.

I don't expect too many controversial discussions in the near future and would wait with formal rules till we need them.

best
Flo

Am 20. Januar 2019 um 15:12:13, Christian Kaltepoth (christian@xxxxxxxxxxxx) schrieb:

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:
    1. At least X review approvals before a PR can be merged (Maybe with just one required reviewer?)
    2. Travis build must pass (Always a good choice?)
    3. 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


--
Christian Kaltepoth

_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/krazo-dev
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/krazo-dev

Back to the top