[Pharo-project] Let's get rid of Core vs. Full
Hi, So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. 1) We don't develop the system using the tools that we tell people to use. -> bugs don't get fixed -> there is no pressure on improving the tools -> we can't use the advanced tools while developing the Core. 2) We integrate *far* too late. -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested. 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. -> People even expect to be able to shrink it more, which in turn we do not test. 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... getting them fixed for the release if they are not touched for a year is nearly impossible. 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working. So I vote for abandoning Core vs. Dev for 1.3. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Rather than abandon core vs full, here's a thought on a slightly different approach... Do development in the FULL version. That way the tools are used and bugs in the tools are fixed as the changes are made in the CORE...you are keeping the FULL alive, not adding new features, etc, since that kind of work is the responsibility of the maintainers ... Use the build server to run tests against the CORE and the set of CORE tools... You'll be dragging along more code as you do new development on the CORE, but at least the work of keeping the FULL version in synch will be spread across the whole CORE development cycle rather than concentrated at the end ... Just some ideas:) Dale On Apr 3, 2011, at 10:31 AM, Marcus Denker wrote:
Hi,
So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work.
1) We don't develop the system using the tools that we tell people to use. -> bugs don't get fixed -> there is no pressure on improving the tools -> we can't use the advanced tools while developing the Core.
2) We integrate *far* too late. -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested.
3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. -> People even expect to be able to shrink it more, which in turn we do not test.
4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... getting them fixed for the release if they are not touched for a year is nearly impossible.
5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late.
6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible.
The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working.
So I vote for abandoning Core vs. Dev for 1.3.
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On Mon, Apr 4, 2011 at 3:56 AM, Dale Henrichs <dhenrich@vmware.com> wrote:
Rather than abandon core vs full, here's a thought on a slightly different approach...
Do development in the FULL version. That way the tools are used and bugs in the tools are fixed as the changes are made in the CORE...you are keeping the FULL alive, not adding new features, etc, since that kind of work is the responsibility of the maintainers ...
Use the build server to run tests against the CORE and the set of CORE tools...
This is what makes the most sense to me as a user - and one that uses both core and dev. Dev is what I spend 99% of my time in, and of course core is what I actually deploy my applications on. But pretty much all of my impression of Pharo comes from Dev. The worry I would have about having only core releases, or core + untested Dev script would be that given the "clean design over backward compatibility" philosophy, none of the development tools would ever keep up with the changes in Core. You'd effectively have a product that was unusable to a developer (or at least, not a fair representation of how good Smalltalk can be for development). It basically comes down to this: Either you want to provide developer tools with Pharo or you do not. If you do not, then ditch Dev entirely, and make it very clear that Pharo is just a platform, and the third party developers of development tools will need to support Pharo specifically. If you do, then the Development tools need to be first class citizens. You need to develop in Dev - which is built from Core. And Dev needs to benefit from the same sorts of refactorings and cleanings as Core does, and tests in Dev must always be green (blue). Given that the webpage currently states that providing excellent development tools is a primary goal of Pharo, I feel that Dale's approach is what makes the most sense. Regards, Stuart
Hi, Well... I disagree to completely abandon full images. I understand the good reasons Marcus et all have to propose this, but in my opinion abandon a development image with needed development tools is a mistake, because most of us use it for development our applications, and most of newbies for sure need it, and don't know how to build it by themselves. Most of my students use the Pharo full image, and they tend to consider full images the real "Pharo" images (same way most people consider JSE version of eclipse the "real" eclipse). Said so... I really thing we need to flatten the pharo full image to it's minimal expression. I think now is some-kind over bloated and most of the problems we have is because we add too much packages to it, and for that reason we can't use it to develop the core image. My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image. Cheers, Esteban El 04/04/2011, a las 6:26a.m., Stuart Herring escribió:
On Mon, Apr 4, 2011 at 3:56 AM, Dale Henrichs <dhenrich@vmware.com> wrote:
Rather than abandon core vs full, here's a thought on a slightly different approach...
Do development in the FULL version. That way the tools are used and bugs in the tools are fixed as the changes are made in the CORE...you are keeping the FULL alive, not adding new features, etc, since that kind of work is the responsibility of the maintainers ...
Use the build server to run tests against the CORE and the set of CORE tools...
This is what makes the most sense to me as a user - and one that uses both core and dev. Dev is what I spend 99% of my time in, and of course core is what I actually deploy my applications on. But pretty much all of my impression of Pharo comes from Dev.
The worry I would have about having only core releases, or core + untested Dev script would be that given the "clean design over backward compatibility" philosophy, none of the development tools would ever keep up with the changes in Core. You'd effectively have a product that was unusable to a developer (or at least, not a fair representation of how good Smalltalk can be for development).
It basically comes down to this: Either you want to provide developer tools with Pharo or you do not. If you do not, then ditch Dev entirely, and make it very clear that Pharo is just a platform, and the third party developers of development tools will need to support Pharo specifically. If you do, then the Development tools need to be first class citizens. You need to develop in Dev - which is built from Core. And Dev needs to benefit from the same sorts of refactorings and cleanings as Core does, and tests in Dev must always be green (blue).
Given that the webpage currently states that providing excellent development tools is a primary goal of Pharo, I feel that Dale's approach is what makes the most sense.
Regards, Stuart
This is my ideas.
My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image.
This is what I understood from what Marcus said, too :) Cheers, Doru On 4 Apr 2011, at 15:57, Stéphane Ducasse wrote:
This is my ideas.
My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image.
-- www.tudorgirba.com "Every thing should have the right to be different."
This is what I understood from what Marcus said, too :)
sure I did not mean that marcus was stealing me ideas. But that I was inlined with esteban proposal Stef
Cheers, Doru
On 4 Apr 2011, at 15:57, Stéphane Ducasse wrote:
This is my ideas.
My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image.
-- www.tudorgirba.com
"Every thing should have the right to be different."
and I wasn't trying to steal marcus... If that's what he proposed, I just didn't understand it the first time... in that case, I say "I agree with Marcus" :) cheers, Esteban El 04/04/2011, a las 5:22p.m., Stéphane Ducasse escribió:
This is what I understood from what Marcus said, too :)
sure I did not mean that marcus was stealing me ideas. But that I was inlined with esteban proposal
Stef
Cheers, Doru
On 4 Apr 2011, at 15:57, Stéphane Ducasse wrote:
This is my ideas.
My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image.
-- www.tudorgirba.com
"Every thing should have the right to be different."
And I did not mean that you were trying to steal anyone's ideas. I just wanted to point out that people might have misunderstood what I understood Marcus said :). Cheers, Doru On 5 Apr 2011, at 13:37, Esteban Lorenzano wrote:
and I wasn't trying to steal marcus... If that's what he proposed, I just didn't understand it the first time... in that case, I say "I agree with Marcus" :)
cheers, Esteban
El 04/04/2011, a las 5:22p.m., Stéphane Ducasse escribió:
This is what I understood from what Marcus said, too :)
sure I did not mean that marcus was stealing me ideas. But that I was inlined with esteban proposal
Stef
Cheers, Doru
On 4 Apr 2011, at 15:57, Stéphane Ducasse wrote:
This is my ideas.
My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image.
-- www.tudorgirba.com
"Every thing should have the right to be different."
-- www.tudorgirba.com "We are all great at making mistakes."
As I can understand the proposal of Marcus is not have anymore an image without the minimal set of tools for development. And I full agree with this option. Allways is possible to shrink the image in a next step if needed. In other words, to me Core is not useful witthout a minimal set of dev tools and I'm doing production deployments with such tools with no problems. By other hand, as most of the images are in remote servers I need to use them via VNC and with the dev tools. Just my opinion. Cheers. 2011/4/4 Tudor Girba <tudor.girba@gmail.com>:
This is what I understood from what Marcus said, too :)
Cheers, Doru
On 4 Apr 2011, at 15:57, Stéphane Ducasse wrote:
This is my ideas.
My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image.
-- www.tudorgirba.com
"Every thing should have the right to be different."
Please someone clarify, are you going to kill the core? Honestly I don't know how people survive with the dev image, I guess you have super fast laptops. Not my case, and the Core just run nice in "old" hardware. 2011/4/4 Germán Arduino <garduino@gmail.com>:
As I can understand the proposal of Marcus is not have anymore an image without the minimal set of tools for development. And I full agree with this option.
Allways is possible to shrink the image in a next step if needed. In other words, to me Core is not useful witthout a minimal set of dev tools and I'm doing production deployments with such tools with no problems. By other hand, as most of the images are in remote servers I need to use them via VNC and with the dev tools.
Just my opinion.
Cheers.
2011/4/4 Tudor Girba <tudor.girba@gmail.com>:
This is what I understood from what Marcus said, too :)
Cheers, Doru
On 4 Apr 2011, at 15:57, Stéphane Ducasse wrote:
This is my ideas.
My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image.
-- www.tudorgirba.com
"Every thing should have the right to be different."
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
Not my case, I use to use 1.1.1 and 1.2 even in a netbook Lenovo x100 with no problems (Under Linux of course :) 2011/4/4, Hernán Morales Durand <hernan.morales@gmail.com>:
Please someone clarify, are you going to kill the core?
Honestly I don't know how people survive with the dev image, I guess you have super fast laptops.
Not my case, and the Core just run nice in "old" hardware.
2011/4/4 Germán Arduino <garduino@gmail.com>:
As I can understand the proposal of Marcus is not have anymore an image without the minimal set of tools for development. And I full agree with this option.
Allways is possible to shrink the image in a next step if needed. In other words, to me Core is not useful witthout a minimal set of dev tools and I'm doing production deployments with such tools with no problems. By other hand, as most of the images are in remote servers I need to use them via VNC and with the dev tools.
Just my opinion.
Cheers.
2011/4/4 Tudor Girba <tudor.girba@gmail.com>:
This is what I understood from what Marcus said, too :)
Cheers, Doru
On 4 Apr 2011, at 15:57, Stéphane Ducasse wrote:
This is my ideas.
My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image.
-- www.tudorgirba.com
"Every thing should have the right to be different."
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
-- ================================================= Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================
On Apr 5, 2011, at 3:00 AM, Hernán Morales Durand wrote:
Please someone clarify, are you going to kill the core?
Honestly I don't know how people survive with the dev image, I guess you have super fast laptops.
But you can unload packages.
Not my case, and the Core just run nice in "old" hardware.
2011/4/4 Germán Arduino <garduino@gmail.com>:
As I can understand the proposal of Marcus is not have anymore an image without the minimal set of tools for development. And I full agree with this option.
Allways is possible to shrink the image in a next step if needed. In other words, to me Core is not useful witthout a minimal set of dev tools and I'm doing production deployments with such tools with no problems. By other hand, as most of the images are in remote servers I need to use them via VNC and with the dev tools.
Just my opinion.
Cheers.
2011/4/4 Tudor Girba <tudor.girba@gmail.com>:
This is what I understood from what Marcus said, too :)
Cheers, Doru
On 4 Apr 2011, at 15:57, Stéphane Ducasse wrote:
This is my ideas.
My proposition for 1.3: 1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea) 2) Reduce the "full" image to Core+OB+RB+Shout+OCompletion+Finder+MetacelloBrowser 3) If it is possible, develop Core image into this reduced full image.
-- www.tudorgirba.com
"Every thing should have the right to be different."
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
1) Add MetacelloBrowser and switch to version-separated repositories (like MetaRepoForPharo11, etc. -I don't like the "abbreviated names" but you get the idea)
I will make sure the browser is robust and well documented. There is still some work to do on that front, but I will allocate the resources for this. I am sure Dale will join the effort as well. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Apr 3, 2011, at 7:31 PM, Marcus Denker wrote:
Hi,
So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work.
1) We don't develop the system using the tools that we tell people to use. -> bugs don't get fixed -> there is no pressure on improving the tools -> we can't use the advanced tools while developing the Core.
Yes
2) We integrate *far* too late. -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested.
yes but this is not our fault
3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. -> People even expect to be able to shrink it more, which in turn we do not test.
4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... getting them fixed for the release if they are not touched for a year is nearly impossible.
5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late.
But marcus you should also read the metacello chapter. Did you read it?
6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible.
The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working.
So I vote for abandoning Core vs. Dev for 1.3.
Yes but we need good tool. Stef
I really agree with you Marcus. It sounds to me that core/dev is a black and white approach. I know there are no resources, but what do you think of starting with a minimum image and the build over more sophisticated images? -Kernel image -Core image -Image with really basic browsing/scm tools (OB, Script Manager, Shout, etc) - or "developer basic" -developer standard (the current dev) -developer scientific -developer web ... etc. that wouldn't result in more easier integrations? Cheers, 2011/4/3 Marcus Denker <marcus.denker@inria.fr>:
Hi,
So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work.
1) We don't develop the system using the tools that we tell people to use.         -> bugs don't get fixed         -> there is no pressure on improving the tools         -> we can't use the advanced tools while developing the Core.
2) We integrate *far* too late. Â Â Â Â Â Â Â Â -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested.
3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. Â Â Â Â Â Â Â Â -> People even expect to be able to shrink it more, which in turn we do not test.
4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... Â Â getting them fixed for the release if they are not touched for a year is nearly impossible.
5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. Â Â e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late.
6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible.
The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working.
So I vote for abandoning Core vs. Dev for 1.3.
    Marcus
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
On Apr 3, 2011, at 9:34 PM, Hernán Morales Durand wrote:
I really agree with you Marcus. It sounds to me that core/dev is a black and white approach.
I know there are no resources, but what do you think of starting with a minimum image and the build over more sophisticated images?
-Kernel image -Core image -Image with really basic browsing/scm tools (OB, Script Manager, Shout, etc) - or "developer basic" -developer standard (the current dev) -developer scientific -developer web ... etc.
that wouldn't result in more easier integrations?
I'm not sure that you want a lot of different setups because it means checking problems due to interactions. So far we cannot maintain 2 so I do not see why more would help. a core + packages + a dsitribution browser to load certified distributions we want a mini-core + a set of maintained pharo packages + a configuration files When we work on them -> new mini core + automatic publication of new packages + new configuration files Right now this process does not work so this is a ***pain*** I spent 2 hours one sunday to fix some stupid problem with shout in OB just because we do not have good tools on top of metacello and because loading packages is slow. Stef
2011/4/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Apr 3, 2011, at 9:34 PM, Hernán Morales Durand wrote:
I really agree with you Marcus. It sounds to me that core/dev is a black and white approach.
I know there are no resources, but what do you think of starting with a minimum image and the build over more sophisticated images?
-Kernel image -Core image -Image with really basic browsing/scm tools (OB, Script Manager, Shout, etc) - or "developer basic" -developer standard (the current dev) -developer scientific -developer web ... etc.
that wouldn't result in more easier integrations?
I'm not sure that you want a lot of different setups because it means checking problems due to interactions. So far we cannot maintain 2 so I do not see why more would help. Â Â Â Â a core + packages + a dsitribution browser to load certified distributions
we want a mini-core + a set of maintained pharo packages + a configuration files
When we work on them     -> new mini core +  automatic publication of new packages + new configuration files
Ok I see. Let me comment some background: In the past I've worked in a team of 4 developers doing a custom ANSI private smalltalk, programming smalltalk code in notepad without cvs or any kind of SCM during almost 1 year, and I know what is having no tools at all. We had just a very well organized swiki, a methodology for communication... and an extremely ugly set of XML files for enabling "packages". We had weekly package releases. The core image was regularly released each month. Not a super mega project, but it worked for our client. Anyone wanting details of how please don't hestitate to ask me privately. I still have the documentation and source code. I'd prefer just a good mini-core or core release regularly than n setups, so my vote is for abandoning regular Dev releases, which to me are "newbie" releases, not meaning to offend anyone here, I know most readers know how to do their own dev releases (for example I have 2 pharo core images one for developing FFI and primitives and another one for scientific development). Believe me, I work everyday in Pharo and I've abandoned the Dev image, too many hangs when working heavily (I **really** tried the dev image), I can post the experiment scripts, although many times there were unhandled exceptions when just browsing code. If I had a team I'd report every issue.
Right now this process does not work so this is a ***pain*** I spent 2 hours one sunday to fix some stupid problem with shout in OB just because we do not have good tools on top of metacello and because loading packages is slow.
I'd like you enjoy releasing Pharo, I'm now enjoying comparing Smalltalk with Perl, Python and Java :)
Stef
-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.
On 3 April 2011 19:31, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work.
1) We don't develop the system using the tools that we tell people to use.         -> bugs don't get fixed         -> there is no pressure on improving the tools         -> we can't use the advanced tools while developing the Core.
2) We integrate *far* too late. Â Â Â Â Â Â Â Â -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested.
3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. Â Â Â Â Â Â Â Â -> People even expect to be able to shrink it more, which in turn we do not test.
4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... Â Â getting them fixed for the release if they are not touched for a year is nearly impossible.
5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. Â Â e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late.
6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible.
The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working.
So I vote for abandoning Core vs. Dev for 1.3.
Marcus, i think that full or 'dev' images just need to have a configurations which people could load on top of core image. The responsibility of core team is to define what is included in those configurations on next release and making sure that they can be loaded in latest core images. But don't mix 'can be loaded' with 'works without bugs' :) This is another story. This is where community has to be involved and people who interested in using full image(s) need to help with it. Otherwise, if nobody using it, then why wasting an effort with maintaining and fixing such a large codebase? I know it by myself, that bugs are discovered and fixed only when you using some tool(s). But if something lies there unattended, then it will definitely break at some point, and it is not really matters how hard you try to keep backwards compatibility or making sure all tests are green.
    Marcus
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Best regards, Igor Stasenko AKA sig.
Hi, I fully agree with Marcus. Cheers, Doru On 4 Apr 2011, at 09:18, Igor Stasenko wrote:
On 3 April 2011 19:31, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work.
1) We don't develop the system using the tools that we tell people to use. -> bugs don't get fixed -> there is no pressure on improving the tools -> we can't use the advanced tools while developing the Core.
2) We integrate *far* too late. -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested.
3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. -> People even expect to be able to shrink it more, which in turn we do not test.
4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... getting them fixed for the release if they are not touched for a year is nearly impossible.
5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late.
6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible.
The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working.
So I vote for abandoning Core vs. Dev for 1.3.
Marcus, i think that full or 'dev' images just need to have a configurations which people could load on top of core image. The responsibility of core team is to define what is included in those configurations on next release and making sure that they can be loaded in latest core images.
But don't mix 'can be loaded' with 'works without bugs' :) This is another story. This is where community has to be involved and people who interested in using full image(s) need to help with it. Otherwise, if nobody using it, then why wasting an effort with maintaining and fixing such a large codebase?
I know it by myself, that bugs are discovered and fixed only when you using some tool(s). But if something lies there unattended, then it will definitely break at some point, and it is not really matters how hard you try to keep backwards compatibility or making sure all tests are green.
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Best regards, Igor Stasenko AKA sig.
-- www.tudorgirba.com "Every thing should have the right to be different."
participants (10)
-
Alexandre Bergel -
Dale Henrichs -
Esteban Lorenzano -
Germán Arduino -
Hernán Morales Durand -
Igor Stasenko -
Marcus Denker -
Stuart Herring -
Stéphane Ducasse -
Tudor Girba