On 08/11/2015 04:28 PM, Ian Stakenvicius wrote: > 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)? > > >
The "CATEGORY:" prefix is already in the wiki. Interesting idea about projectname/herdname prefix. I've already seen someone (I think ulm) prefixing with [QA]. I don't feel strong about this. IMO, if there is no useful prefix... just don't use any. The lack of prefix will make it obvious that this is a larger change. But project/herd specific prefixes could still make sense.
