> Please feel free to make a proposal for another way to organise thing, > a way that would suit you more. Even if I tend to be quite insistant > on the way I think things should be, I always take into account the > other persons opinions. > > As said, what matters to me is: > 1. to have an easy way to follow the development, useful in > development management > 2. to have an easy way to make release and to give to user an > overview of important changes, or changes they are expecting > > Currently ChangeLog address point 1, ChangeLog.byversion address point > 2. The first is generated so it is not really time consuming. The > second is hand-filled but cannot seriously be generated by the commits > since it frequently groups different items. > > If you come up with a proposal that address these two points, I'll > will not object.
Ok, here's my point. To recap: currently, fixing a bug <=> 1) describe the issue in a new tracker item 2) fix the issue 3) describe the issue in ChangeLog.byversion 4) describe the issue in the commit message 5) close the tracker item (I didn't mention discussing the issue with other developers) Based on my experience, I'd tend to disagree: - It can take more time to describe the issue than fixing it. Well, at least it does take time to write the same thing in three different places. - When people (eg. you) actively work on the project, I use to turn all mailing lists into digest mode to avoid being 'spammed' :) by numerous notifications, and I have to browse through redundant or trivial notifications. This feeling may be exaggerated by the fact I received a blank notification each time a dependency of an item was changed. - As a user, I never had the patience to read ChangeLog.byversion (1.0.4.2 to 1.0.5, for example, being around 200 lines long). What I would do is: - fix the issue - document it with the commit message And during the release process, reread the ChangeLog and update a NEWS file with the most important changes in the release. User should be able to see at a glance what are the important changes that concerns them, and should not have to dig into an exhaustive (and exhausting ;)) list of changes. In the case of Savane, I would also add additional update instructions (eg changes in site-specific/) in updates/. It is possible to provide adequate content for all kinds of users, but given the redundancy of the work and the time it consumes, I tend to provide maximum (ChangeLog) and reasonable (NEWS) verbosity only. As for items, I think they are worth opening only when the issue needs to be discussed among developers, or has to be described extensively. Point 1 is CVS (and the associated ChangeLog) Point 2 is NEWS + a bit of ChangeLog That's how I'd see the thing :) -- Sylvain _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
