[ros-dev] [VOTE] Miscelanea branches

[Mike Nordell]

Sorry if this became a bit rant-ish, but I had to get it off my chest.

Casper Hornstrup wrote:

> Should we allow branches (other than trunk) with mixed new development
> and bugfixes unrelated to the new development that is on the
> branch (miscelanea branches) ?

While I'd love to cast a vote on this issue, I recognize the world is not
binary (black and white), but rather shades of gray (~2^10 for human
perception, http://www.gamedev.net/columns/hardcore/hdrenvmap/).


If such bugfixes are indeed _completely_ unrelated to the new (or fixing)
development of the branch, then I'd say they should be committed to
trunk/head/<whatever_you_call_it>. But that does in no way or form imply the
use of "miscelanea branches" invalidated.

Often however, and I speak from personal experience here, new (or
correctional) development for something specific (let's call this set of
changes S) in one area (A, member of S) will find problems in other areas
(B, C). If such problems are indeed of the kind that they affect A to the
extent the author considers B&C in need of fixing before A can be completed,
then the set S is by necessity extended to become A,B,C. So what was
initially perhaps unrelated, has now become integral, and vital.

While I potentially could fix them in the trunk in order C,B,A, it
would be very confusing for bystanders to see me committing C code that
seemingly only restructured locking and/or started using unrelated locking
primitives for no seemingly valid reason, while having the whole change set
for A only locally on my own machine(s). Same for B. Not until A is
committed into trunk would those changes make sense.

I also think a branch, which can be used as a public repository of local
changes, is to prefer over e.g. me just hacking away at home - not sharing
any code until a later date, and risking every byte of it due to e.g. a
hardware failure. Putting such code in a repository branch where it both can
be viewed by others to see the direction I'm taking, and for safekeeping
(assuming one trusts the
repository), is in my mind a superior alternative to the (possibly
hazardous) options.

This is btw no free-form fanatasy, this is based on personal experience
(with the difference the "branch" was only held on my local computer, where
noone at all could see what I did, and when a hardware failure hit me I lost
most of it, and steam, why nothing of it ended up in the repository). A was
fast mutex, B was Cc, C was Mm, and in addition to this a number of other
areas also ended up needing modifications.


So why did climb the soap box again? To try explain my view, and experience,
that we do not live in a binary world, and with such deep dependencies, new
or fixed code in one area might have impact on code in areas initially
completely unrelated, but due to dependencies becomes an integral part of
the initial set.

But to at least excercise my right to vote, I vote "None of the options".
This I think is, or should become, a valid alternative, since it displays I
have excercised my right to vote, and participated in the voting procedure,
but not agreed with any of the presented alternatives enough to stand behind
them. In part, this decision is due to the impreciseness of the question,
and the not 100% crystal clear definition of "miscelanea branches" (I can
see at least two interpretations of it).

/Mike

P.S. If following up, please don't over-quote, and please use only
plain-text for the western locale(s).