On 2015/03/10 22:31:06, michael_dawson wrote:
On 2015/03/10 14:06:46, michael_dawson wrote:
> On 2015/03/10 13:45:14, Sven Panne wrote:
> > On 2015/03/10 13:32:38, michael_dawson wrote:
> > > I can see once we are caught up and can get them in more quickly
> > > it may be easier but for now its going to be a reasonable amount
> > > of extra work for us since we have to strip out the parts that
> > > are not accepted yet and then apply the changes to a code base
> > > that is behind our repo. Is there a way to avoid doing them
> > > sequentially?
> >
> > OK, to speed things up, we can make an exception for this CL: Split
off
the
> > controversial serializer part and have a single catch-up CL for the
rest.
But
> > for upcoming tracking CLs in the PPC part, we really want to have them
> > separately, just like for MIPS. We don't want that to torture you,
quite
the
> > opposite: :-) There is basically no such thing as a "trivial CL" in
v8,
and
> you
> > *will* have to revert your own stuff quite often. With combined CLs,
this
will
> > be no fun. Furthermore, it happens from time to time that *we* revert
some
> > stuff, so we/you would have to undo the corresponding change in the
PPC
part,
> > too. Again, this is highly complicated for combined CLs. We learned
that
the
> > hard way, and that's why we're strict about that regime by now. :-}
>
> Thanks, will start to create that review now.
> >
> > > From what I understand so far I think I'll have
> > > wait for one to be accepted before I can create the next in most
> > > cases as there may be dependencies
> >
> > There shouldn't be too many dependencies between the CLs tracking the
rest
of
> > the v8 changes, at least that's how it was in the past.
> >
> > > and if I pull in earlier changes
> > > before they are accepted those would show up in the later review
> > > as well.
> >
> > Technically you can set up the base URL to stack CLs onto each other,
but
this
> > gets confusing quickly, so I wouldn't recommend it. When things are
settled
> down
> > and you are an OWNER of the PPC subdirectories, the turnaround times
should
be
> > small, anyway.
>
> We've already been committing the changes required
> for each common code change in separate commits in our repo.
> Once we can turn them around quickly in the google repo as well it
should
> be much easier to commit them separately.
Ok new review just to bring us to to current.
https://codereview.chromium.org/994533004/
I assume once that's in we can get comments on what we outlined in the
google
doc for
how to address the changes in serialize.cc. We had to exclude the test
test-serialize/SerializeInternalReference as it requires the proposed
change
to
be able to
pass for PPC.
Any chance you've had a chance to review:
https://docs.google.com/document/d/1Qs7bcehIhUSl80TnUautl_VQym-At4rD42YL1r5crzI/edit
https://codereview.chromium.org/986553005/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
