On 2015/03/11 14:38:12, michael_dawson wrote:
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
I think we can close this issue as being resolved as of
https://codereview.chromium.org/1008963002/
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.
