Once upon a time, I made a point of updating the changelog, but during
that death march affectionately known as the Struts 1.1. release =:), I
fell out of the habit, and haven't picked it up again. Back in the day,
some thoughtful people also tried to update the changelog as they made
the commits.
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]
