Hi guys...

Let's talk about wich tools we need to make the process smooth. I offer to
program it.

Initial set of features:
- publish a changeset to the "repository"
- query the changeset from the image
- upload comments to the repository
- probably, when some condition fires, publish the .cs on the update-stream

What about that? What more? It's good?

Diego

PS: Time to start to work again :)


> hi bob
>
> I'm sure that they is something good in that direction. May be we
> should have a way to report from within the image itself too.
> Posting a change is really easy there is the post to the list. It would
>  be really cool to have a
> comanche server that would know how to accept comments and review about
>  a changeset.
>
> In the KCP I'm often bored and slowdown because I have to manually
> udpate the changeset into the page. I like the idea of the page because
>  everybody can follow what we are doing and load all the code in one
> click. Now if for the review people could say review for changeset...
> and automatically the review gets published in the wiki page with the
> right tag. this would make all the reviewing process and sharing of
> changeset between a group much easier. We were thinking to use cvs but
> this is too closed and going to sourceforge seems to us killing.
>
> So I do not know if the stream is really the solution but there is
> something to do in that vein.
>
> Stef
>
> On Wednesday, May 7, 2003, at 07:08 PM, Bob Arning wrote:
>
>> On Wed, 07 May 2003 09:53:42 -0700 Tim Rowledge
>> <tim at sumeru.stanford.edu> wrote:
>>>> So -
>>>> Write a small app that shows a list of changesets, html-scrapted off
>>>>  bug
>>>> fixes, and when you choose one, uses OSProcess to activate another
>>>> Squeak on a clean image, and load the changeset in question into
>>>> that image.
>>> Suggestion - change the sqfixes filter/whatever to put the changes
>>> files(s) and messages (if at all possible since they count as
>>> documentation) somewhere that is accessible as an FTP site; since
>>> Squeak
>>> has easy access to FTP it ought to be possible to read, file-in and
>>> even
>>> write back.
>>
>> Well, how about a radical solution: put *all* bug fixes in the (or an)
>>  update stream, but in an inactive form. Perhaps simply gzip+base64
>> the  change set plus documentation and install this in some sort of
>> ProposedChanges class. Then you can use any current image to easily
>> extract and test any proposed fix/enhancement. If you put them in
>> *the* update stream, it might be nice to add a preference to skip
>> these kinds of updates since they might be large and uninteresting.
>>
>> Cheers,
>> Bob