[Vm-dev] can I have right to http://www.squeaksource.com/OSProcessPlugin ?

Wed Jun 7 21:02:31 UTC 2017

2017-06-07 22:06 GMT+02:00 Esteban Lorenzano <estebanlm at gmail.com>:

>
> forget it, I renounce to try to explain why from
> maintainability/management point of view is a lot better to keep all
> sources together.
> Obviously, I’m wrong, and the situation we have today is ideal.
>
> Esteban
>
>
Hey Esteban,
You have the right to disagree, my arguments are not gospell truth, and I
didn't remember writing ideal anywhere (just MC rocks).

IMO, having VMMaker sources replicated on pharo-vm github repo thru
filetree does count for something in managing complications you have so far.

I said it was not sustainable two years ago, and I doubt it's more now.

For the long term goal, I did not say that shifting to 100% git/github
tools would not be sustainable. I just said that such switching does
require mature in-image-tools, or guys like Eliot and me would not switch,
take it for some sort of wisdom.

For the short term goal, the original question of moving OSProcessPlugin, I
did the mistake (I missed the latest version recently), Eliot did the
mistake (he has even overriden one fix of mine by using an older revision
end of last year), you did the mistake, so it clearly shows something about
the process.

This process relies too much on manually opening repositories, inspecting
changes, and deciding to load/merge a newer MC revision.

Putting all the packages under one repository would ease this manual
process. The question I ask is whether there exist other means for
integrating changes as long as they are correctly managed upstream.

Eliot suggested that, David should generate C source and publish on
opensmalltalk-vm soon after posting a production ready MC package: indeed,
since he his the integrator, he knows what is production ready.
The danger is to forget, or postpone, especially because doing it both for
interpreter and cog/spur is too much demanding (too many different tools
maybe?).
One more step, and we go to automation of C-cde generation :), we just need
some sort of human blessing from the integrator.

David suggested that squeak guys use mcm, and I completed with Metacello.
You could have answered that you, as integrator of Pharo VM, wants finer
control than automated update to MC head if you wanted to argue, but having
to argue for you is no fun ;)

Last thing, such decision cannot be made without asking the
author/maintainer of the plugin, if you want to convince him, you have to
argue too, no?

Best regards

Nicolas

> On 7 Jun 2017, at 21:43, Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com> wrote:
>
>
>
> 2017-06-07 16:45 GMT+02:00 Esteban Lorenzano <estebanlm at gmail.com>:
>
>>
>>
>> On 7 Jun 2017, at 15:15, Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>> l.com> wrote:
>>
>>
>>
>> 2017-06-07 14:32 GMT+02:00 Esteban Lorenzano <estebanlm at gmail.com>:
>>
>>>
>>> Hi Dave, list
>>>
>>> I want to commit some changes to OSProcessPlugin.
>>> Can I have rights to that repository?
>>>
>>> thanks,
>>> Esteban
>>>
>>> ps: I need to insist in the necessity of having all VM plugins (the
>>> “official” ones: those who are compiled with the osvm builds) in the same
>>> place. Otherwise this is a horrible (and irreproducible) process.
>>>
>>>
>> Hi Esteban,
>> why not reproducible?
>> Isn't it manageable with a Monticello Configuration Map (.mcm) as David
>> suggested, or a Metacello ConfigurationOf... for being more pharo-to-date?
>>
>>
>> because is a pain to maintain, and having different repository services
>> makes you needing to thrust in different providers status, and then if you
>> want to work offline you need to take a copy of each repository which are
>> dispersed all around the world.
>>
>
> The  location are relatively stable so far (one move from
> www.squeaksource.com <http://www.squeacksource.com/> to source.squeak.org for
> VMMaker a few years ago).
>
>
>> I just lost 3 hours of my life trying to figure out which version of
>> OSProcessPlugin was the correct one, then looking for the correct
>> repository, etc.
>> This wouldn’t happened if all used plugins are maintained together.
>>
>> ... Nor if you would use either a mcm or Metacello configuration.
>
> Speaking of repository map, I just checked the status of Pharo 6, and it
> does not look more simple:
>
>  <Capture d’écran 2017-06-07 à 20.36.36.png>
>
> Naming branches and tagging stability is a different problem than
> repository location.
>
> For OSProcess, there are only two branches (interpreter and oscog/spur),
> and history is quite linear (just bug fixes). So the policy is: load
> latest, run regression tests, revert only if something goes wrong.
>
> It's true that in MC, explicitely naming branches is optional, but we
> can...
> It's just a convention (like naming master trunk cog or anything else is
> just a convention in git). I'm not sure we really need it yet for plugins,
> new features are scarce.
>
> The main difference is not about branches, it's more about integration of
> tools, issues/wiki/PR/CI.
>
>
>> btw (advocating for the way I would like to have things) this wouldn’t
>> even be necessary if all packages needed would be versioned along the
>> platform sources, using filetree format… then having the clone of your
>> desired version you would be sure to have also the correct VMMaker AND
>> plugin versions… but I know this way of sorting things is too much to ask,
>> so I would be happy if all packages are *at least* in the same place.
>>
>> Esteban
>>
>>
> For having worked a bit on the pharo-vm two years ago, the workflow was
> horrible.
>
> We had the workspace provided by image state - which is like a mixture of
> working copy (dirty with unpublished changes) + staging area (cherry
> picking thru MC GUI), eventually with branches/stach saved in
> package-cache, or in other MC repositories.
>
> This was concurrencing the working copy on disk, which was often out of
> sync, and conflicting.
>
> Branches in MC repositories had to be synced manually with git branches (I
> used my own Smalltalkhub repository for my own experiments with many
> feature branches, plus official VMMaker repo which I regularly tried to
> merge, plus pharo VM github repo).
>
> Each pull request was rotting immediately due to MC metadata and
> incomprehensible policy of ignoring the merge tool provided by Thierry
> Goubier (which was working quite smoothly).
> And there were bugs introduced by pharo in MC, plus bugs of file names too
> long, and I probably forget other annoyances.
>
> So it was a nice experiment for learning, but clearly not mature.
>
> Shifting entirely to git would reduce the complications a bit. and I
> promise I will test the new git-based-in-image-version-control-tools
> provided by Pharo and help getting closer to your ideal world.
> But what about the status of image changes? Or is the image a pseudo file
> system?
> Anyway, you know it will take time to reach the maturity and smoothness of
> MC. MC rocks (at least in Squeak).
>
> Stability of tools apart, for OSProcessPlugin, we have a different case:
> the manager wants to control integration of change requests. How is it
> going to work with a single repository? Or is it something you want to
> change too?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170607/b4657eee/attachment-0001.html>