> All right, I've created a donut-plus-aosp branch, which currently
> contains the state of master (pre-eclair-merge). Its evolution will be
> restricted to code drops from Google and changes which help build it
> on commonly supported systems (i.e. MacOS or Ubuntu).
> JBQ
> On Fri, Nov 13, 2009 at 9:44 PM, Jean-Baptiste Queru <j...@android.com>
> wrote:
> > So far, there hasn't been a good process to deal with that. In a
> > nutshell, donut and eclair and mirrors of Google's internal trees of
> > the same name (or snapshots of those trees), and as such aren't meant
> > to receive contributions (since contributions would block the
> > mirroring process or would get deleted by the snapshot process).
> > Getting contributions back into Google's donut and eclair trees isn't
> > likely to happen, since those trees are tightly controlled (many
> > layers of approvals).
> > We've had cases in the past where two codelines (one more stable than
> > the other) were relevant for the community: e.g. at some point in time
> > the donut branch couldn't be used on hardware but cupcake could;
> > unfortunately we didn't have any mechanism in place for the community
> > to keep using a variant of cupcake that had received community
> > contributions on top of it.
> > At the time, an additional level of complexity was that the cupcake
> > tree at Google wasn't maintained within git. That issue has
> > disappeared since both donut and eclair have been developed uniquely
> > in git for a long while. Also, I got a lot more familiar with git and
> > I was given a lot more freedom to deal with such situations, so it's
> > actually practical to think about solutions.
> > The solution I have in mind is to branch the current master tree as a
> > "donut + community fixes", before I merge eclair into master. That new
> > branch would be controlled very tightly and wouldn't receive changes
> > other than the kind of build fix that you have in mind.
> > Some of this is still fuzzy in my mind, so plans could still change,
> > but I'd like to move in that direction (and if we don't get it right
> > for donut we'll do better next time - in the worst case this costs me
> > half an hour of branch setup, it's not the end of the world).
> > JBQ
> > On Fri, Nov 13, 2009 at 8:34 PM, Chad Fawcett <c...@useless.net> wrote:
> >> Curiosity question...if a change has been made in master which might be
> >> worthwhile pulling into donut or eclair, is there a recommended process
> to
> >> follow? I can do it locally, I'm talking about submitting back into
> gerrit.
> >> For example, there are 2-4 patch sets (depending how custom your local
> >> setup), currently only for master, used to cleanly build on OS X 10.6.
> One
> >> has been master merged and 2-3 more are going through review and
> revision in
> >> gerrit...for arguments sake though, let's say they're through all that
> and
> >> have already all been master merged at this point. They don't add new
> >> functionality per se, they're tool set fixes..Should I pull the patch
> and do
> >> a branch-specific commit for review? Should I ask the original change
> set
> >> submitter or verifier to do so? Should we all just move on and stick
> with
> >> master?
> >> In the case of eclair, I can definitely understand if it makes sense to
> wait
> >> till after much of that branch has been merged into master to avoid
> >> noise/conflicts, but for donut, could a submit of the change go in now?
> >> -Chad
> >> --
> >> Chad Fawcett
> >> http://twitter.com/chadfawcett
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "android-platform" group.
> >> To post to this group, send email to android-platform@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> android-platform+unsubscribe@googlegroups.com<android-platform%2Bunsubscrib e@googlegroups.com>
> .
> >> For more options, visit this group at
> >> http://groups.google.com/group/android-platform?hl=.
> > --
> > Jean-Baptiste M. "JBQ" Queru
> > Software Engineer, Android Open-Source Project, Google.
> > Questions sent directly to me that have no reason for being private
> > will likely get ignored or forwarded to a public forum with no further
> > warning.
> --
> Jean-Baptiste M. "JBQ" Queru
> Software Engineer, Android Open-Source Project, Google.
> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.
> --
> You received this message because you are subscribed to the Google Groups
> "android-platform" group.
> To post to this group, send email to android-platform@googlegroups.com.
> To unsubscribe from this group, send email to
> android-platform+unsubscribe@googlegroups.com<android-platform%2Bunsubscrib e@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/android-platform?hl=.
