[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jdt-dev] Github workflow
|
Hi folks,
1. I suggest recommend a simpler fork/pull workflow. My setup is like this:
fork eclipse-jdt/eclipse.jdt.ui
clone eclipse-jdt/eclipse.jdt.ui
git remote add thomas .../tsmaeder/eclipse.jdt.ui
This way, branches are set up to track eclipse-jdt/eclipse.jdt.ui, not my fork. I never have to sync the fork, it purely exists to house my branches used in PR's. I always pull from the main repo.
2. We should set up a codeowners file that suggests reviewers for new PR's: many changes in gerrit got lost because no-one was requested.
3. We should set up a PR template that explains what we expect in a PR. Links to docs pages are fine.
4. Should we require an approval before merging?
5. Commit messages: now that we can have multiple commits in a PR, using the bug title as the commit message does not make sense to me. I would much rather have a concise description of the change. Look at this one, for example:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=577109 I doubt "[postfix] assist "sif" gone wild " is a very helpful commit message. Including a bug number for fixes is still helpful, though. Note that there is tooling in Github that allows you to find the PR a change was introduced in. So if you really need to know the history of a change....
6. Do we expect/recommend people to sign their commits with gpg?
7. Unless we have a technical reason not to, I would recommend we protect the master branch against direct pushes. PR's only.
discuss ;-)
/Thomas
