Ge van Geldorp wrote:
Yes, that is what RC1 is for. It is supposed to be made immediately after branching, when entering feature freeze. It's status is basically no more than that of a random svn version. Perhaps "RC1" is a misnomer.
<snip>
Perhaps we should call it "FF" (Feature Freeze) instead and rename RC2 to "CF" (Code Freeze)?
My understanding of RC in the software world is a Release Candidate, meaning we have removed every bug we could find and we think this software is now ready for release.
Therefore I think RC gives out the wrong impression and should not be used. Code Freeze or Preview Release sounds good to me.
However, I have decided to no longer continue as TC, if I was even TC to start with.
I am really sorry to hear this and hope you will reconsider.
I also hope you will reconsider. IMO, the assignment of a TC has proven to be one of the most successful ideas I've seen since I started following the project. The work you have done so far has been fantastic and I would like to see it continue.
Ged.
************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster@exideuk.co.uk mailto:postmaster@exideuk.co.uk and then delete this message.
Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com
Here's a combination of various suggestions to hopefully begin to close this matter:
1) Go with Gé's suggestion and rename our candidates to x.x.x-FF and x.x.x-CF respectively.
2) TC has no power to block FF - doesn't make sense to do so.
3) TC has power to block CF, subject to be overruled by a vote should a majority feel it is not critical enough.
4) No matter which way we enter CF, it takes an informal vote on the ML to drop back to FF for major discovered bugs - but any single developer can request and be granted a formal vote.
Andrew, would you still be willing to run for TC and continue the absolutely fantastic work you've done there given these, assuming everybody would agree to them?
From: Royce Mitchell III
Here's a combination of various suggestions to hopefully begin to close this matter:
- TC has power to block CF, subject to be overruled by a
vote should a majority feel it is not critical enough.
Sorry, I still think this is fundamentally wrong. It's the developers as a collective which run this project. It's the developers as a collective (and this includes the TC with his vote) which should make this decision. If you're going to give final decision making capability to the devs anyway, why put the TC in the middle? If the devs are going to overrule him anyway, there's a big chance that the vote would piss off the TC (especially if it happens a few times in a row). I know I would find it much easier to accept a collective decision, rather than a collective decision explicitly overriding a decision I made earlier. To get this moving forward, perhaps 2 proposals should be voted on: proposal A which gives TC blocking power (overrulable by a vote) and proposal B which does note give the TC that power. Instead of a yes/no vote on a single proposal we can then vote either A or B.
Andrew, would you still be willing to run for TC and continue the absolutely fantastic work you've done there given these, assuming everybody would agree to them?
In the scenario above (A/B vote) Andrew could wait for the outcome of the vote and then decide whether he wants to fulfill the TC role. I hope he will, but I understand he would want to know exactly what he signs up for before committing himself.
Gé van Geldorp.