| 1 |
On 08/11/2015 04:28 PM, Ian Stakenvicius wrote: |
| 2 |
> On 11/08/15 04:57 AM, Tobias Klausmann wrote: |
| 3 |
>> The more we stuff into the summary line, the harder it will be to |
| 4 |
>> write meaningful summaries. And thus, people will write crappy ones |
| 5 |
>> or ignore the length limit. I recommend against any more |
| 6 |
>> prescription over "Add the the cat/pn if meaningful, don't use more |
| 7 |
>> than 75 characters". |
| 8 |
> |
| 9 |
>> The cat/pn rule is tricky anyway: what if one commit touches 100 |
| 10 |
>> packages? Or should that be split into 100 commits for easier |
| 11 |
>> partial rollback? |
| 12 |
> |
| 13 |
>> Regards, Tobias |
| 14 |
> |
| 15 |
> |
| 16 |
> |
| 17 |
> The summary line limit is going to be a real issue, tbh. I think it |
| 18 |
> would probably be best to adopt the convention of putting a few |
| 19 |
> choice, perhaps even canned, phrases in the summary line, and ensure |
| 20 |
> any and all details (effectively what the summary line used to be for |
| 21 |
> when it had practically no limit) within the commit message body instead |
| 22 |
> . |
| 23 |
> |
| 24 |
> Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: |
| 25 |
> adjusted dependencies' are generic (and short) enough yet descriptive |
| 26 |
> enough to see what went on while scanning the log. 'Fix bug' IMO in |
| 27 |
> the summary doesn't work at all because, although its accurate, that |
| 28 |
> bug could literally be anything at all. |
| 29 |
> |
| 30 |
> Multi-package commits are going to be more of an issue of course.. I |
| 31 |
> did one last night, fortunately I think I can get away with using |
| 32 |
> "mozilla packages" in place of cat/pn since it is a very specific set |
| 33 |
> of packages. Perhaps for sweeping changes like that we can use the |
| 34 |
> herdname or projectname or the category name (if its a particular |
| 35 |
> category only)? |
| 36 |
> |
| 37 |
> |
| 38 |
> |
| 39 |
|
| 40 |
The "CATEGORY:" prefix is already in the wiki. Interesting idea about |
| 41 |
projectname/herdname prefix. |
| 42 |
|
| 43 |
I've already seen someone (I think ulm) prefixing with [QA]. |
| 44 |
|
| 45 |
I don't feel strong about this. IMO, if there is no useful prefix... |
| 46 |
just don't use any. The lack of prefix will make it obvious that this is |
| 47 |
a larger change. But project/herd specific prefixes could still make sense. |
Archives