On 29.03.2017 18:12, Jord van der Elst wrote: > > On Wed, Mar 29, 2017 at 5:59 PM, Christian Beer > <christian.b...@aei.mpg.de <mailto:christian.b...@aei.mpg.de>> wrote: > > > Restricting to commits that have "client" in the commit title is also > wrong as there is no commit discipline in BOINC (aka. no atomic > commits) > and you can have client changes embedded in other commits (where the > message doesn't state that). You would need to at least include commit > titles with "lib" too and that would probably still miss a lot of > changes. You would need to restrict to commits that changed files in > client/, clientgui/ and lib/. > > > It was an example, Christian. > For what matters, I now filter on client, mgr, mac, lib, scr, > winbuild, locale, curl, openssl, zlib, linux, vbox and for > completeness, server. Just because all of those at times make up a > working client.
And you are still missing the commits that do not state the component in the title. You would need to better use everything except "locale" changes. As Oliver also said in an earlier email the level of details of a changelog is different for each audience. The normal user who wants to decide if he needs to upgrade, only needs a summary of changes in plain english. The developer who wants to fix stuff needs the complete commits including the technical comments in the messages. By providing proper tags to the repository each developer can create this complete change log on the fly individually. The Changelog that the user of the software sees needs to be created by hand. On other Open Source projects this is done during development by setting version Milestones and every new feature or change in behavior gets an issue and every commit is linked to an issue. The list of commits are for the developers to look at. The list of issues of a milestone can be compiled into a user-friendly changelog (almost on the fly). A milestone represents the features or changes that happened (or should happen) since the last milestone. It would save a lot of work if BOINC would use a scheme like that. Regards Christian _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
