[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] SWT repositories moved to Github
|
Hi folks,
------ Original Message ------
From: "Alexandr Miloslavskiy" <alexandr.miloslavskiy@xxxxxxxxxxx>
To: "General development mailing list of the Eclipse project."
<eclipse-dev@xxxxxxxxxxx>; "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx>;
"Eclipse platform general developers list." <platform-dev@xxxxxxxxxxx>
Sent: 29/03/2022 00:40:32
Subject: Re: [eclipse-dev] SWT repositories moved to Github
On 2022-03-28 20:37, Aleksandar Kurtakov wrote:
These Git repositories are now moved to GitHub: https://github.com/eclipse-platform/eclipse.platform.swt and https://github.com/eclipse-platform/eclipse.platform.swt.binaries
Woohooo! New and shiny!
Bigger question:
I understand that we now rely on GitHub PRs instead of Gerrits. I would love to see the usual practice of PRs consisting of branches of properly chunked commits. I understand that previously patches were rather done in "single commit" style mostly due to Gerrit limitations. Now that GitHub PRs show entire pull request as a single thing that shows all associated commits, there is seemingly no roadblock to start making chunked commits. What do you think?
A practice we adopted in the Eclipse Theia project was to insist on a
_reasonable_ sequence of commits in the history before PR's were merged.
Usually, that is one commit. Our thinking was that if there is more than
one commit that makes sense as a step of evolution of the code, it's
better to open two PR's, because smaller PR's are simpler to understand
and test.
While the PR was under review, you would add commits to the PR to
address comments: since you can view changes from a subset of commits,
you can just look at new changes since you last reviewed. The fixup
commits would then be squashed before merging the PR.
If I've learned one thing in my 30+ years of developing software, it's
that you can't design a rule system that covers 100% of the cases: in
the end, the responsibility whether something is acceptable to be merged
lies with a committer. In fact that is their core responsibility.
/Thomas
PS: I know change sucks in general, but this is a good opportunity to
rethink some of the processes that have been in place for 20 years. What
still makes sense, what does not?
