[squeak-dev] Compatibility (was some other subject...)

2009/6/29 Stéphane Rollandin <[hidden email]>:
>> So what? Some people keep using even older images.
>
> well thank you for driving me out. I guesss I just have to shut up now.

Don't be so dramatic, Stéphane. Your opinion is all right and worth
one voice. As everybody else here. =)

There are frustrations in regard to the constraint of backward
compatibility. It is greatly increased by the fact that we have
limited set of test cases to ensure our changes don't break anything.
And we don't have an official API to lean on as well...

Moreover, the community should ask the question on how important the
compatibility is (specifics in term of qualification and
quantification)? We could certainly define levels of compatibility,
set for each (major?) component. What has to be absolutely kept? What
can be ditched?

To simply state that it will break one's code is perhaps not enough
when a growing frustration in the community shows up. We should
definitively understand better what kind of need in terms of
compatibility our community has.

Could also this compatibility be simulated? Can we use text
transformation rules to update the code and thus ensure an easy
migration to newer image? Etc.


Ian.

--
http://mecenia.blogspot.com/

> To simply state that it will break one's code is perhaps not enough
> when a growing frustration in the community shows up. We should
> definitively understand better what kind of need in terms of
> compatibility our community has.

at times I wonder what kind of community this is. it definitely doesn't
feel like a community to me: I have been contribution packages and
original work for years that have mostly been unnoticed by 99% of the
"community". and when I speak up like I do today I feel like an alien.

the sociological structure of the Squeak community is maybe a key point
worth studying, that would help defining Squeak's goals and means. we
have researchers, educators, individuals, businesses and a large part of
silent people (as everywhere, but for Squeak specifically maybe it's no
so good to be silent)

my 2 cents.

Stef

2009/6/29 Stéphane Rollandin <[hidden email]>:
>> To simply state that it will break one's code is perhaps not enough
>> when a growing frustration in the community shows up. We should
>> definitively understand better what kind of need in terms of
>> compatibility our community has.
>
> at times I wonder what kind of community this is. it definitely doesn't feel
> like a community to me: I have been contribution packages and original work
> for years that have mostly been unnoticed by 99% of the "community". and
> when I speak up like I do today I feel like an alien.

Don't be upset with that. It's extremely challenging to contribute to
Squeak. And it's time to change that. You can make your point worth on
the mailing list and also discuss with Squeak Oversight Board. The
process is likely to be painful by any mean but we should leave our
emotions aside and discuss about what's important for every and each
of us.

> the sociological structure of the Squeak community is maybe a key point
> worth studying, that would help defining Squeak's goals and means. we have
> researchers, educators, individuals, businesses and a large part of silent
> people (as everywhere, but for Squeak specifically maybe it's no so good to
> be silent)

I agree with that. We need to speak up more and stand for what we
believe. I was mostly silent but it seems to be the right time to
share my experience, but also to listen to yours and others. Bear with
us, all right? =)

> Stef

Regards,
Ian

--
http://mecenia.blogspot.com/

Ian Trudel wrote:
> Don't be upset with that. It's extremely challenging to contribute to
> Squeak. And it's time to change that. You can make your point worth on
> the mailing list and also discuss with Squeak Oversight Board. The
> process is likely to be painful by any mean but we should leave our
> emotions aside and discuss about what's important for every and each
> of us.

Indeed. I'm all ears for ideas about how we can simplify the
contribution process.

Cheers,
   - Andreas

Hi!

Andreas Raab wrote:
Pharo has a world writable MC inbox. And they have "sworn" to react
quickly and review incoming stuff. That is of course a classical
"harvesting" setup, and we have had trouble with such a bottleneck
earlier - so I am not sure I advocate it, but if you have man power to
do the integration, it works.

Some of us believe that a simple "commit bit" might be a way forward,
meaning that if we (whoever "we" is) decide to trust a developer we
simply give that developer the right to commit straight to the trunk. No
review, no harvester, no inbox. It is trunk after all, sure, it can
break, so what? That is what unit tests and stable/unstable is for.

We should still of course use an issue tracker and above all correlate
our commits to issues on the tracker by including a reference to it.

Finally I think that new tools like a working DeltaStream base or MC2
could move us into other models of interaction. Deltas could enable a
subscribe/publish model with multiple streams, that would be an
awesomely interesting model to work in. Let's say Igor goes berzerk :)
and starts breaking things - then I could just unsubscribe from his
stream, rebuild and wait until the storm settles. Or if I learn that
Andreas has a stream with really interesting new features I would like
to have - then I add his stream.

But the fact remains, it must be TRIVIALLY easy to commit a quick fix.
Most quick fixes come about when someone is busy, busy doing work - and
if it isn't easy to "fire off" a fix, then it will not be done because
the work comes first.

In Gjallar I have experienced this lots and lots of times. I have
submitted some of my fixes to Mantis but I am sure I have more fixes
that I just didn't get around to send.

regards, Göran

2009/6/29 Göran Krampe <[hidden email]>:
I was also discussing the same idea with Igor. A community repository
accessible to everyone. Something that we could sync with and *at
least* submit quickly unit tests and possibly fixes. Additions should
probably be handled differently. The release team can still work on
their repository and integrate valuable patches and tests as they deem
necessary.

> Finally I think that new tools like a working DeltaStream base or MC2 could
> move us into other models of interaction. Deltas could enable a
> subscribe/publish model with multiple streams, that would be an awesomely
> interesting model to work in. Let's say Igor goes berzerk :) and starts
> breaking things - then I could just unsubscribe from his stream, rebuild and
> wait until the storm settles. Or if I learn that Andreas has a stream with
> really interesting new features I would like to have - then I add his
> stream.

Nah, Igor wouldn't do that! Would he? :)

The idea seems interesting. How would it be managed? It would be
interesting if community members could peer review streams and rate
them. We could possibly diminish the burden from release team's
shoulders if the evaluation partially shared on the community. The
community could perhaps have a direct incidence on what should be
reviewed by the release team, according to their rating.

> But the fact remains, it must be TRIVIALLY easy to commit a quick fix. Most
> quick fixes come about when someone is busy, busy doing work - and if it
> isn't easy to "fire off" a fix, then it will not be done because the work
> comes first.

I'm with you, Göran. This has to be quick and simple. Almost as a "BUY
NOW" or 1-click button. =)

> In Gjallar I have experienced this lots and lots of times. I have submitted
> some of my fixes to Mantis but I am sure I have more fixes that I just
> didn't get around to send.

Things do get lost, aren't they? And there is so much to review and
fix and update.

> regards, Göran

Regards,
Ian.

--
http://mecenia.blogspot.com/

Göran Krampe wrote:
> Pharo has a world writable MC inbox. And they have "sworn" to react
> quickly and review incoming stuff. That is of course a classical
> "harvesting" setup, and we have had trouble with such a bottleneck
> earlier - so I am not sure I advocate it, but if you have man power to
> do the integration, it works.

This may sound a bit cynical in the context of what you were originally
writing, but since we were just complaining about the reduced number of
contributions perhaps that makes the model more feasible again?

> Some of us believe that a simple "commit bit" might be a way forward,
> meaning that if we (whoever "we" is) decide to trust a developer we
> simply give that developer the right to commit straight to the trunk. No
> review, no harvester, no inbox. It is trunk after all, sure, it can
> break, so what? That is what unit tests and stable/unstable is for.

I would certainly be willing to give that a try. How about something
like using source.squeakfoundation.org with the board being admins for
the project and people who are granted commit rights get dev status?

> But the fact remains, it must be TRIVIALLY easy to commit a quick fix.
> Most quick fixes come about when someone is busy, busy doing work - and
> if it isn't easy to "fire off" a fix, then it will not be done because
> the work comes first.

I completely agree. I'm in the very same situation often enough.

Cheers,
   - Andreas

2009/6/29 Andreas Raab <[hidden email]>:
You mean current process like:
- check whether problem exists in a kernel image, or if you're just
eating your own dog food;
- check for existing mantis issue;
- open a new mantis issue if required;
- publish a fix;
- publish a test;
- add a hook for Installer;
- test the hook;
- register the mantis issue as ready for harvesting somewhere (should
better be a user changeable status in mantis report, rather than an
entry in a completely different site).

For a two line change, this infrastructure might cost a few hours indeed.
Ability to trace changes and addition of non regression tests don't
come for free.
Pharo has its own drag with this respect...

I'm all ear to a more efficient process (don't know the emoticon for
open ear...)

Nicolas

There is a new status in mantis "testing" - thats it.

Keith
>
> I'm all ear to a more efficient process (don't know the emoticon for
> open ear...)
>
> Nicolas
>
>
>  

2009/6/29 Keith Hodges <[hidden email]>:
Hi Keith,
Yes, I noticed, but It seems I can't change the status.
What is the procedure for a privilege-less user to notify readiness?

Nicolas