From: Dave Chinner <david@fromorbit.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Eric Sandeen <sandeen@sandeen.net>,
linux-xfs@vger.kernel.org, darrick.wong@oracle.com
Subject: Re: [PATCH v2] mkfs: add mkfs config version specifier for the config file
Date: Thu, 21 Jun 2018 09:18:50 +1000 [thread overview]
Message-ID: <20180620231850.GO19934@dastard> (raw)
In-Reply-To: <20180619205710.GH7508@wotan.suse.de>
On Tue, Jun 19, 2018 at 10:57:10PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 19, 2018 at 02:53:28PM -0500, Eric Sandeen wrote:
> > Soo....
> >
> > I'm really on the fence about versioning at all, because we have yet to
> > identify any concrete scenario in which we'd need to bump the version;
> > we haven't even defined what exactly the "version" implies.
>
> Right.
>
> > So unless anyone has a concrete example of how a version would be needed,
> > functional, reliably-parsed, and well-defined I'm inclined to leave this out.
>
> Dave asked for it, so I would imagine he could make a better case for it.
I ask for things so that people think about the problem, not
necessarily because I want something to be done. Please don't
conflate "Dave says X" with "we must implement X" because I am often
wrong and/or playing the Devil's Advocate role.
I try to look outside the box for potential issues, so if I see a
potential issue I'll say /something/ just to get people to discuss
that aspect of the problem and come up with a reasonable solution. I
don't have the time to solve every problem we have, I don't
/want/ to solve every problem, but I want to make sure we solve
the problems we have in the right way the first time.
In reality, I don't care either way if we have a version symbol in
the config file, and if it is decided that it is a good thing how it
will be implemented. What I care about is that we've thought about
supporting config files over their entire lifetime, not just
considered what is needed in the near term to solve the immediate
problem.
IOWs, my comments about treating a config file like any other
long term persistent structure were intended to shift the focus of
the discussion from implementation minutae to the bigger, long term
picture details that needed to be thrashed out. Work out the big
picture first, the small details will fall naturally from that...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2018-06-20 23:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-18 18:05 [PATCH v2] mkfs: add mkfs config version specifier for the config file Luis R. Rodriguez
2018-06-19 19:53 ` Eric Sandeen
2018-06-19 20:57 ` Luis R. Rodriguez
2018-06-19 21:21 ` Eric Sandeen
2018-06-19 23:52 ` Luis R. Rodriguez
2018-06-20 13:11 ` Jan Tulak
2018-06-20 23:18 ` Dave Chinner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180620231850.GO19934@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox