[V3dot10] Doing updates

[Edgar J. De Cleene]

El 2/11/08 2:00 PM, "Matthew Fulmer" <tapplek at gmail.com> escribió:

> However, I Really did not like how you handled communication
> with the rest of the community during 3.10. I would like you to
> do two things differently:
> 
> First, Make yourself available to the community. Log in to
> #squeak when you can, ask questions about little decisions you
> want to make in your project, and answer little questions that
> people have. People really like a person who discusses his
> project personally with them.

I'm not a team leader in 3.10. It's not my job.
My job was look swiki pages, follow Mantis reports, test the code of each,
doing all pain process and run the test three times.
On Mac, Linux, Windows XP.
In case I have questions, send Mantis notes to reporters.
If presence in #squeak helps, I could connect often.


> What problem does this solve? 3.10 was viewed by many as a
> communication disaster. No one knew how things were being
> decided, and no one knew how to influence the decision making
> process. Therefore, nobody contributed. To get people to feel
> comfortable enough with your project to contribute, you must
> advertise "Here is how decisions are made, and here is how to
> influence what goes in and out, and here is what we need more
> data on in order to make an informed decision to accept or
> reject a fix". 

We have  several pages in swiki about how to proceed in 3.10.
Several people contribute in Mantis and I respond to some questions directly
in all lists.
So I thing you are unfair in above paragraph.


> 
> Keith Hodges is a good example of how to do this right, and the
> tool he produced, namely the Installer wiki, goes a long way
> toward lowering the barrier to contributors:
> 
> 1. Keith is always accessible via IRC, so anyone can ask him a
>    quick question and get to know him. Someone who hangs around
>    and answers questions is really easier to trust.
> 
> 2. The image-building process is very easy and well-advertised
>    throughout the wiki. It is simply:
>         
>         Installer install: '311'
> 
> 3. There is a designated bin for people to request that people
>    examine bug fixes and test them for inclusion in the official
>    image. Also, it is easy to test them. Rather than click on
>    links in a page and download and install fixes one at a time,
>    simply execute:
> 
>         Installer install: 'MinorFixesUnstable'
> 
>    The more people review fixes, the more people leave comments
>    on whether they work or not, and the quicker the release team
>    can decide whether the fix should be included in the official
>    image. Finally, it is easy for the release team to mark the
>    change as "official"; simply remove the change from
>    http://installer.pbwiki.com/MinorFixesUnstable-Squeak3:10 and
>    add it to
>    http://installer.pbwiki.com/MinorFixes-Squeak3:10 . This is a
>    huge productivity boost over the 3.10 method of publishing a
>    new package and writing a new update script every time a bug
>    fix was accepted.
> 
> 4. Unload scripts are equally public and easy to use:
> 
>         Installer install: 'Clean'
> 
>    and the script is at
>    http://installer.pbwiki.com/Clean-Squeak3:10
> 
> 
> 
> 
> Why is this better than ReleaseBuilderFor3dot10?
Well, I disagree with he.
I believe in team work, but my ideas of how a team should be seems
different.
I believe Installer could be a kind of "goto " and people only should unload
updates from a only place.
Scripts ? Well, people could use, but again I think is not a good idea.
Regarding to ReleaseBuilder, I suggest read the first mails in this list
saying is the way to do.

My "tentative" image only shows the final product, as .cs updates should be
done and put into ftp.
As reduced image don't load easily old projects, maybe could be easy
download a ready one.

But is only my view.
Maybe we need a vote of following the practice of one update stream in .cs
form like we have until now or if better any could load things from any
place without some control.

Edgar