branches to merge

jerry gay jerry.gay at gmail.com
Thu Sep 3 04:49:29 UTC 2009


On Wed, Sep 2, 2009 at 18:21, Andrew Whitworth<wknight8111 at gmail.com> wrote:
> We have two branches that reached maturity today and are ready for a
> merge in to trunk. I want to run past the team first before anything
> gets merged anywhere.
>
excellent news.  thanks for letting us know about it.

> The first, which we've already heard about, is bacek's context_pmc3
> branch. This turns the Parrot_context structure into a new Context PMC
> type. Among other benefits, this should plug all instances of leaking
> context memory. This branch is bigger and older of the two, so if
> we're able to do any merging I want to merge this one first.
>
agreed.

> The second. kill_parrot_cont, is from newcomer jrtayloriv, which does
> some cleanups to the Continuation PMC. Continuation PMCs previously
> had a single ATTR, which was a pointer to a Parrot_cont structure. His
> branch simplifies this, we now don't have a Parrot_cont structure at
> all, the fields of it are now ATTRs of the Continuation PMC proper.
> This should help decrease calls to malloc(), which in turn should be
> good for performance (though I have done no benchmarking to prove
> this). jrtayloriv is new to Parrot, so I would like people to check
> out his work and give him lots of good feedback about the branch.
>
cool!  i look forward to the benchmarks.

> Both of these branches are just the first steps of larger cleanup
> efforts needed in these systems. The earlier we get in trunk, the
> faster we can get started on the next steps.
>
> Both of these branches are ready to merge as of this evening. If they
> are going to happen, I would like them to go earlier rather then later
> so we can make sure trunk is completely stable for the 1.6. release in
> 2 weeks. These last two weeks have been a little bumpy, so we should
> be a little extra cautious that everything stabilizes before 1.6.0.
>
agreed, but i want to suggest an approach, in order to have a better
chance at stability, as well as a fighting chance at debugging these
changesets in (almost) isolation, let's plan on merging these branches
a few days apart, following a pattern something like this:

~ announce each merge on the list as it happens, and request smolder runs
~ keep an eye on smolder failure reports, and prioritize fixes for
bugs due to branch merges above all else
~ keep everyone informed, by creating, updating, and closing tickets
for related issues
~ be clear in ticket descriptions and updates, as well as commit comments
~ do not merge another branch if the currently merged branch is still
causing regressions
~ achieve general agreement that the merge is successful publicly, on
the mailing list

i'd prefer to have at least two business days between each merge.  i
don't see a reason to wait in merging the context_pmc3 branch, as we
have a history of smolder reports on trunk right now, and good reports
from multiple platforms on that branch as well.  let's get that branch
in soon and run smolder against trunk.

agreed?
~jerry


More information about the parrot-dev mailing list