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?
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).
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?
> 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.
> For more options, visit this group at
> http://groups.google.com/group/android-platform?hl=.
Isn't it time to consider posting a branch-flow picture (similar to
Gerrit workflow http://source.android.com/submit-patches/workflow) ?
We are with cupcake/donut/eclair/AOSP flavors, and it will be a huge
help for everyone to quickly grasp the big picture.
A quick hand drawn whiteboard diagram, captured in your Android device, maybe?
-Jey
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?
>> 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.
>> For more options, visit this group at
>> http://groups.google.com/group/android-platform?hl=.
> 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.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=.
Yes, we need to do that - I'd rather do it as the situation stabilizes
a bit, instead of capturing the exact state right now and have it
become obsolete in a few days.
On Sat, Nov 14, 2009 at 11:53 AM, Jey Michael <jey.mich...@gmail.com> wrote:
> Isn't it time to consider posting a branch-flow picture (similar to
> Gerrit workflow http://source.android.com/submit-patches/workflow) ?
> We are with cupcake/donut/eclair/AOSP flavors, and it will be a huge
> help for everyone to quickly grasp the big picture.
> A quick hand drawn whiteboard diagram, captured in your Android device, maybe?
> -Jey
> 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?
>>> 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.
>>> For more options, visit this group at
>>> http://groups.google.com/group/android-platform?hl=.
>> 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.
>> For more options, visit this group at http://groups.google.com/group/android-platform?hl=.
> --
> 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.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=.
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).
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?
>> 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.
>> For more options, visit this group at
>> http://groups.google.com/group/android-platform?hl=.
> 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.
> 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?
> >> 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=.
> > 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.
> 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=.
