On Fri, Feb 17, 2017 at 06:43:41AM +0000, Daniel Shahaf wrote:
> Evgeny Kotkov wrote on Thu, Feb 16, 2017 at 23:55:19 +0300:
> > Stefan Sperling <stsp_at_elego.de> writes:
> > >> 1) enabling it on trunk permanently (and disabling it on stable branches)
> > >>
> > >> 2) tagging a wc that has the patch applied
> > >>
> > >> 3) committing the patch to a branch and <handwave>arrange for the tag to
> > >> incorporate the changes from that branch</handwave>.
> > >
> > > 4) Encourage people to compile alpha/beta/rc with --enable-maintainer-mode.
> > 4) seems like an appropriate option to me.
> > This is because we only ship the source code, and I think that those who
> > actually build it should be in charge of enabling or disabling the debug
> > features.
> So perhaps we should change the guard from
> #ifdef SVN_DEBUG
> #if defined(SVN_DEBUG) || defined(FSFS_VERIFY_AS_REVISION_BEFORE_CURRENT_PLUS_PLUS)
> to make it easier to enable that one feature, without everything else
> that maintainer mode brings.
Why are you concerned about everything else that maintainer mode brings?
I use it all the time and don't notice any problem. Which problems do you
expect for end users if they use maintainer mode?
Additional knobs like this cause additional clutter and forces packagers
to sort through them all and figure out which combo they want.
Granted, we have a lot of specific feature compile time knobs already,
but that in itself is not a good reason for adding more of them.
I think it is entirely reasonable for us, in general and regardless of this
particular revision++ check, to ask users to enable maintainer mode when
testing alpha and betas.
> (and if we choose #4, we should document that somewhere — release notes
> or release announcement or something)
Of course -- BTW, the release notes aren't done yet; Could anyone help
me with going over CHANGES and creating sections in the release notes
for new features worth highlighting (new subcommands, options, etc.)? :-)
Received on 2017-02-17 10:05:32 CET