2009/6/29 Stéphane Rollandin lecteur@zogotounga.net:
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.
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 lecteur@zogotounga.net:
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
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
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
Hi!
Andreas Raab wrote:
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
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 goran@krampe.se:
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.
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.
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 andreas.raab@gmx.de:
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
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
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).
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 keith_hodges@yahoo.co.uk:
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).
There is a new status in mantis "testing" - thats it.
Keith
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
I'm all ear to a more efficient process (don't know the emoticon for open ear...)
Nicolas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Göran Krampe -
Ian Trudel -
Keith Hodges -
Nicolas Cellier -
Stéphane Rollandin