[Pharo-dev] Keyboard events is broken.

Guillermo Polito guillermopolito at gmail.com
Wed Aug 7 09:55:40 EDT 2013

On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> My understanding how it should be:
> - you work in own branch  (and in git, repository clone is already a
> branch, just on your computer).
> If you want to make it public you need to make own branch on gitorious
> and commit there.
> - once you finished with changes and tested it , you are free to merge
> with blessed
> (no need to have GODs permission to do that, or make pull requests)

We did all that. We tested it with Ben because he needed the change to send
ctrl events from the vm to the image, which were not sent. We tested in our
computers, and we had no much trouble.

- I do not use delete key because I don't have one
- circumflex accent (return) was working with my keyboard layout

So the vm was to me in a completely usable state.

> now i understand we are humans and not immune to mistakes, but i
> insist that committing to blessed

'blessed' is a crappy name for a repository. And the idea that the code in
this repository is always working flawlessly is nonsense. For example, we
had for months the problem with the smallinteger in there.

And then, the unstable is in another repository then? Where is that
repository? Why do we have to make another repository for that and not just
a branch (in the same repo, not in my machine)?

> should be done after some manual testing and checking it don't breaks
> things badly, and of course
> blessed is not for committing the unfinished code , which in the
> middle of work.

First, we considered it as finished. What you found was a bug, not a
pending to do task.

Second, I have not the time to change to and learn every keyboard layout to
test, nor to plug every external keyboard and see how it behaves. So if you
think we should have done that, it will never be finished, and we will die
with what we have.

Third, we need an unstable official branch for the pharo vm code for people
to test. To me, as blessed is the only repository out there, it is the only
place where I can put it.

> That is my only issue , that you committed code which is not yet
> finished, and makes VM unusable,

Now again. To me the latest vm was completely usable. How can I
*prove*that the change is then finished if I do not test with every
device and layout?

So people has to test it. And let's be realistic: given the few people
using nowadays the latest pharo vm, if I put my code in my own personal
repository, how many people will download my *experimental* VM to test it
from my hidden branch in my hidden and personal repo? I guess almost none.

No one tests => never proved => never finished => never merged => dies

That does not work.

So if *bleesed* is the stable branch, which is the latest unstable branch?
Do we need many repositories for that?

and we cannot release VM with important fix to smallinteger bug before
> you finish, which turns yourself
> into a bottleneck.

You can always go to the vm log


and check my last commits and try to rollback them in any case. This change
was only two lines of code. I'm of course not the code owner.

Now, I'm tired to argue. I want to solve this by stating:
- how do we get the latest *unstable* and where should the code be
- how do we get the latest *stable* and where should the code be

Something else is that I have the feeling that we are discussing because of
the stupid "blessed" name. So I did this:
- create a new pharovm repo inside https://gitorious.org/cogvm, the old
blessed repo stays the same
- I copied everything from the repo blessed to pharovm, including history
- I created a blessed branch, which should in the future have the
properties you like <=> latest stable
- let master for latest bleedingEdge (not experimental, but maybe buggy)

And then if we want other branches we create them.


> --
> Best regards,
> Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130807/667e78e3/attachment-0002.html>

More information about the Pharo-dev mailing list