On Sat, Sep 20, 2014 at 12:37:39PM -0500, Greg Stein wrote:
> On Wed, Sep 10, 2014 at 12:24 PM, C. Michael Pilato <cmpilato_at_collab.net>
> wrote:
>
> > On 09/10/2014 01:06 PM, Stefan Sperling wrote:
> > > I've been working on the log-message-templates branch recently.
> > > This branch was started by cmpilato a long time ago but for some
> > > reason sat around untouched ever since. It's now been overhauled
> > > by me with much help from Bert.
> >
> > Just for a bit of history, I left the branch incomplete because I knew
> > that the implementation didn't meet the (IMO, ridiculously
> > over-engineered) prior design discussions around the feature. Lacking
> > the energy and time to attempt to rehash those discussions when the
> > branch was still young, it simply got back-burnered indefinitely.
> >
>
> And all these posts else-thread demonstrate exactly why you back-burnered
> it... everybody has another feature or three to add. Or why this patch
> isn't Quite Right, and needs to be Fixed.
As more and more people barged in with suggestions I increasingly lost
motivation as well. Not because they're bad suggestions but because most
of them will likely remain suggestions without working code to back
them up. As the person trying to drive this forward I'm essentially left
with a mixed bag of ideas that cannot possibly all work together.
It's clear that we don't have consensus on the scope of this feature
and its intended use. I guess I'll have to start drafting a design
document that clearly states what the intended scope and the intended
use cases are. E.g. setting arbitrary revprops is definitely out of
scope in my opinion -- this kind of customisation of revision information
can already be done in other ways (from a post-commit hook for example).
I get the point about the need for comments in the template.
But I don't see a point in adding a format number because I don't
think we should bother our users with that kind of complexity for
what should be a straightforward to use feature. I'm now convinced
that if we add variable expansion features then we should add them
with the initial release of this feature and have them be set in
stone for all time. If we are unable to put this in the design right
away what reason do we have to believe that someone will surely sit
down to design and implement it later? Let's be honest -- we probably
won't ever do it if we don't do it now.
I'll start another thread on this topic once I have found time to
write a spec that addresses some of the points raised in this
discussion and that I would like to implement.
Thanks to everyone for all the feedback so far!
I'll have a chance to talk to FreeBSD devs next week and will use
this opportunity to get feedback from them as well.
Received on 2014-09-21 11:07:51 CEST