German Morales <germanmorales at delta-sys.com> wrote:
> It seems that Daniel Vainsencher wrote:
> > First, add the [cd] tag - you've done the work (the changes are
> > documented), make it explicit.
> 
> Yes, but:
> 
> -should I add my big comments to the change set preamble?
Yes.

> -what about things that I say are fixed in following change sets? should I
> merge the fixes so you can accept MCP0001 safely?
Not sure I understand the nature of the dependency. To accept patch A,
it needs to not depend on anything else that's not accepted already.

If MCP0001 can be added, and then adding MCP0006 makes it cleaner, that
ok. 

If something is broken until I also accept 0006, that's not ok, and you
should either split 0001 until it doesn't break stuff, or merge it with
0006. I prefer the former.

> > I would understand it much better like this -
> > ***********
> > Enforce existing "template method" pattern for Morph>>initialize and
> > Morph>>basicInitialize.
> > Extend it to initialize bounds and border properties in addition to
> > color.
> > In the process, removes most direct accesses to the relevant variables,
> > setting the stage for protecting those variables completely.
> > ***********
> 
> Well, what is clearer is somehow subjective, but we will try.
:-) Maybe that's not the best wording either... I don't care about the
style or pattern language that much - just be explicit about the logical
connection of the changes you make, so it's clear that it's one coherent
change. Again, this isn't a requirement, I'm just trying to help you
"advertise" how simple you've already made the change set.

> > If you think its ready, send it to the list as a [FIX] (until we get
> > sqfixes to harvest automatically the [REFACTOR] flag), with the [cd][er]
> > flags. Since it seems simple and well documented to me, I'll give it
> > priority.
> 
> Ok, depends on previous questions.
> Thanks for your comments Daniel,

I hope we'll get many changes as well structured and documented as
these.

Daniel