On Mon, Dec 6, 2010 at 10:42 AM, Grant Ingersoll <[email protected]> wrote:
> Our new Changes could be structured like below. The important thing about > this approach is that it can all more or less be written at release time > other than the contributor list and perhaps the back compat section. Well this is important about the approach: and scary. Typically if we add/change something and we do it incrementally, we might add 50 jira issues till we get where we want. But at the end of the day the user doesn't care about our experiments/refactoring/incremental improvements, only the end user-affecting change. if we move to this, it puts quite a burden on the release manager to edit the jira-generated list determine which issues/how to describe the "end feature" that the user needs to know about... today, every committer is responsible for presenting their changes in CHANGES.txt in a way that makes sense to the user, and I think this is easier since they were the one working on it, and its fresh in their mind. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
