Hi Chris,

I suppose many of us drawn towards Git instead of Monticello find Monticello
lacking in not only minor ways. The alternative or improvement needs not
necessarily be Git, but given its acceptance in the wider developer
community, it is an obvious choice.


Chris Muller-3 wrote
> For me,
> it's not really anything about any "feelings" about Git as the
> (im)practicality of integration.  It's a beast.  To bring a beast into
> _everyone's_ workflow that has 90% more "stuff" than we need [...]

What exactly do you think is so massive about Git? The basics are really
quite simple. The complexity comes with the vast number of possibilities to
transform a graph of history, and canonical Git supporting many of them, but
you do not have to do or support all of these. Other idiosyncrasies of Git
can be simply omitted. For example, you will not find anything about the
"index" or staging area of Git in the Git Browser tools. Git vocabulary is
different from Monticello vocabulary (that is true for almost all pairs of
version control systems) and Git has some different ideas of how tracking
works and what to put in a single repository. But if you stick to the
Monticello workflows and know the corresponding Git vocabulary, I contend
that Git is not more complicated than Monticello. Fixing a Monticello
ancestry is at least as complicated as doing a rebase ("advanced feature")
in Git; after you have learned either, you can confidently wield either.

In other ways, Monticello just looks simpler because something is in fact
missing. Consider branches: most Git tools have knobs to deal with them in
various ways, while Monticello tools just deny to talk about branches.
Monticello ancestry does support branching, yet I think Monticello lacks
first-class objects for branches, with all the implications for repository
handling. The tools might look simpler without branch management, but it is
not a feature but rather the lack of one. Note that you can also avoid
branch management in Git: just stay on the mainline branch forever and merge
your commits back and forth with the upstream repository's mainline. While
it might appear simpler that way, you might as well call it less organized.


Chris Muller-3 wrote
> [...] requires
> them to sign up just to use -- I think it would be a "filter" on the
> community, especially of non-developers (hint:  You and Jakob are
> developers).  For me, being hosted by a private company is not so
> attractive.

As Phil pointed out, you seem to confuse Git with GitHub here. But your
arguments are applicable if we take the integrated issue tracker into
account because that needs to be run by someone. In theory Squeak could host
an own GitLab Community Edition server instead of relying on GitHub.

Note that you also have to sign up to use Mantis or participate on the
mailing list or the Slack channel.

About the "filter": how many non-developers try to trace inbox contributions
or engage in code reviews? How many non-developers use Monticello (given
that it can only track packages and configuations thereof)? The "filter"
might not take anything interesting away from the other target audiences
after all. 

We do not wish to move all discussions from the list to pull requests. Also
the idea was to link up pull request conversations with the list, like the
CI job reports, or conversations on the OpenSmalltalk-VM repository to the
vm-dev list.


Chris Muller-3 wrote
> For example, you could submit an
> improvement that allows original contributors of Inbox items to move them
> to Treated themself.

How? Only Trunk committers have access to the Squeaksource treating backend,
so neither the code nor the tool is available to normal users for
improvement. Guest users cannot even delete versions from the inbox
repository, can they?


Chris Muller-3 wrote
> You could add a button to filter out all entries in
> the Inbox which have further descendants also in the Inbox.  You could
> make
> an, "update from Inbox" which would only download packages for which have
> your loaded versions as ancestors.

I don't understand how these would help in the tracking of issues, can you
elaborate please? My understanding: The first shows you the tips of all
loose branches in the inbox, but still without a mapping to issues (which is
not necessarily a 1:1 mapping, with reinforced complexity because of the
drive towards a compact ancestry...). Combined with some client-side
extensions it might allow us to track branches locally, but not share them
explicitly. To find remote branches, you would have to download many of
these versions first because only then you can access their ancestry (you
don't know in advance which versions are the tips, and combined with the
redundancy among versions, this is a Monticello implementation flaw). The
second would allow an update if someone moved some of your own branches
forward. But it rarely happens nowadays.


Chris Muller-3 wrote
> There are many simple things that could
> be done.  A bug-tracker is a bigger deal, but it's often a lot less
> overhead to just FIX the bug than open, track, and close a bug report.  We
> do have Mantis to keep track of the longer-term bugs.

I think this plays down the issue. It being a bigger deal is exactly why we
would like to use an existing platform. "Just FIX the bug" is not always so
straightforward that a single new version is sufficient. There might be
multiple iterations, or multiple packages affected, or many versions towards
a larger goal over an extended period of time. That's why we would like some
integrated issue tracking, even for short-term bugs. Think more of pull
requests with conversation and review facilities than of bug tickets. Pull
requests, combined with a system that can actually track branches or tasks,
allow for iterative refinement and feedback while binding all the iterations
or steps together.

Mantis is not integrated with Monticello, is it? Also it doesn't look very
active.


Chris Muller-3 wrote
> We have *decades* of Monticello packages for Squeak across not just our
> own
> repositories, but many other "external" legacy repositories. [...]
> Monticello will continue
> to be used by some.  

In my opinion this is no argument against different tools because nobody
suggested to remove Monticello from Squeak. As we already see in practice,
Git tools and Monticello tools, as well as both kinds of repositories, can
co-exist.

Otherwise we could still use floppy disks because there are decades of
software packages that were distributed on floppy disks, yet we don't. :-)


Chris Muller-3 wrote
> It seems clear that the only path to Git and other
> tools is a backward-compatible integration with existing tools

Well, other paths have already been walked. ;-) But in which direction goes
this backwards- compatibility? Do you want be able to use newer tools also
on old repositories? Alright, that would be nice. Do you want to be able to
use newer repositories in old tools? Why, given that it will probably
restrict the newer repositories?


Chris Muller-3 wrote
> a "stepping
> stone" that doesn't require a major adjustment like losing method-level
> timestamp information.

This seems to confound the use of Git with the use of the Tonel format with
a Pharo-style implementation.

Otherwise it affirms what I wrote a few messages before: maybe we do have to
bite the bullet and write a proper MCGitRepository that molds Git-hosted
projects into the Monticello tools, even though we have already created
other tools.

By the way, the draft spec of Tonel that Martin was offering to the list in
a recent thread demands that custom attributes on classes, methods, ... be
preserved by the system. So even if Squeak woulde use Tonel more often in
the future, it would not necessarily mean that method timestamps have to be
sacrificed. Squot and its Git tools are stored in the FileTree format, have
been Git-hosted from the start, include some packages whose Monticello
ancestries have been converted and integrated into the Git history, and has
method timestamps all over.


Chris Muller-3 wrote
> But it's not going to write itself.  Only the
> burning interest within people like you and/or Jakob will get it done.  :)

Thank you for the encouragement. Unfortunately with regards to Monticello
tools it recurrently sounds like: "If you want contemporary features, you
must add them to the old tools because we do not want to adopt new tools
that can already do the job." Forgive me if this reads too polemic.

Kind regards,
Jakob



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