On Dec 18, 2006, at 10:37 PM, Jason Dillon wrote:
For the M1 release I would have said close enough and made the
final release from trunk.
But changing the tag is harmful by itself by setting precedence...
something which should not be followed, yet unless people
understand why, they will just continue along those bad practices.
And technically speaking, making a change to a branch or hacking up
a tag should have the exact same effect on any work that anyone
might need to redo for a release. And really we could thump the
rule book on the ci to tags too... which is pointless for this
release. The important thing is that people understand that its
not appropriate to alter a "tag" in that manner. This is a pure
policy argument, as technically from the release perspective is
identical using svn, in both cases, the release must be re-cut, re-
approved, blah, blah, blah. And in general for release tags, it is
best to treat them as read only.
We're all on the same page...I weighed the change versus lost sleep
and my marriage. The commit won :)
--jason
On Dec 18, 2006, at 5:53 PM, David Blevins wrote:
On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:
Process of branching and tagging (we already have a plethora of
discussion...I think this needs to get on a Wiki)
- includes tags and modifications
Discussion, proposal, resolution and final vote.
http://cwiki.apache.org/GMOxPMGT/release-branching-process.html
Thanks David...this is what I was referring to and I don't think we
need to go through it again. I forgot it made it to the Wiki.
Granted that was June, just about time to do it all over again :)
In regards to the commit to the tag, I don't have a problem with
it as it was completely ineffectual in any technical sense. We
could of course thump the rule book and make Matt redo 8+ hours of
work and have days worth of revoting followed up by a couple weeks
worth of cumulative man hours on policy discussions... or we could
just say "close enough" and focus on 2.0-M2.
-David
Matt Hogstrom
[EMAIL PROTECTED]
