1 |
On 12 August 2015 at 02:28, Ian Stakenvicius <axs@g.o> wrote: |
2 |
> Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: |
3 |
> adjusted dependencies' are generic (and short) enough yet descriptive |
4 |
> enough to see what went on while scanning the log. |
5 |
|
6 |
I personally find those summaries a bit too terse. |
7 |
|
8 |
Mostly, because when I see "A version is bumped" I immediately expect |
9 |
to know which version the bump is to, but have to dig out the diff to |
10 |
find out. |
11 |
|
12 |
I would also prefer, where possible, to replace "adjusted |
13 |
dependencies" to be more concise, like "include dev-perl/Foo in |
14 |
dependencies", ( though of course, apply some taste, listing more than |
15 |
3 distinct new dependencies in the summary is execessive, treat them |
16 |
like hashtags on twitter, 1 is good, 2 is OK, 3 and you're starting to |
17 |
get crazy ) |
18 |
|
19 |
> Multi-package commits are going to be more of an issue of course.. I |
20 |
> did one last night, fortunately I think I can get away with using |
21 |
> "mozilla packages" in place of cat/pn since it is a very specific set |
22 |
> of packages. Perhaps for sweeping changes like that we can use the |
23 |
> herdname or projectname or the category name (if its a particular |
24 |
> category only)? |
25 |
|
26 |
Agreed. If you need multi-package changes and you can't think of a |
27 |
good category prefix to use, the commit message should visibly |
28 |
acknowledge that its a multi-package commit of some kind, and the |
29 |
*kind* of change should be very clear. |
30 |
|
31 |
Just keep in mind really the recommendations for prefix naming are |
32 |
descriptive, not prescriptive, and interpretation and good taste need |
33 |
to be applied everywhere. |
34 |
|
35 |
|
36 |
|
37 |
-- |
38 |
Kent |
39 |
|
40 |
KENTNL - https://metacpan.org/author/KENTNL |