Sylvain Beucler <[EMAIL PROTECTED]> tapota : >> 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/.
That what I did in the past, for the first release. It took me several hours and it was not exactly a funny job. And when doing release, there are usually many many others things going on, better things to do than reading the changelog bit per bit - and spending time to understand an issue someone knows better. ChangeLog.byversion is not exhaustive and notice important changes. Even if you were not concerned by an half on them. > 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. Ok. But giving in the commit message a link to another discussion somewhere to explain the changes is not ok in this regard. > Point 1 is CVS (and the associated ChangeLog) > Point 2 is NEWS + a bit of ChangeLog We can renamed ChangeLog.byversion by NEWS, if you want, since we actually have in mind the same thing. Now, how should be filled the NEWS/ChangeLog.byversion? The previous way (half a day of dumb job without even being sure to explain properly what should be explained) is not satisfactory to me. About the bug fix at the origin of the discussion, what was it about? It was unclear to me after reading the commit message. What is about a user report on the error message returned (or not returned by mistake) at login failure? That's more or less what I understand. And that's typically in my experience the kind of bug that are likely to have been noticed by a bunch of users, and so that is worth being in the ChangeLog.byversion. -- Mathieu Roy +---------------------------------------------------------------------+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +---------------------------------------------------------------------+ _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
