-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/08/15 04:57 AM, Tobias Klausmann wrote: > The more we stuff into the summary line, the harder it will be to > write meaningful summaries. And thus, people will write crappy ones > or ignore the length limit. I recommend against any more > prescription over "Add the the cat/pn if meaningful, don't use more > than 75 characters". > > The cat/pn rule is tricky anyway: what if one commit touches 100 > packages? Or should that be split into 100 commits for easier > partial rollback? > > Regards, Tobias >
The summary line limit is going to be a real issue, tbh. I think it would probably be best to adopt the convention of putting a few choice, perhaps even canned, phrases in the summary line, and ensure any and all details (effectively what the summary line used to be for when it had practically no limit) within the commit message body instead . Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: adjusted dependencies' are generic (and short) enough yet descriptive enough to see what went on while scanning the log. 'Fix bug' IMO in the summary doesn't work at all because, although its accurate, that bug could literally be anything at all. Multi-package commits are going to be more of an issue of course.. I did one last night, fortunately I think I can get away with using "mozilla packages" in place of cat/pn since it is a very specific set of packages. Perhaps for sweeping changes like that we can use the herdname or projectname or the category name (if its a particular category only)? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlXKBpIACgkQAJxUfCtlWe3pQgD8Ct1elGvDIObKKvskQJ1jCZIK cYvuWdMD7pobr/hH6iIA/jnYirAb9CDe4iNlVPqG2AKYbj9NJdGnpoL/TFhJtj8U =vnTb -----END PGP SIGNATURE-----
