CVS and the CVS emails should be the primary reference for the changelog, since these are kept automatically. Not everything goes through Bugzilla. Erik Hatcher mentioned that Ant can generate a summary changelog from CVS, but I haven't tried it yet.
As far as tests and documentation go, there is a general consensus that new features should breed new tests. When possible, bugfixes should generate new tests too. Although, since Struts was not designed for testability, creating such tests can be a challenge. We should at least be running the tests we have around any change or commit.
However, at this point, I believe the Cactus tests are broken and that James Mitchell may try to fix them soon.
Since we are in an evolutionary mode right now, it not strictly necessary to obtain a vote on new features. But, it can save the trouble of backing the change out if it turns out to be something another Committer would veto. The hardcore Apache projects rarely vote on anything except releases. The decision-making is consensus-based through general discussion on the development lists. People use terms like +1 and -1 in the discussions, but its not so much a vote as an indication of how they would vote, should a vote occur.
So, if you used tests as part of developing the feature, then please commit those too. Or, if you see a test suite that could be extended to include the new feature, please add the test.
Unless we are going to try automating the changelog with Ant, then it would be helpful to update the changelog as well (creating a new one if needed).
Under heading "observe the style of the original", please make sure that any submission is fully Javadoc'd. If possible, please also update the user guide as to the existence of your feature, relying on the Javadoc for base material.
If the feature was covered by a Bugzilla ticket, then please resolve the ticket. It's been suggested that if a feature was not registered in Bugzilla, then we should create one for it, but I'm not sure that we've developed a behavioral consensus on that. =:)
-Ted.
Don Brown wrote:
I'm familiar with the process of bringing up new features to the group as it is documented on jakarta's site: http://jakarta.apache.org/site/decisions.html
Rather, I was interesting in what the Struts process once the feature is committed. I would assume the following areas would be affected: - tests - changelog - documentation - bugzilla
Don
On Sun, 28 Sep 2003, Robert Leland wrote:
Don Brown wrote:
What is the process when adding a new feature (in this case, wildcards for action mappings)?
Create a Subject: [Proposal] wild cards for action mappings.
Use lazy Consensus. At least 3 +1 votes, no -1 votes. There is a doc somewhere that says when to use each type of vote. Also I thought we already discussed this and it's addition was approved ?
Do we wait until a release is ready to update the documentation or update it when the feature goes in?
I would say nightly Docs should always match the nightly source
Also, I couldn't really find a changelog.
If you have maven you can now build the top level struts documentation which includes a generated change log.
Do we just use bugzilla to track new features? If so, should an enhancement request be made before a feature gets added?
No.
If this information is already on a webpage somewhere, I apologize in advance :)
I would like to know that answer also.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
