Why do we want this?

To be able to push stuff in mozilla-central quite easily.

That approach would make it hard for people to test new APIs. It's also not going to help keep the WIP code from rotting, since the MOZ_WEBAPI code would be invisible to patches landing on m-c. I had an envisioned a workflow something like - iterate in bugs/patch queue/project branch until API X is ready for feedback - land on m-c, pref'd off - iterate moar until full spec and impl are done for X - pref on What are the issues you see in an approach like that?

(In reply to Chris Jones [:cjones] [:warhammer] from comment #3) > That approach would make it hard for people to test new APIs. It's also not > going to help keep the WIP code from rotting, since the MOZ_WEBAPI code > would be invisible to patches landing on m-c. Right, these are my concerns as well.

What about changing MOZ_WEBAPI to MOZ_WEBAPI_EXPERIMENTAL and move stuff out of MOZ_WEBAPI_EXPERIMENTAL as soon as they are ready for feedback. My main concern is that a project branch might be more annoying than helpful (at least for the moment).

My instinct is to not bother with MOZ_WEBAPI/MOZ_WEBAPI_EXPERIMENTAL until we run across cases where there's a bunch of code we want to land on m-c that's not at all ready for feedback. I'm not really sure what that kind of code would look like. What code would you want to land on a project branch initially, if one were created?

I have some code to send SMS and place calls that is rotting in my patch queue. I guess I should just keep it here then...

How will it be less rotting if we stick it in the tree but don't try to build or test it?

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #8) > How will it be less rotting if we stick it in the tree but don't try to > build or test it? Boilerplate code bitrotes quickly and that often requires to fix the local patch queue. Though, I believe I'm quite alone to think it would help so I will just mark it as WONTFIX.