From Red Tape to No Tape - Part 2: A Self-evaluation to Recognize Organizational Misalignment with Agile Values

From Red Tape to No Tape - Part 2: A Self-evaluation to Recognize Organizational Misalignment with Agile Values

And here's the second part.

Here are a couple of contrasting elements of each company structure:

Bureaucratic vs. Post Industrial (Agile)

Hiring is viewed as fulfilling an immediate skill set need.

Hiring is viewed in the long term with cultural fit and individual contributions outside of skills being considered.

Language in the meetings focuses on I, me, individual contribution.

Language in meetings focuses on team and collective contribution.

maven release plugin

It's magic, yes, but for the odd piece.

When I'm ready to send a release candidate to QA, I expect to make a release branch. Mainline development can continue, and if I need to fix a bug QA has found I can make it in the branch and merge it to trunk.
When I think of vcs "tags," I think of some marker that indicates that a release was made from "this revision."

It seems that the maven release plugin expects that your code is perfect when you've run "mvn release:prepare." For subversion, it creates an "svn copy" in your "tags" directory. While in svn, that's no different from a copy in a directory of any arbitrary name, it, by convention, implies "no further work in this copy."
So that's sort of in conflict with how I want to use it. I want it to make an "svn copy" in my "branches" directory, because I expect I might need to patch it.

You can set a "tagbase" variable to point to your "branches" directory, but while it (presumably) works if you set it to something arbitrary (say, "mytags"), it doesn't work when you set it to "branches."

So, I've just "gotten over it," and I'm using "tags" for release candidates that might get modified.

:(