Hi all,

thanks for this insightful discussion! :-)

> (sorry for so much traffic from me today folks!)

No need to worry, I'm glad about any message by you!

I will give a short case study and tell you how I think it probably could be
performed more efficiently using the GitHub workflow:

1) I'm proposing a new extension to some Squeak component, let's say a menu
for the HelpBrowser. To do this, I upload a new version to the inbox
(Package-ct.2 based on Package-xyz.1).
2) Some kind person is giving me some feedback on the proposal so I am
reworking it. To share the new version with the community, I have two
options: A. Upload a new inbox version (Package-ct.3) that depends on
Package-ct.2 or B. upload a new inbox version that contains a copy of all
changes of Package-ct.2, too, that is based on Package-xyz.1 again, and that
explains that Package-ct.2 can moved into the treated inbox now. Usually, I
choose option B because it makes it easier to read the complete diff of my
proposal compared to the trunk (but let's see step 3 for this decision). In
every case, I need to leave a note referring to Package-ct.2.
3) Some kind person would like to clean up the inbox, including reviewing
and eventually merging of my proposal, but where should they find all
relevant information? Regarding to Package-ct.2, the Monticello Browser does
not give you any hint that it is stale and should be moved into the treated
inbox (provided that I chose option B in step 2) because you cannot see the
discussion from the mailing list there. The mail-archive thread about
Package-ct.2, too, does not contain any reference to Package-ct.3 (unless
I'm sending another piece of noise manually). On the other hand, if I chose
option 2.A, you cannot review Package-ct.3 standalone neither in the
Monticello Browser nor in the mailing thread. And things get more
complicated if just another review is left on the proposal before it can be
merged ...
Of course, as I am not a merging person, I cannot tell whether step 3
exactly describes your workflow as a merger, but I am facing very similar
issues when trying to get an overview of my own contribution. And also, we
had several small incidents in the past when something was merged that
actually should have been improved before (just for example,
Regex-Core-ct.56).

So how could this look differently when applying the GitHub workflow?
1) For the initial proposal, I'm opening a new Pull Request to merge
"helpbrowser-menu" into "trunk" with a single commit commit-a.
2) To react on the kind person's feedback, I add another commit commit-b to
this branch. GitHub, the GitBrowser, and every other git client will
automatically display the connection between both commits, and because
commit-a is no longer a head commit, it will not be considered as a complete
feature by anybody any longer.
3) Every subsequent feedback can be left directly to the Pull Request thread
(which can be easily synchronized with the mailing list using a bot similar
to the OpenSmalltalk-VM-Bot) and be resolved by just another commit to this
branch. All version information is kept at one single place.
*) As a bonus, GitHub offers a bunch of useful features that make it easier
to overview and organize all contributions. For example, we can
automatically run the CI for every Pull Request (which I'm sure would help
us to introduce a smaller number of bugs into the Trunk/master); issue/PR
references are automatically displayed on both ends of a link; people can be
assigned to certain PRs; labels can be used to mark a PR as draft, fix,
enhancement, review, etc. and much more ... Also, there is already an
existing project to integrate GitHub conversations into Squeak, see
SqueakIssueIntegration.
*) Another plus could be organizing all packages in one repository to get
rid of changesets sent to the list which I find truly unhandy as they are
not really designed for versioning.

> Those occasional hiccups with our inbox don't change the fact that reviews
> take time and effort. Having a fancy "auto-merge this pull request because
> CI says it is okay" won't make it better. Maybe even worse.

I agree that we will need to keep some policies, e.g. "checkout a change and
test it before merging" it, but unless this policy is violated, I do not see
how the quality should be impaired.
But won't you agree that reviewing stuff gets easier if you only have to
check one location instead of two or three, and requesting changes does not
require to start the next from the beginning again?

> Just look at the OpenSmalltalk VM repo:
> https://github.com/OpenSmalltalk/opensmalltalk-vm --- Many open issues and
> pull requests, some of them are several years old.

Hm, given a total of 335 PRs, 12 open PRs is not such a bad number, that is
about 3.6% of all contributions. The percentage of open inbox commits
733/(733+12744) is 5.4% which is somewhat worse, and this does not even
include all the unmerged changesets from the mailing list ... :-)

> When I'm spending my time writing version notes, committing and updating,
> I'm not writing code.

I cannot follow you at this point. Whether you upload a version to the inbox
or create a GH PR, you have to document your changes to some extent either
way. The difference is that if you make a follow-up commit to an existing
PR, you can be very brief (e.g. "fix a typo") and squash your commits when
merging the PR.

> With everyone doing it, everyone must constantly merging everyone elses'
> active-committal style, and if they're not really tested ("eh, fix
> later!") then

> Making a commit "feels" productive, but the extra efficiency from this
> methodology can only be realized when and if it's actually consumed by
> someone else and it was of good enough quality to boost their development.

There is no need to lower code quality just because of using a branching
concept, is it? CI can help us to *improve* quality but does not force us to
merge more often. Just in the opposite, it would be possible to develop
against an extra stable branch as proposed by Herbert (unless too many
people are touching the same components at the same time). And also, git has
a feature called rebase, so there is no need for too many merge commits :-)

> we need an ancestor selector on the commit dialog!

+1

> But, our community is small

That's another good point, I'd love to see more contributions by more people
on the Squeak project! But from my point of view, the mailing-list-based
workflow is simply a quite conservative approach that might keep many
potentially interested casual Squeakers away from participating in our
community. I think the following article provides a very good summary of my
thought on this matter: "Relying on plain-text email is a 'barrier to entry'
for kernel development, says Linux Foundation board member"
(https://www.theregister.com/2020/08/25/linux_kernel_email/). Marcel argued
that the mailing list works as a filter for keeping unexperienced or
unqualified people away from our community, but I believe our community is
too small for throwing away all these possible contributions.

Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html