On 03/30/12 16:27, Robert Collins wrote:
I have a few questions inspired by the events that lead to at least
two of our forks, and various experiences in Ubuntu.
How do we preserve our velocity while working with upstream? Do we
wait for upstream to be totally happy before we move forward? Do we
monkey patch? Do we have a transient fork?
What should we do when upstream are hard to work with? E.g.: they've
broken API compatibility in trunk and our patches vs trunk are totally
different to patches vs what we are using, and upgrading what we're
using is nontrivial .... and trunk isn't releasable? Or what if they
only release once a year, or if they really don't want our patch? Or
if they want to polish the patch a great deal more than we need it
polished, before they'll consider landing it?
I've experienced some of the frustrations you allude to here as well
(and really great upstream experiences, of course).
Most of the observations and questions from my email were of the "well,
you've decided to fork, now what" variety. The observations lead to one
approach to answering the questions you give here: you should put up
with the difficulties of working with upstream until you estimate that
the long-term cost of maintaining a *good* fork (branches updated, tests
maintained, new tests added) seems less. That's a pretty big cost, but
I can think of at least a couple of instances in which it might have
been arguably less.
What if upstream aren't in bzr? How do we 'make a branch' there?
(Thanks to imports, that's usually not a big problem IME. I can imagine
exceptions.)
Would we upgrade a dependency for a service that is working fine and
has no other work planned for it?
As I said, our current inclination is approximately what someone
advocated (and reportedly practiced) in canonical-tech: if the upstream
is healthy and moving, yes, upgrade regularly. It should be a big,
conscious decision not to do so.
That's my current guess. <shrug>
Gary
_______________________________________________
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
