[squeak-dev] Development methodology (was: tedious programming-in-the-debugger error needs fixing)

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Thu Oct 1 21:43:24 UTC 2020


> Sounds like Christoph wants an issue tracker that is integrated with the version control system.


Exactly. You managed to summarize in one sentence which took me two screen pages. :-)


> Now since Squeak does not switch to Git (given the feelings of several prominent people here towards Git), what remains to be solved is the integration with the version control system.


I already have some early plans about this lying on my desk how such an integration system could look like. Schematically, we would need to observe the list of pull requests in the git repository and mirror every new commit as an inbox version to the inbox. The other way around, the Monticello list of inbox/trunk versions needs to be observed, and all new versions that were not already triggered by a PR need to be converted into a new git commit either on the main branch or on a PR branch. Conversation could be synchronized using the OpenSmalltalk-VM-Bot.

Ideally, this approach could allow us to operate with the same version & issue model from two alternative views, Monticello+mailing list, and GitHub.


However, that's only a thought experiment at this time, and everything further would probably be an implementation detail only. The actual question is how big is the actual demand for such a hybrid/two-way VCS for us a community (and not for me as a single Monticello-moaning person) and how many people actually would like to use the git interface.


> I don't suppose anyone will be able to go the other way around and write, maintain, and operate the custom Monticello issue tracker platform in their free time.


I don't think so, too. While I appreciate the idea of using true Smalltalk objects for every part of the Squeak project, including issues and versioning, it is simply not realistic for a community of our size to build a full-stack service from the scratch for these aspects, again, that can compete with big existing solutions such as GitHub & Co. Thus, my personal opinion would be to outsource it.


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von jakres-2 <forums.jakob at resfarm.de>
Gesendet: Donnerstag, 1. Oktober 2020 22:57:59
An: squeak-dev at lists.squeakfoundation.org
Betreff: Re: [squeak-dev] Development methodology (was: tedious programming-in-the-debugger error needs fixing)

Sounds like Christoph wants an issue tracker that is integrated with the
version control system. GitHub just happens to be one of the platforms to
offer this (next to Bitbucket, and Gitlab, and Jira, and what not).

If I remember correctly, that is one of the reasons why Pharo has moved to
Git and GitHub: because they did not want to reinvent/reimplement these
tools.

There already is https://github.com/squeak-smalltalk/ and the squeak-app
repository over there (through Travis CI) is what sends us the smalltalkCI
reports for Trunk. Maybe we could use another repository there as an issue
tracker and subscribe issue/pull request comments to squeak-dev in the same
manner as the CI. (I don't suppose that the Mantis is still frequently used
or would send email to the list, correct?) Now since Squeak does not switch
to Git (given the feelings of several prominent people here towards Git),
what remains to be solved is the integration with the version control
system.

Maybe we have to build the proper Monticello frontend to Git repositories
after all... despite enjoying the non-Monticello tools such as the Git
Browser in and around HPI. I don't suppose anyone will be able to go the
other way around and write, maintain, and operate the custom Monticello
issue tracker platform in their free time.

Kind regards,
Jakob



Christoph Thiede wrote
> 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.





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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201001/3a7dea03/attachment.html>


More information about the Squeak-dev mailing list