Mantis usage rules du jour

>> From: [hidden email] [mailto:squeak-dev-
>> [hidden email]] On Behalf Of Bert Freudenberg
>> Sent: Saturday, February 23, 2013 1:22 PM
>>
>> On 23.02.2013, at 19:02, Colin Putney <[hidden email]> wrote:
>>
>>> On Sat, Feb 23, 2013 at 8:09 AM, Frank Shearar <[hidden email]>
>> wrote:
>>>>> Mantis might appear less dead if reports/changes got posted to
> squeak-
>> dev. Thoughts?
>>>>
>>>> The reason it doesn't already do this is just that I didn't want to
> annoy
>> everyone. I think it's a great idea. What granularity ought to apply?
> Mails on
>> new issues? State changes (to see when something's resolved)?
>>>>
>>>> Yeah, great idea. I'd say send messages for both, with a [Bugs] tag for
> easy
>> filtering.
>>>
>>> Colin
>>
>> +1 for [Bugs] because short.
>>
>> - Bert -
>>
>
> Bugs is good because of bugs.squeak.org and mantis does come from bug.  I
> thought about bugs first but was thinking that we don't use mantis to
> document bugs only.  We use it for new code, for making changes to working
> code and such.  It works fine for me but I wonder if the name would prevent
> some people from using it, or would it cause some confusion.  
>
> [Squeak-dev] should really be [commits].  Maybe [Bugs] should be [changes]
> or [discuss].
>
> Ron

> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Bert Freudenberg
>
>
> On 24.02.2013, at 19:51, "Ron Teitelbaum" <[hidden email]> wrote:
>
> >> From: [hidden email]
> >> [mailto:squeak-dev- [hidden email]] On Behalf Of
> >> Bert Freudenberg
> >> Sent: Saturday, February 23, 2013 1:22 PM
> >>
> >> On 23.02.2013, at 19:02, Colin Putney <[hidden email]> wrote:
> >>
> >>> On Sat, Feb 23, 2013 at 8:09 AM, Frank Shearar
> >>> <[hidden email]>
> >> wrote:
> >>>>> Mantis might appear less dead if reports/changes got posted to
> > squeak-
> >> dev. Thoughts?
> >>>>
> >>>> The reason it doesn't already do this is just that I didn't want to
> > annoy
> >> everyone. I think it's a great idea. What granularity ought to apply?
> > Mails on
> >> new issues? State changes (to see when something's resolved)?
> >>>>
> >>>> Yeah, great idea. I'd say send messages for both, with a [Bugs] tag
> >>>> for
> > easy
> >> filtering.
> >>>
> >>> Colin
> >>
> >> +1 for [Bugs] because short.
> >>
> >> - Bert -
> >>
> >
> > Bugs is good because of bugs.squeak.org and mantis does come from bug.
> > I thought about bugs first but was thinking that we don't use mantis
> > to document bugs only.  We use it for new code, for making changes to
> > working code and such.  It works fine for me but I wonder if the name
> > would prevent some people from using it, or would it cause some

> >
> > [Squeak-dev] should really be [commits].  Maybe [Bugs] should be
> > [changes] or [discuss].
> >
> > Ron
>
> [squeak-dev] is added to all mails by the list software.
>
> [Bugs] would be in addition.
>
> Actually, since we don't have a [tag] for commit messages either, maybe we
> don't need them, as long as the rest of the generated subject still allows
> filtering?

> On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape <[hidden email]> wrote:
> PS: Off-topic but IMHO important. I started replying to this email
>     7:30 AM and got stuck at the installation instructions and now
>     I send this mail at 1 PM;
>       I, sadly, have to conclude: Installing a proper development
>     image for Seaside on Squeak is still a mess.
>       I was the one who provided the Squeak Seaside image for Squeak 4.3
>     but currently I see myself completely unable to set up Seaside for
>     Squeak 4.4.
>     Just some random notes to relieve me:
>     • Installing Seaside need Metacello.
>     • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing
>       and completely unavailable for Squeak
>     • Bootstrapping metacello needs Omnibrowser basics
>     • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is
>       completely broken. Remember the not working buttons? still there.
>     • First installing OmniBrowser via Coiln’s script and then loading anything via
>       Metacello that depends on OB: boom
>     • First installing Omnibrowser via Metacello, then loading via Colin’s script:
>       no boom, but conflicting Classes. need to remove OB-Morphic manually...
>     • at _that_ point I gave up.
>
> I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
>
> rado

> Am 25.02.2013 um 14:26 schrieb radoslav hodnicak <[hidden email]>:
>
>> On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape <[hidden email]> wrote:
>> PS: Off-topic but IMHO important. I started replying to this email
>>    7:30 AM and got stuck at the installation instructions and now
>>    I send this mail at 1 PM;
>>      I, sadly, have to conclude: Installing a proper development
>>    image for Seaside on Squeak is still a mess.
>>      I was the one who provided the Squeak Seaside image for Squeak 4.3
>>    but currently I see myself completely unable to set up Seaside for
>>    Squeak 4.4.
>>    Just some random notes to relieve me:
>>    • Installing Seaside need Metacello.
>>    • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing
>>      and completely unavailable for Squeak
>>    • Bootstrapping metacello needs Omnibrowser basics
>>    • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is
>>      completely broken. Remember the not working buttons? still there.
>>    • First installing OmniBrowser via Coiln’s script and then loading anything via
>>      Metacello that depends on OB: boom
>>    • First installing Omnibrowser via Metacello, then loading via Colin’s script:
>>      no boom, but conflicting Classes. need to remove OB-Morphic manually...
>>    • at _that_ point I gave up.
>>
>> I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
>>
>> rado
>
> Well, there is
> https://github.com/renggli/builder/blob/master/scripts/seaside3-metacello.st
> which explicitely _does_ use Metacello and
> https://github.com/renggli/builder/blob/master/scripts/seaside3.st
> which explicitely _does not_ use Metacello.
>
> If you were an “image distributor”, ie, someone who hands images to other developers,
> which one would you take? Which resulting image is easier to update? Which script is easier
> to maintain? (Sorry the many questions, not meant to be offensive :) )
>
> Best
> -Tobias

>
> On 2013-02-25, at 14:56, Tobias Pape <[hidden email]> wrote:
>
>> Am 25.02.2013 um 14:26 schrieb radoslav hodnicak <[hidden email]>:
>>
>>> On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape <[hidden email]> wrote:
>>> PS: Off-topic but IMHO important. I started replying to this email
>>>    7:30 AM and got stuck at the installation instructions and now
>>>    I send this mail at 1 PM;
>>>      I, sadly, have to conclude: Installing a proper development
>>>    image for Seaside on Squeak is still a mess.
>>>      I was the one who provided the Squeak Seaside image for Squeak 4.3
>>>    but currently I see myself completely unable to set up Seaside for
>>>    Squeak 4.4.
>>>    Just some random notes to relieve me:
>>>    • Installing Seaside need Metacello.
>>>    • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing
>>>      and completely unavailable for Squeak
>>>    • Bootstrapping metacello needs Omnibrowser basics
>>>    • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is
>>>      completely broken. Remember the not working buttons? still there.
>>>    • First installing OmniBrowser via Coiln’s script and then loading anything via
>>>      Metacello that depends on OB: boom
>>>    • First installing Omnibrowser via Metacello, then loading via Colin’s script:
>>>      no boom, but conflicting Classes. need to remove OB-Morphic manually...
>>>    • at _that_ point I gave up.
>>>
>>> I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
>>>
>>> rado
>>
>> Well, there is
>>       https://github.com/renggli/builder/blob/master/scripts/seaside3-metacello.st
>> which explicitely _does_ use Metacello and
>>       https://github.com/renggli/builder/blob/master/scripts/seaside3.st
>> which explicitely _does not_ use Metacello.
>>
>> If you were an “image distributor”, ie, someone who hands images to other developers,
>> which one would you take? Which resulting image is easier to update? Which script is easier
>> to maintain? (Sorry the many questions, not meant to be offensive :) )
>>
>> Best
>>       -Tobias
>
>
> Well, in the first one the complexity is just hidden, distributed over many packages in various repositories, which seems hard to control for an individual image builder. As you discovered, it drags in many unneeded pieces - Zinc, OB, really? So if you want to build a clean image right now then it seems indeed avoiding Metacello would make your live easier. I don't know how much effort it would take to sanitize all the various configs it loads? Since you gave up after several hours, I guess a lot of effort (although I would be delighted to be proven wrong). But it sounds like it might not have taken you several hours to adapt the second script to your needs.

>
> On 2013-02-25, at 14:56, Tobias Pape <[hidden email]> wrote:
>
>> Am 25.02.2013 um 14:26 schrieb radoslav hodnicak <[hidden email]>:
>>
>>> On Mon, Feb 25, 2013 at 1:14 PM, Tobias Pape <[hidden email]> wrote:
>>> PS: Off-topic but IMHO important. I started replying to this email
>>>   7:30 AM and got stuck at the installation instructions and now
>>>   I send this mail at 1 PM;
>>>     I, sadly, have to conclude: Installing a proper development
>>>   image for Seaside on Squeak is still a mess.
>>>     I was the one who provided the Squeak Seaside image for Squeak 4.3
>>>   but currently I see myself completely unable to set up Seaside for
>>>   Squeak 4.4.
>>>   Just some random notes to relieve me:
>>>   • Installing Seaside need Metacello.
>>>   • Then somehow trying to install Seaside: do it wrong and Boom: Zinc is missing
>>>     and completely unavailable for Squeak
>>>   • Bootstrapping metacello needs Omnibrowser basics
>>>   • The Omnibrowser verison for Squeak as in the ConfigurationOfOmnibrowser is
>>>     completely broken. Remember the not working buttons? still there.
>>>   • First installing OmniBrowser via Coiln’s script and then loading anything via
>>>     Metacello that depends on OB: boom
>>>   • First installing Omnibrowser via Metacello, then loading via Colin’s script:
>>>     no boom, but conflicting Classes. need to remove OB-Morphic manually...
>>>   • at _that_ point I gave up.
>>>
>>> I haven't tried this recently but Lukas' scripts for building images at https://github.com/renggli/builder/tree/master/scripts don't use Metacello and I have used this method to load Seaside in the past (replacing Gofer calls with Installer).
>>>
>>> rado
>>
>> Well, there is
>> https://github.com/renggli/builder/blob/master/scripts/seaside3-metacello.st
>> which explicitely _does_ use Metacello and
>> https://github.com/renggli/builder/blob/master/scripts/seaside3.st
>> which explicitely _does not_ use Metacello.
>>
>> If you were an “image distributor”, ie, someone who hands images to other developers,
>> which one would you take? Which resulting image is easier to update? Which script is easier
>> to maintain? (Sorry the many questions, not meant to be offensive :) )
>>
>> Best
>> -Tobias
>
>
> Well, in the first one the complexity is just hidden, distributed over many packages in various repositories, which seems hard to control for an individual image builder. As you discovered, it drags in many unneeded pieces - Zinc, OB, really?

> Frankly I think this is a very good time, certainly as good as any, to
> reconsider how we track issues.  It's all going to have to be setup
> again from scratch soon anyway.
>
> I've personally always felt that that something integrated into Squeak
> itself (well, an installable package anyway) is the way for us to go,
> something customized to how we are accustomed to working and probably
> hooking into Monticello.  But making any such thing will be a lot of
> work and someone has to step up to do it and take the risk that the
> community will not find the result actually usable/acceptable.