<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Nico, Folks,<br>
<br>
On 10/22/2020 11:19 AM, Nicolás Papagna Maldonado via Cuis-dev
wrote:
<blockquote
cite="mid:CADGn7BPaqiM9S81LG1RX9NK+678O4_+vjypr8B03S-h+0297CQ@mail.gmail.com"
type="cite">
<div dir="ltr">Hi folks!
<div><br>
</div>
<div>A couple of days ago I found by chance (I was not
subscribed to Github Notifications) that Mariano's changes
have been merged into the <a moz-do-not-send="true"
href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pull/175">Cuis-SmalltalkDev</a>.</div>
<div><br>
</div>
<div>As I mentioned in this thread, I was trying out the changes
using Mariano's Finder in my personal Cuis projects to test
the changes (thanks Hernan for testing them too, and Mariano
for submitting them!).</div>
<div><br>
</div>
<div>However, <a moz-do-not-send="true"
href="https://github.com/npapagna/cuis-finder">https://github.com/npapagna/cuis-finder</a>
is the official repo for Cuis-Finder and I believe if
something is going to be merged into Cuis-SmalltalkDev it
should be first "officially" merged into Cuis-Finder.</div>
<div>If this is not the case, then I'll either run an outdated
repo, or I'll be forced to merge changes without having the
chance to evaluate them just to keep it in sync.</div>
<div><br>
</div>
<div>I do believe this was not done with bad intentions and
think it's a great opportunity to improve the way we handle
these kinds of scenarios to make things easier/more stable for
everyone.</div>
<div>So I propose that we only merge packages into Cuis from the
official package repo or check with the package maintainers if
this is not the case.</div>
<div>If there is a stable release, then that should be favored
over regular package file-outs.</div>
<div><br>
</div>
<div><a moz-do-not-send="true" class="gmail_plusreply"
id="plusReplyChip-1" href="mailto:marianomontone@gmail.com"
tabindex="-1">@Mariano Montone</a> thanks for the changes
you submitted :)<br>
</div>
<div>As I mentioned before I really appreciate them, but while
using it I felt some of them didn't quite align with what I
had in mind for Finder.</div>
<div>I think loosing the arrows keys and the ability to quickly
edit the search query in favor of tab switching is not very
user friendly (when tab/shift+tab already allowed tab
navigation in the first place).</div>
<div>The same goes for the PasteUpMorph refactor: I was thinking
of experimenting with having more than one finder open to
allow users to reorganize windows and continue exploring
without losing their search when browsing a result.</div>
<div><br>
</div>
<div>The good news is that I anticipated that Finder could have
more than one UI because of this.</div>
<div>The model is completely separated from the UI and there is
a setting that controls how Finder is launched, allowing
anyone to provide their own implementation.</div>
<div>Please feel free to get in touch if you need Finder to
include core changes to support your experiments.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Nico PM</div>
<div><br>
</div>
</div>
</blockquote>
<br>
When we move a package into the Cuis-Smalltalk-Dev or some other
repo in the Cuis-Smalltalk github org it is because the lead
developer(s) agree to move development there. I had assumed this was
the case with Cuis-Finder, and didn't stop to check if this was so.<br>
<br>
Nico, I understand now that <a moz-do-not-send="true"
href="https://github.com/npapagna/cuis-finder">https://github.com/npapagna/cuis-finder</a>
will continue to be the home of Cuis-Finder. Having a duplicate in
Cuis-Smalltalk-Dev could only add confusion. So, I've just removed
it.<br>
<br>
Mariano, Nico, it is up to you both to decide to merge efforts or
keep two separate lineages of the package. If you agree to maintain
a single one, and you want to host it in the Cuis-Smalltalk github
organization, you are welcome to do it.<br>
<br>
WRT package ownership, this is how I see it. The code we write can:<br>
1) Be integrated into the base Cuis image<br>
2) Be added as a Package to the Cuis-Smalltalk-Dev repo<br>
3) Be added as a Package to another (perhaps new) repo in the
Cuis-Smalltalk GitHub organization<br>
4) Be kept in a separate repo or location at the author(s)
discretion<br>
<br>
For options 1 and 2, the "ownership" is transferred to the
community. This means that anybody is free to submit modifications
or new versions, and that the usual community procedure is followed
to accept them and integrate them. The community, and especially the
maintainers of the Cuis base image, take responsibility to keep them
updated when changes to Cuis could break them. This means they will
be taken care the same as the base image.<br>
<br>
For option 3, if the author(s) desires so, they could still oversee
development. The only changes that authors won't be asked about are
changes required to keep the package working as Cuis evolves.<br>
<br>
For option 4, the author(s) keep full control over the code. As a
consequence, they keep the responsibility to update their code
updated as Cuis evolves.<br>
<br>
I hope these are reasonable rules, and I guess everybody had already
assumed they were like this. In any case, like everything else, this
is open for discussion.<br>
<br>
Thanks,<br>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
</body>
</html>