| 1 |
On Tue, Jan 21, 2014 at 07:41:21PM +0100, Tom Wijsman wrote: |
| 2 |
> On Tue, 21 Jan 2014 09:20:04 -0800 W. Trevor King wrote: |
| 3 |
> > On Tue, Jan 21, 2014 at 05:59:54PM +0100, Tom Wijsman wrote: |
| 4 |
> > > On Tue, 21 Jan 2014 08:51:14 -0800 W. Trevor King wrote: |
| 5 |
> > > > On Tue, Jan 21, 2014 at 04:40:19PM +0100, Tom Wijsman wrote: |
| 6 |
> > > > > On Sun, 19 Jan 2014 18:32:35 -0800 W. Trevor King wrote: |
| 7 |
> > > > > > No policy/suggestion/goal is going to be followed 100% of |
| 8 |
> > > > > > the time. |
| 9 |
> > > > > |
| 10 |
> > > > > This way, it seems preferable to use the mailing list when |
| 11 |
> > > > > blaming. |
| 12 |
> > > > |
| 13 |
> > > > Unless some of the discussion happened on IRC. There are |
| 14 |
> > > > several possible channels for patch discussion, but only one |
| 15 |
> > > > commit message per patch. |
| 16 |
> > > |
| 17 |
> > > Exactly, without knowledge codification all that will continue |
| 18 |
> > > to be a "feel like", "probably not", "shouldn't", "unless some". |
| 19 |
> > |
| 20 |
> > I don't see that as a problem. I guess I just have more faith |
| 21 |
> > that current devs will put in a reasonable best-effort without |
| 22 |
> > codification beyond “here are some conventions you may want to |
| 23 |
> > use”, and that future devs will be competent enough to still be |
| 24 |
> > productive in the face of unhelpful commit messages. |
| 25 |
> |
| 26 |
> If they are just mentioned at random all the time, perhaps half of |
| 27 |
> them get remembered or so; the half of what is remembered gets given |
| 28 |
> through to the next generation of future devs, this up to the point |
| 29 |
> that it would have been a better idea to write this down than to |
| 30 |
> have faith. |
| 31 |
|
| 32 |
I'm all for recording suggested conventions in DEVELOPING, but I don't |
| 33 |
think it's worth the trouble to over-specify the conditions under |
| 34 |
which each tag should be used, or to lay out consequences for cases |
| 35 |
where they're forgotten. The faith part is trusting devs to |
| 36 |
understand and apply the written suggestions, not in determining what |
| 37 |
the suggestions are. |
| 38 |
|
| 39 |
Cheers, |
| 40 |
Trevor |
| 41 |
|
| 42 |
-- |
| 43 |
This email may be signed or encrypted with GnuPG (http://www.gnupg.org). |
| 44 |
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy |
Archives