On Sat, 2008-10-04 at 23:29 +0200, Marcus Denker wrote:

Hi,

Maybe I need to make some thing clear

1) There will be mistakes.

Yep, change includes mistake!

When integrating bugfixes and enhancements, it is impossible to not make mistakes. The problem is that one can not check every single fix, this is just not possible. And even if it would be checked line-by-line and very closely, there would be new bugs. It is just impossible that this does not happen.

The problem is of course that the people doing the integration everytime a bug is introduced look (and feel) like idiots. It would help if people would not strengthen this feeling... if I do something where I feel like an idiot most of the time, at some point I will stop.

Uhhh, is it that? I didn't read that much complaints on the list. Marcus, you are doing an incredible job!! And my feeling is that you are _really_ fast integrating stuff. Seeing that it is embarrassing for me as I don't find any time to do something for pharo at the moment.

2) There is only limited time.

We can not look at every submission directly, we can not fix every bug (even those introduced recently) very fast. This does not mean that we don't like the person who submited something (or that this person did something wrong). It *especially* does not mean to discriminate againt projects. e.g. if Seaside can't be loaded because of somet stupid bug, this does not mean that seaside is not wanted or something like that.

3) There is a lot of stuff that should be done ... and the only reason it is not done is lack of time. It's not because we are idiots.

I think we should build this community on trust. Trusting submissions of community members is not something bad in my opinion. It's not your job to check everything very deeply. It is the job of everyone to review updates/changes and to test them. Taking all together I think we need to split upstream. As long as there is only one upstream you can't check that _before_ it gets published. And people see a version in the upstream as the next stable thing. So we need a side channel for integration and testing. Norbert

Taking all together I think we need to split upstream. As long as there is only one upstream you can't check that _before_ it gets published. And people see a version in the upstream as the next stable thing. So we need a side channel for integration and testing.

This sounds like a good idea. Now I do not know if this could work because if we integrate B1 B2 B3 B4 and there is a problem we cannot really cancel B2 just add B5 to fix it. Stef

On Oct 6, 2008, at 7:22 AM, Norbert Hartl wrote:

On Sun, 2008-10-05 at 23:41 +0200, Stéphane Ducasse wrote:

...

...

Taking all together I think we need to split upstream. As long as there is only one upstream you can't check that _before_ it gets published. And people see a version in the upstream as the next stable thing. So we need a side channel for integration and testing.

This sounds like a good idea. Now I do not know if this could work because if we integrate B1 B2 B3 B4

and there is a problem we cannot really cancel B2 just add B5 to fix it.

I think there are cases where you have to redo B2, e.g. if it is not loadable.

Yes but there are case where you have to redo B3 if it depends/is based on B3

Then just redo it and post it to the list. Everyone using a development upstream should read the list. Removing B2 is not necessary because B5 undoes the problem of B2. And that is exactly the reason for doing an development upstream. You can undo things before merging the whole thing into the official upstream. The official one does not contain anything faulty from B2. What might be a problem is that version numbers on dev are getting larger faster than on the official one (if you use a single number).

So the usual development case is that you take the latest official release S1 and do subsequent D1, D2, D3, D4 enhancements. If you think everything is stable and worth publishing you merge D4 into S1 and create S2. Based on that you do D5, D6, D7 and so on.

This is already what we do somehow with publishing an image. But we do not have two streams.

About the naming scheme I'm not sure. I would prefer something like stable version 1 and development version 1.1, 1.2, 1.3 than stable version 2 and development 2.1, 2.2. So there is no doubt which development version belongs to which stable version.

But I don't know how much work it will be to get it work that way.

I do not know. What we can do is to have enough time and testers using the up stream. :)

Norbert

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Mike, I agree. We have discussed this in one or two threads before, but it might not be obvious for people joining Pharo. At the moment there is only an alpha version of Pharo available, and as usual in an alpha phase, there exist known bugs and changes are introduced that may break. In other words, this is not a version you want to use to run a power plant. However, this is only a temporary situation. As soon as we produce a first stable release, we will maintain this release and apply critical bugfixes, but no new features are added. This will be the version that people should be able to depend on for the use of Pharo in production. At the same time a new unstable version will be started to continue the development of Pharo. I think, we could then have two update streams, one for the stable and one for the unstable version. Cheers, Adrian On Oct 7, 2008, at 00:07 , Michael Roberts wrote:

given what I consider to be constraints - and these are not complaints at all, just observation which I am quite happy with 1) 3 harvesters 2) minimal software support for sophisticated branch or release management

I wonder if it would be better to put more effort into expectation management amongst the community. i.e define and document what the update stream represents, and what a 'release' represents. I think it is fantastic we have an update stream. It shows progress, and allows interested folk to test the integration by the harvesters and provide feedback. I do not consider each update to be a 'release' or stable. It is not blessed to me like updates that used to come out of Squeak Central. To me it just shows progress, even if it introduces bugs. A bug can be reported on the list/tracker, feedback can help the next update. each step we move forwards, in a small controlled fashion.

Perhaps once a milestone is reached, or some considered point in the future - a release is declared and built. Perhaps people who don't want to be on the development-edge do not update from the update stream until a time that it is recommended. Updates are addictive I find, but I have set my expectations and enjoy the progress.

just my thoughts, I would prefer the harvesting and update process is not complicated trying to satisfy too many requirements. From my point of view it is important we can test the integration represented in the update stream, since there should be a way that we can scale the testing amongst a wider group outside the harvesters.

It is perhaps interesing, (or not), that I was discussing something similar with Yann the other day. We were talking about MCC and what exactly it was - we did not really know. The next day a post on the Seaside list mentioned the move to universes in that context and constraints. Yann and I were wondering if it would be useful (or not) to have a bit more of the model of Envy maps in Monticello. We did not have any great ideas, just a feeling that Universes, MC, MCC, SM, Squeak SVN etc just demonstrate many forces that pull the needs for configuration management and version control in different directions. I think trying to solve this general problem: updates, branches, releases, backporting, distribution, approval, integration, etc is just very hard. My suggestion with Pharo would not be to do anything particularly clever at the moment as long as everyone knows what is to be expected from the current process. That way we keep moving forward without needing to reinvent too much in one go.

cheers,

Mike

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project