[squeak-dev] Re-liason proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re-liason proposal

Igor Stasenko
Because of a disturbing events which came after Andreas announced new plan,
that release team member(s) not seeing their own place under this
plan, and think it can seriously endanger/cancel all what have been
done during last few years,
i proposing on a next board meeting to invite a release team members
to discuss the problem(s) and find a compromise/solution which would
satisfy everyone.

This disturbance & fighting is the last thing i expected to occur,
when i gave my vote for Andreas proposal.

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re-liason proposal

David T. Lewis
On Sat, Jul 04, 2009 at 05:43:29AM +0300, Igor Stasenko wrote:
> Because of a disturbing events which came after Andreas announced new plan,
> that release team member(s) not seeing their own place under this
> plan, and think it can seriously endanger/cancel all what have been
> done during last few years,
> i proposing on a next board meeting to invite a release team members
> to discuss the problem(s) and find a compromise/solution which would
> satisfy everyone.

There is no way to say this without hurting someone's feelings, so
let me just say it plainly: Andreas' proposal is absolutely the right
thing to do. I strongly support it, and I strongly support the board's
approval for moving forward on implementing the process.

> This disturbance & fighting is the last thing i expected to occur,
> when i gave my vote for Andreas proposal.

It is right for the board to have this discussion, and hopefully a
consensus will emerge from it. Nevertheless, there are times when not
everyone will be happy, and this may be one of those times. Hurt
feelings or no, let's do the right thing and move forward.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re-liason proposal

keith1y
David T. Lewis wrote:

> On Sat, Jul 04, 2009 at 05:43:29AM +0300, Igor Stasenko wrote:
>  
>> Because of a disturbing events which came after Andreas announced new plan,
>> that release team member(s) not seeing their own place under this
>> plan, and think it can seriously endanger/cancel all what have been
>> done during last few years,
>> i proposing on a next board meeting to invite a release team members
>> to discuss the problem(s) and find a compromise/solution which would
>> satisfy everyone.
>>    
>
> There is no way to say this without hurting someone's feelings, so
> let me just say it plainly: Andreas' proposal is absolutely the right
> thing to do. I strongly support it, and I strongly support the board's
> approval for moving forward on implementing the process.
>
>  
>> This disturbance & fighting is the last thing i expected to occur,
>> when i gave my vote for Andreas proposal.
>>    
>
> It is right for the board to have this discussion, and hopefully a
> consensus will emerge from it. Nevertheless, there are times when not
> everyone will be happy, and this may be one of those times. Hurt
> feelings or no, let's do the right thing and move forward.
>
> Dave
>  
Dave with respect,

I think you are wrong, and I am not the only one, however the
technicalities of the situation are irrelevant.

The fact remains that the board made decisions about the release without
any discussion with the release team that they appointed. The board is
intended to be a body that provides guidance oversight and liason. In
the past it has always taken a hands off approach seeking to liase with
the teams that volunteer to do the work. The board has no authority to
tell squeakers what to do, this is a community of volunteers who spend
considerable amounts of time and effort working on everyones behalf. The
only barely real power the board has is to decide who can use the name
squeak.

It doesn't matter what you think of the work, if you delegate
responsibility to a team, you should leave that responsibility delegated
to that team, and communicate with that team, until such a time as you
seek to replace that team with fair due process.  If you appoint a
release team leader repsonsible for a release then you have given that
leader the authority to organise that release. You should not undermine
or usurp that authority, even board members should seek to work under
the team leaders that they appointed, other wise it makes a mockery of
the appointment of team leader. It is entirely out of order to self
appoint yourself as a replacement team leader, just because you have
been elected to the board. That is not liason, nor is it oversight. If
the board wants to find a new release team, then it should start a due
process of liason and consultation, recruiting volunteers and seeking a
new team leader. If a board member was to self-appoint himself as a team
leader this would probably be an abuse of his political position.

Take for example 3.10, did the board override Ralph ever? Did it want
to? I venture to say probably, but they would never have been so crass
as to do so without some public debate, and consensus over a prolonged
period. Even when Ralph disappeared for several months the board took
steps to try and phone him before making rash decisions.

We elected the board to represent us in a professional manner, with an
expectation that they would act with some level of decorum and
considered judgement. Thus far I am sorely disappointed.

Ask yourself how you would feel if 3 years of your work was summarily
discarded in this manner? And ask youself if you would be willing to
work without pay for anyone who was to treat you like this, not likely I
feel.

Keith

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re-liason proposal

Ian Trudel-2
This is surprising that the release team hasn't been consulted on the
back of this idea. The board is newly elected and hopefully they will
take such things into consideration next time.

However, as far as I understand, the new community development model
is experimental and open to re-evaluation by all means. And it
certainly does not get rid of the need to have a release team.

It's not time to get upset or offended by such things. But it is
always the right time to voice concerns.

Other questions come to my mind. Does the release team read this
mailing list? They could have shared their opinion during the
discussions, like everybody else. What the release team think about
the new model? Would they change or add anything?

Regards,
Ian.

--
http://mecenia.blogspot.com/

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re-liason proposal

keith1y
Ian Trudel wrote:
> This is surprising that the release team hasn't been consulted on the
> back of this idea.
Thats what I thought too, but surprising isn't the word I used.
>  The board is newly elected and hopefully they will
> take such things into consideration next time.
>  
There is a high attrition rate among those who have tried being in the
release team. The new process was supposed to help with that, by moving
to a more automated system.
> However, as far as I understand, the new community development model
> is experimental and open to re-evaluation by all means.
Oh right, where does it say that?
> And it
> certainly does not get rid of the need to have a release team.
>  
> It's not time to get upset or offended by such things.
Its a bit late for that.
> But it is
> always the right time to voice concerns.
>
> Other questions come to my mind. Does the release team read this
> mailing list?
I in particular had expressly expressed a desire NOT to be involved in
discussions about the release in squeak-dev, for various reasons.
Andreas for one knew this. Previous release-teams have had no problem
whatsoever in conducting relevant discussions on the release mailning list.
> They could have shared their opinion during the
> discussions, like everybody else. What the release team think about
> the new model? Would they change or add anything?
>
>  
Ian I have made my view quite clear, the new model replaces ALL the work
of the release team with something entirely innappropriate. Please read
my previous email for a detailed explanation.

Keith


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re-liason proposal

keith1y
In reply to this post by Ian Trudel-2
Ian,

In case you didnt realise I am the release team for 3.11. Since Matthew
my co-member was seconded off to look at re-licencing issues and 4.0

I expressly asked Andreas and others not to discuss release team issues
on squeak-dev, because my employer reads squeak-dev.

Every email that I send to squeak-dev risks my employer asking "Is Keith
really focused on delivering what I am paying him for". The answer
currently is no.

However, since I have now seen the true colours of the board and those
involed, I think I can go and do some real paid work now.

You know you could actually read the 3.11 documentation

http://installer.pbworks.com/SqueakReleaseTeam
http://installer.pbworks.com/Squeak311
http://installer.pbworks.com/Squeak311Proposal
http://installer.pbworks.com/311


Keith

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re-liason proposal

keith1y
In reply to this post by keith1y
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Re-liason proposal

Andreas.Raab
In reply to this post by Ian Trudel-2
Ian Trudel wrote:
> This is surprising that the release team hasn't been consulted on the
> back of this idea. The board is newly elected and hopefully they will
> take such things into consideration next time.

Yes, without any doubt that was a mistake. I was trying to avoid
delaying too much and move things forward and in the process I
overlooked this important bit of communication. I already apologized for
that to Keith.

Cheers (and happy 4th),
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

Ken Causey-3
I'd like to try to turn this discussion into another direction.  What
would you have us do now?

It's reasonable to argue that the Squeak Oversight Board made some
mistakes regarding communication.  I would point out that Keith
specifically requested that no discussion occur on squeak-dev.  I would
also point out that we tried to discuss issues with Keith many times
elsewhere.  Did anyone take a version of Andreas' plan to Keith and
directly ask his opinion?  No, not to my knowledge.  Andreas has now
apologized for that twice.  Versions of the idea were available for a
couple of days to everyone before the Board took any action.  The
response seemed to be favorable.

So what now?  As far as I can tell Keith would have us simply go back to
the way things were at the beginning of the week and completely cancel
Andreas' plan.  When we made this decision we specifically were not
canceling 3.11 or Keith's plan, we were adding a way for contributions
to be made.  I've specifically tried to engage Keith on what in Andreas'
plan interferes with his plan a couple of times and that both plans may
have to make some compromises to co-exist.  So far I've only been able
to understand a couple of issues that seem easily addressable from a
technical perspective otherwise it seems to simply come down to a belief
on his part that direct access to a large group to the content of the
image as packages is not going to work.  I have questions about that
myself, I don't see any way to answer those questions without trying it.

I don't see why, at least for a while, we can't pursue both efforts and
see where it goes.

Ken



signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

Ian Trudel-2
2009/7/4 Keith Hodges <[hidden email]>:
> Ian Trudel wrote:
>> This is surprising that the release team hasn't been consulted on the
>> back of this idea.
> Thats what I thought too, but surprising isn't the word I used.

Errare humanum est.

>>  The board is newly elected and hopefully they will
>> take such things into consideration next time.
>>
> There is a high attrition rate among those who have tried being in the
> release team. The new process was supposed to help with that, by moving
> to a more automated system.

Automated system always sounds good. Now, if only the system could
contribute to itself...

>> However, as far as I understand, the new community development model
>> is experimental and open to re-evaluation by all means.
> Oh right, where does it say that?

That's from my understanding. Can anybody from the board could confirm
or deny this statement?

>> It's not time to get upset or offended by such things.
> Its a bit late for that.

It's really important as a community effort to inject some positivism
at the moment. And your effort is as important as others in this
regard. You're not alone with frustrations. However, if we could leave
the emotions at the doors, we're likely to be able to discuss as grown
up. It comes to a point that your emotions are overwhelming in every
message you write.

Can we move on, please?

> Ian I have made my view quite clear, the new model replaces ALL the work
> of the release team with something entirely innappropriate. Please read
> my previous email for a detailed explanation.

This is where I think you're completely wrong. The release team is
still relevant even with the new community development process. The
official releases are ultimately in the hands of the release team. And
you would probably have a live communication with others about how to
integrate the release process in this new approach, if you were less
busy with your emotions that is.

Besides, you're also missing the trick when it comes to contribution.
On one side, there is quick and simple community development process,
based on MC repositories, and on the other side, some matis+installer
mantis+...+whatever. While the later might better fit to the release
process, it is not the case when it comes to contributions.

2009/7/4 Keith Hodges <[hidden email]>:
> I expressly asked Andreas and others not to discuss release team issues
> on squeak-dev, because my employer reads squeak-dev.
>
> Every email that I send to squeak-dev risks my employer asking "Is Keith
> really focused on delivering what I am paying him for". The answer
> currently is no.

You cannot discuss about release team issues on squeak-dev because
your employer is snooping but you openly admit that you're not doing
what you're paid for? Azooooo?!

> However, since I have now seen the true colours of the board and those
> involed, I think I can go and do some real paid work now.

You're judging them a tad too quickly.

> You know you could actually read the 3.11 documentation

Thanks for the links.


2009/7/4 Andreas Raab <[hidden email]>:

> Yes, without any doubt that was a mistake. I was trying to avoid delaying
> too much and move things forward and in the process I overlooked this
> important bit of communication. I already apologized for that to Keith.

There is so much one can apologize for. One sincere apology should
have been enough. Keith should get over it now. And then he could talk
with you about how to properly integrate the release process with the
new community development process. =)

Regards,
Ian.
--
http://mecenia.blogspot.com/

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

Nicolas Cellier
2009/7/6 Ian Trudel <[hidden email]>:
>
> Besides, you're also missing the trick when it comes to contribution.
> On one side, there is quick and simple community development process,
> based on MC repositories, and on the other side, some matis+installer
> mantis+...+whatever. While the later might better fit to the release
> process, it is not the case when it comes to contributions.
>


That raises the question: where will we find a database for tracing
changes and providing some rationale?
Mantis might be unefficient, but discussions in a mailing list does
not cover much of mantis classification features.
Can it be the work of the release team to classify and document the
work from other guys? I bet they would soon be flooded.
It's also important to trace why a change has not been accepted. A
mailing list is too much a short memory and some subjects might come
back recursively.

Andreas' proposition is certainly worth a try, but I don't see yet how
these questions will be addressed.

Nicolas

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

Bert Freudenberg

On 06.07.2009, at 10:07, Nicolas Cellier wrote:

> 2009/7/6 Ian Trudel <[hidden email]>:
>>
>> Besides, you're also missing the trick when it comes to contribution.
>> On one side, there is quick and simple community development process,
>> based on MC repositories, and on the other side, some matis+installer
>> mantis+...+whatever. While the later might better fit to the release
>> process, it is not the case when it comes to contributions.
>>
>
>
> That raises the question: where will we find a database for tracing
> changes and providing some rationale?
> Mantis might be unefficient, but discussions in a mailing list does
> not cover much of mantis classification features.
> Can it be the work of the release team to classify and document the
> work from other guys? I bet they would soon be flooded.
> It's also important to trace why a change has not been accepted. A
> mailing list is too much a short memory and some subjects might come
> back recursively.
>
> Andreas' proposition is certainly worth a try, but I don't see yet how
> these questions will be addressed.
>
> Nicolas


Good questions.

For keeping up-to-date on what's happening to the trunk the RSS feed  
is quite useful:

http://source.squeak.org/trunk/feed.rss

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

keith1y
Bert Freudenberg wrote:

>
> On 06.07.2009, at 10:07, Nicolas Cellier wrote:
>
>> 2009/7/6 Ian Trudel <[hidden email]>:
>>>
>>> Besides, you're also missing the trick when it comes to contribution.
>>> On one side, there is quick and simple community development process,
>>> based on MC repositories, and on the other side, some matis+installer
>>> mantis+...+whatever. While the later might better fit to the release
>>> process, it is not the case when it comes to contributions.
>>>
>>
>>
>> That raises the question: where will we find a database for tracing
>> changes and providing some rationale?
>> Mantis might be unefficient, but discussions in a mailing list does
>> not cover much of mantis classification features.
>> Can it be the work of the release team to classify and document the
>> work from other guys? I bet they would soon be flooded.
>> It's also important to trace why a change has not been accepted. A
>> mailing list is too much a short memory and some subjects might come
>> back recursively.
>>
>> Andreas' proposition is certainly worth a try, but I don't see yet how
>> these questions will be addressed.
>>
>> Nicolas
>
>
> Good questions.
>
> For keeping up-to-date on what's happening to the trunk the RSS feed
> is quite useful:
>
> http://source.squeak.org/trunk/feed.rss
>
> - Bert -
Take an example

- pick a goal of image minimisation.

Andreas' way of doing it is to announce "minimisation" and let loose the
team of squeak well wishers to target something to be refactored out.
Methods wil be deleted and a new image will be released, albeit as a set
of updated trunk packages.

Those in other forks of squeak will be left with a process of forensic
coding to work out exactly what was removed, why and how.

My way of doing it is to pick a package or subsystem that needs to be
unloaded, and to move all of those methods into a new package, save the
package in a public place.

Now, any fork of squeak can load that package, (re-organising the
methods in the local fork), and then unload the package to perform the
removal. Give or take the occasional fix needed to make this process
work smoothly it does work.

For an example of a package that has been targetted for removal this
way, I took Edgars script in SqueakLight and used it to remove Nebraska
in this manner. I also factored Object-Tracer.

- pick a goal of image reorganisation

Andreas way of doing things is to again let loose the team on the
repository... Mine is to publish the task for re-organisation and allow
the team to refine it until they are happy with it.

e.g.
            "reorganize Kernel-Object"
            self category: 'MorphicExtras-SqueakPage'     classes:
#ObjectOut.
            self category: 'Kernel-Tracer'                 classes:
#(ObjectTracer ObjectViewer).            
            self category: 'Kernel-Model'                 classes:
#(Model DependantsArray MessageSend WeakMessageSend).
            self category: 'Kernel-Model-Tests'        classes:
#(DependentsArrayTest WeakMessageSendTest).

Keith



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

keith1y
Keith Hodges wrote:

> Bert Freudenberg wrote:
>  
>> On 06.07.2009, at 10:07, Nicolas Cellier wrote:
>>
>>    
>>> 2009/7/6 Ian Trudel <[hidden email]>:
>>>      
>>>> Besides, you're also missing the trick when it comes to contribution.
>>>> On one side, there is quick and simple community development process,
>>>> based on MC repositories, and on the other side, some matis+installer
>>>> mantis+...+whatever. While the later might better fit to the release
>>>> process, it is not the case when it comes to contributions.
>>>>
>>>>        
>>> That raises the question: where will we find a database for tracing
>>> changes and providing some rationale?
>>> Mantis might be unefficient, but discussions in a mailing list does
>>> not cover much of mantis classification features.
>>> Can it be the work of the release team to classify and document the
>>> work from other guys? I bet they would soon be flooded.
>>> It's also important to trace why a change has not been accepted. A
>>> mailing list is too much a short memory and some subjects might come
>>> back recursively.
>>>
>>> Andreas' proposition is certainly worth a try, but I don't see yet how
>>> these questions will be addressed.
>>>
>>> Nicolas
>>>      
>> Good questions.
>>
>> For keeping up-to-date on what's happening to the trunk the RSS feed
>> is quite useful:
>>
>> http://source.squeak.org/trunk/feed.rss
>>
>> - Bert -
>>    
> Take an example
>
> - pick a goal of image minimisation.
>
> Andreas' way of doing it is to announce "minimisation" and let loose the
> team of squeak well wishers to target something to be refactored out.
> Methods wil be deleted and a new image will be released, albeit as a set
> of updated trunk packages.
>
> Those in other forks of squeak will be left with a process of forensic
> coding to work out exactly what was removed, why and how.
>
> My way of doing it is to pick a package or subsystem that needs to be
> unloaded, and to move all of those methods into a new package, save the
> package in a public place.
>
> Now, any fork of squeak can load that package, (re-organising the
> methods in the local fork), and then unload the package to perform the
> removal. Give or take the occasional fix needed to make this process
> work smoothly it does work.
>
> For an example of a package that has been targetted for removal this
> way, I took Edgars script in SqueakLight and used it to remove Nebraska
> in this manner. I also factored Object-Tracer.
>
> - pick a goal of image reorganisation
>
> Andreas way of doing things is to again let loose the team on the
> repository... Mine is to publish the task for re-organisation and allow
> the team to refine it until they are happy with it.
>
> e.g.
>             "reorganize Kernel-Object"
>             self category: 'MorphicExtras-SqueakPage'     classes:
> #ObjectOut.
>             self category: 'Kernel-Tracer'                 classes:
> #(ObjectTracer ObjectViewer).            
>             self category: 'Kernel-Model'                 classes:
> #(Model DependantsArray MessageSend WeakMessageSend).
>             self category: 'Kernel-Model-Tests'        classes:
> #(DependentsArrayTest WeakMessageSendTest).
>
> Keith
>  
Question, has Andreas even ever loaded "Tasks"?

I am going to take 3 weeks out

Keith

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

Ken Causey-3
In reply to this post by Nicolas Cellier
On Mon, 2009-07-06 at 10:07 +0200, Nicolas Cellier wrote:

> 2009/7/6 Ian Trudel <[hidden email]>:
> >
> > Besides, you're also missing the trick when it comes to contribution.
> > On one side, there is quick and simple community development process,
> > based on MC repositories, and on the other side, some matis+installer
> > mantis+...+whatever. While the later might better fit to the release
> > process, it is not the case when it comes to contributions.
> >
>
>
> That raises the question: where will we find a database for tracing
> changes and providing some rationale?
> Mantis might be unefficient, but discussions in a mailing list does
> not cover much of mantis classification features.
> Can it be the work of the release team to classify and document the
> work from other guys? I bet they would soon be flooded.
> It's also important to trace why a change has not been accepted. A
> mailing list is too much a short memory and some subjects might come
> back recursively.
>
> Andreas' proposition is certainly worth a try, but I don't see yet how
> these questions will be addressed.
>
> Nicolas
Nicolas, I share you concerns.  It should be remembered that I was one
of the major proponents of switching from using the mailing list as our
bug tracker to the use of a bug tracker and supported at least
temporarily settling on Mantis.

But the reality is that it has been years now and very very few people
in this community make use of Mantis and no viable alternative has
appeared.  You are certainly one of the exceptions but you are in small
company I'm afraid.

Perhaps this is just cynical of me, but one of my hopes with this
proposal is that by inviting in a larger part of the community to
participate in the process at a higher level we will engender a deeper
understanding of the issues.

This is going to take some time but I can see two likely results:

1.  I'll learn that I'm wrong and that the use of some tool like Mantis
and the level of administrivia that requires is not necessary to the
smooth working of the development on a project like Squeak.

2.  A greater portion of the community will learn the value of record
keeping that tools like Mantis provide and will be more willing to put
in the effort needed to use and improve and perhaps replace Mantis with
a more suited system.

Continuing as we were did not seem to be resulting in progress and in
fact seemed to be resulting in our losing ground.  I think it's time
that at least for a while we walk down another road.

Ken



signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

johnmci

On 6-Jul-09, at 10:49 AM, Ken Causey wrote:

> Nicolas, I share you concerns.  It should be remembered that I was one
> of the major proponents of switching from using the mailing list as  
> our
> bug tracker to the use of a bug tracker and supported at least
> temporarily settling on Mantis.
>
> But the reality is that it has been years now and very very few people
> in this community make use of Mantis and no viable alternative has
> appeared.  You are certainly one of the exceptions but you are in  
> small
> company I'm afraid.

Well for Sophie we made extensive use of Mantis, because it did work  
to collect bugs. Fixing them was another issue.

But I think you all miss the point that you need to make it easy. Why  
can't I have a submit walkback to Mantis or
to the Squeak Bug Reporting Czar? Or a menu item to submit a bug or  
feature request/whaterever on a menu somewhere.

Many times you are faced with some walkback you have no-idea why and  
there is no process to make the capture
of that easy, yet the environment would let me bundle that up and POST  
to a webserver somewhere, if there was support
for such a concept.

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

Ken Causey-3
On Mon, 2009-07-06 at 13:51 -0700, John M McIntosh wrote:

> On 6-Jul-09, at 10:49 AM, Ken Causey wrote:
> > Nicolas, I share you concerns.  It should be remembered that I was one
> > of the major proponents of switching from using the mailing list as  
> > our
> > bug tracker to the use of a bug tracker and supported at least
> > temporarily settling on Mantis.
> >
> > But the reality is that it has been years now and very very few people
> > in this community make use of Mantis and no viable alternative has
> > appeared.  You are certainly one of the exceptions but you are in  
> > small
> > company I'm afraid.
>
> Well for Sophie we made extensive use of Mantis, because it did work  
> to collect bugs. Fixing them was another issue.
>
> But I think you all miss the point that you need to make it easy. Why  
> can't I have a submit walkback to Mantis or
> to the Squeak Bug Reporting Czar? Or a menu item to submit a bug or  
> feature request/whaterever on a menu somewhere.
I don't miss that point at all.  But you have to realize that I don't
see a problem with using Squeak as it is.  I've made a video showing how
to do this at least in once scenario.  Does this mean I don't think it
could be easier?  Absolutely not, but it does mean that I'm not at all
certain what 'easier' means in this context.

For years how I have dealt with a number of situations where someone
comes up and says the equivalent of 'Mantis sucks'.  And so I then try
to engage them in a conversation designed at my understanding of what
about Mantis sucks in their opinion and how it could be improved.  Not a
single time have a been able to get a concrete proposal or explanation.

In this case you make a couple of suggestions.  I grant you that, but
actually implementing them requires significantly more fleshing out of
the proposals.

Ken

> Many times you are faced with some walkback you have no-idea why and  
> there is no process to make the capture
> of that easy, yet the environment would let me bundle that up and POST  
> to a webserver somewhere, if there was support
> for such a concept.
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================



signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

Ken Causey-3
Oops, I really need to proofread better: when I say "I don't see a
problem with Squeak as it is" I really mean of course "I don't see a
problem with  Mantis as it is".  Sorry for the confusion.

Ken

On Mon, 2009-07-06 at 16:04 -0500, Ken Causey wrote:

> On Mon, 2009-07-06 at 13:51 -0700, John M McIntosh wrote:
> > On 6-Jul-09, at 10:49 AM, Ken Causey wrote:
> > > Nicolas, I share you concerns.  It should be remembered that I was one
> > > of the major proponents of switching from using the mailing list as  
> > > our
> > > bug tracker to the use of a bug tracker and supported at least
> > > temporarily settling on Mantis.
> > >
> > > But the reality is that it has been years now and very very few people
> > > in this community make use of Mantis and no viable alternative has
> > > appeared.  You are certainly one of the exceptions but you are in  
> > > small
> > > company I'm afraid.
> >
> > Well for Sophie we made extensive use of Mantis, because it did work  
> > to collect bugs. Fixing them was another issue.
> >
> > But I think you all miss the point that you need to make it easy. Why  
> > can't I have a submit walkback to Mantis or
> > to the Squeak Bug Reporting Czar? Or a menu item to submit a bug or  
> > feature request/whaterever on a menu somewhere.
>
> I don't miss that point at all.  But you have to realize that I don't
> see a problem with using Squeak as it is.  I've made a video showing how
> to do this at least in once scenario.  Does this mean I don't think it
> could be easier?  Absolutely not, but it does mean that I'm not at all
> certain what 'easier' means in this context.
>
> For years how I have dealt with a number of situations where someone
> comes up and says the equivalent of 'Mantis sucks'.  And so I then try
> to engage them in a conversation designed at my understanding of what
> about Mantis sucks in their opinion and how it could be improved.  Not a
> single time have a been able to get a concrete proposal or explanation.
>
> In this case you make a couple of suggestions.  I grant you that, but
> actually implementing them requires significantly more fleshing out of
> the proposals.
>
> Ken
>
> > Many times you are faced with some walkback you have no-idea why and  
> > there is no process to make the capture
> > of that easy, yet the environment would let me bundle that up and POST  
> > to a webserver somewhere, if there was support
> > for such a concept.
> >
> > --
> > =
> > =
> > =
> > ========================================================================
> > John M. McIntosh <[hidden email]>   Twitter:  
> > squeaker68882
> > Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> > =
> > =
> > =
> > ========================================================================
>



signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

Ian Trudel-2
2009/7/6 John M McIntosh <[hidden email]>:
> Well for Sophie we made extensive use of Mantis, because it did work
> to collect bugs. Fixing them was another issue.

This clearly express the current challenge. Mantis has an organized
and traceable approach with issues but if one has to file in an issue,
fix it, submit a fix, wait indefinitely the fix is integrated, then it
makes the contribution nothing like "quick and simple". Mantis is
first and foremost a solution in a release process.

> But I think you all miss the point that you need to make it easy. Why can't
> I have a submit walkback to Mantis or
> to the Squeak Bug Reporting Czar? Or a menu item to submit a bug or feature
> request/whaterever on a menu somewhere.

John, this is an idea. I am inclined to believe that a solution
integrated within Squeak has increased chances of success.


2009/7/6 Ken Causey <[hidden email]>:

> For years how I have dealt with a number of situations where someone
> comes up and says the equivalent of 'Mantis sucks'.  And so I then try
> to engage them in a conversation designed at my understanding of what
> about Mantis sucks in their opinion and how it could be improved.  Not a
> single time have a been able to get a concrete proposal or explanation.

Sometimes having meaningful suggestions also mean to extensively use a
certain tool. And it seems obvious that those who claim "mantis sucks"
are unlikely to extensively use it.

> In this case you make a couple of suggestions.  I grant you that, but
> actually implementing them requires significantly more fleshing out of
> the proposals.

The more suggestions we get, the closer we are from a workable
solution. Hopefully. =)

Regards,
Ian
--
http://mecenia.blogspot.com/

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Re-liason proposal

johnmci
In reply to this post by Ken Causey-3
> I don't miss that point at all.  But you have to realize that I don't
> see a problem with using Squeak as it is.  I've made a video showing  
> how
> to do this at least in once scenario.  Does this mean I don't think it
> could be easier?  Absolutely not, but it does mean that I'm not at all
> certain what 'easier' means in this context.
>
> For years how I have dealt with a number of situations where someone
> comes up and says the equivalent of 'Mantis sucks'.  And so I then try
> to engage them in a conversation designed at my understanding of what
> about Mantis sucks in their opinion and how it could be improved.  
> Not a
> single time have a been able to get a concrete proposal or  
> explanation.
>
> In this case you make a couple of suggestions.  I grant you that, but
> actually implementing them requires significantly more fleshing out of
> the proposals.
>
> Ken


What's missing is the simple part, I can see it as.

(a) download a developer image

(b) start it up, you get asked say you want to be a developer and  
contribute? Yes -> collect that information, MIT license agreement etc.

(c) walkback/whatever -> send that information off to the Squeak Bug  
Czar?   At this point I don't care too much what the information is
given (b) who ever sits in the role of the Bug Czar can email back to  
the person and collect more information.  As you've realized once
you can talk to the person you can get them to do what is required.


--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





12