This seems like a particularly complicated process for what should be a simple 
thing.

I prefer a very simple convention, and I prefer that conventions be relatively 
easy to parse with software, which means something with parens or braces makes 
sense.  Since braces don't work, I recommend adopting your proposal - using 
'(#0000) Thing'.

Any significant dissenters?

On Sep 24, 2010, at 9:27 AM, Jacob Helwig wrote:

> So, here's the summary of things from this thread, as I understand them:
> 
>  1. "[#xxxx] ..." is _not_ the current convention, even though that has
>     been the common thing seen as of late.
> 
>  2. There is some dispute whether the convention should be "Fix #xxxx
>     Change some behavior", or something more like"(#xxxx) Fix some
>     behavior".
> 
> My main concern was that we didn't have a convention that was
> fundamentally incompatible with using git-am, since I have a setup that
> makes it very easy to pull patches, and patch series down off the
> mailing list, and apply them using git-am in order to review them, and
> generally try them out. (With offlineimap, this means that I can operate
> in a completely disconnected state, though this is getting off topic.)
> Summary point #1 above addresses this concern.
> 
> For #2:
> 
> Personally, I lean more towards something like "(#xxxx) Fix some
> behavior", than "Fix #xxxx Change some behavior".  The reason for this
> is that, to me, the former feels less redundant.  I am a big fan of
> writing commit subjects in the imperative mood[1], so having two actions
> seems a bit over-kill.  However, I can see how it could be argued that
> it's not redundant, at all (and provides extra information), when you
> use something like ((Partial )?Fix|Workaround), instead of just "Fix".
> 
> So, in the interest of getting a clear consensus on this, I suggest the
> following:
> 
>  1. I will tally +/-1 votes from the community, and the core developers
>     as to whether the convention should stay
>     "((Partial )?Fix|Workaround) for #xxxx ...", or be changed to
>     (something like) "(#xxxx) Imperative statement".  I will leave this
>     vote open until Friday, October 1st, 23:59:59 UTC-0700.  If no
>     consensus has been reached by this point, then the convention will
>     remain "((Partial )?Fix|Workaround) for #xxxx ...".
> 
>  2. After the voting period, I will work on codifying The Puppet
>     Development Life Cycle, with the decision, someplace where
>     modifications to it will be required to go through the mailing list
>     for discussion & review, instead of "carved in sand" on the Wiki,
>     where they can be changed without any discussion.  Something like a
>     SubmittingPatches, or DevelopmentLifecycle file in the
>     repositories, and/or something in puppet-doc.git.  I don't know
>     where, yet, but I will do my best to make sure that it's someplace
>     easy to find, well advertised, and that it's generally agreed that
>     "this is the right place for it". (I am quite open to suggestions
>     for the location of this.)
> 
> Please bear in mind: Even though I am sending this from an
> "@puppetlabs.com" email address, I am not sending this with any sort of
> special authority.  I am a community member that sees something where I
> feel that we should reach a clear consensus, and am trying to reach a
> consensus (whatever that may be).
> 
> [1] http://en.wikipedia.org/wiki/Imperative_mood
> 
> -- 
> Jacob Helwig
> 
> On Wed, 22 Sep 2010 12:09:51 -0700, Jacob Helwig wrote:
>> 
>> While pulling down some of the patches to review/look-over, I noticed
>> that our convention for commit messages doesn't play very nicely with
>> git-am.  By enclosing the ticket # in square brackets, git-am ends up
>> stripping the ticket number out, thinking it's part of the "normal"
>> preamble.
>> 
>> For example, when I save the message, and apply it using git-am, Pauls
>> message with the subject
>> 
>>  [Puppet-dev] [PATCH/puppet 1/1] [#4716] ResourceTypeAPI exposes 
>> implementation details that are likely to change
>> 
>> becomes
>> 
>>  ResourceTypeAPI exposes implementation details that are likely to change
>> 
>> 
>> This seems a bit problematic to me.
>> 
>> Perhaps we might want to change the convention to be "(#4716) ...",
>> "#4716: ...", or something else that isn't square brackets?  Thoughts?
>> 


-- 
Ah, but I am more perceptive than most of the universe. Especially
the parts of the universe that are vacuum.  -- James Alan Gardner
---------------------------------------------------------------------
Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199




-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to