[Cuis-dev] Home of Cuis-Finder and Code Ownership in Cuis. Re: Updates to Cuis Finder

[Juan Vuletich]

Hi Nico, Folks,

On 10/22/2020 11:19 AM, Nicolás Papagna Maldonado via Cuis-dev wrote:
> Hi folks!
>
> 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 
> Cuis-SmalltalkDev 
> <https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pull/175>.
>
> 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!).
>
> However, https://github.com/npapagna/cuis-finder 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.
> 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.
>
> 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.
> 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.
> If there is a stable release, then that should be favored over regular 
> package file-outs.
>
> @Mariano Montone <mailto:marianomontone at gmail.com> thanks for the 
> changes you submitted :)
> 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.
> 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).
> 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.
>
> The good news is that I anticipated that Finder could have more than 
> one UI because of this.
> 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.
> Please feel free to get in touch if you need Finder to include core 
> changes to support your experiments.
>
> Cheers,
> Nico PM
>

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.

Nico, I understand now that https://github.com/npapagna/cuis-finder 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.

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.

WRT package ownership, this is how I see it. The code we write can:
1) Be integrated into the base Cuis image
2) Be added as a Package to the Cuis-Smalltalk-Dev repo
3) Be added as a Package to another (perhaps new) repo in the 
Cuis-Smalltalk GitHub organization
4) Be kept in a separate repo or location at the author(s) discretion

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.

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.

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.

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.

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201022/8d733887/attachment.htm>