Hi Andreas!

"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Hi Göran,
> 
> > I am not sure what you mean. The Guide wouldn't just decide 
> > the issue - but he/she would make sure the ball is kept
> > rolling and discussed and eventually also is responsible
> > for boiling down a decision from it all.
> 
> Agree. But the question is (dare I say it again? ;-): Which process? How are
> decisions made?

You definitely dare! And the answer is - I don't know yet. :-) I need to
read about the Fishbowl-whatever and hopefully guys like you can give
more feedback.

My proposal was just a first single step. I didn't say more on purpose.
In Python I think Guido acts like a benevolent dictator - like Linus I
suppose. But I am not sure such a model would fit our community. Again -
I don't know yet.

But putting the PROPs mechanism in place with a Guide responsible for
managing them and keeping track of them we would at least have taken a
first step. And then we can proceed by actually taking PROPs regarding
the process itself. Again - I want you to note that PROPs aren't only
for discussing code etc - they should be used for any decisions we take,
especially those that govern our own processes.

> > And we are talking about a *general decision process* for the 
> > community regardless of issue at hand - I can't see what
> > "reducing the image" has to do with this.
> 
> I understand that this is a more general process but it seems to me that
> we're doing just fine for a large part. For example, I could have posted a
> [PROP] requesting that we come up with some process for solving these issues
> but there seems to be a general agreement on discussing these issues right
> here (or at least I haven't seen anyone saying "please shut up and discuss
> it elsewhere" ;-)
> 
> In other words, it seems as if the "itch of the day" is about what happens
> with contributions and that's why I was concentrating on these issues.

Sure, ok - just as long as we are clear on the generality here.

> > But anyway - "including package XYZ." can mean different things.
> 
> Right. And I want to figure out what people can expect in this area. That's
> what my note was all about.
> 
> > Since you are mentioning the update stream it sounds like you meant 
> > "stuff it into the minimal/basic/full image".
> 
> That'd be one way of dealing with it.
> 
> > But if you instead meant "make package XYZ be a part of the official
> > Squeak" it would mean that package XYZ, depending on its nature, would
> > be a part of minimal/basic/full *as a package*.
> 
> That'd be another way of dealing with it.
> 
> > And secondly, if XYZ is an enhancement to code currently in the
> > image (and said code will of course eventually be turned into a 
> > package) then we can lift it into the updatestream as long as it
> > doesn't go against the partitioning effort.
> 
> That'd be a third way of dealing with it.

No, that would be exactly the same as the "first" way. But whatever -
the only point I was trying to repeat here is that enhancements to code
that currently hasn't been partitioned into packages should IMHO go into
the update stream *as long as that doesn't hurt the partitioning
process*.

This means that enhancements need to be reviewed with that in mind.

> All in all, there are various ways to go about these issues but it needs to
> be understood what the process is and what happens in the course of the
> process.

Right. Obvously we need to make the current "policy" more clear and
possible revise it.
But personally I thought the posted plan for 3.6 was pretty clear on
what we are doing.

> Cheers,
>   - Andreas

Cheers, Göran

PS. Just so everybody understand - I am still waiting for responses on
this thread. Especially from the other Guides. Before I have those
reactions I will not go forward on these "two pills and a promise". But
I am replying to every and all responses in this thread because I feel
this thread is important.