[debian-mysql] Groping for a roadmap in the dark

[Nicholas Bamber]

On 11/06/12 17:33, Olaf van der Spek wrote:

> 
>>> AFAIK purge doesn't delete data, it deletes conf. Users expect the
>>> same, otherwise you wouldn't have to bother with NEWS and questions.
>> No I don't agree that we are proposing to do something unnatural. We are
>> proposing to *correct* and *standardize* the behaviour in a way that the
>> users need to know about.
> 
> If they don't know already, it's unnatural isn't it? Otherwise it'd be
> natural / common sense.

No. That makes no sense to me.

> 
>> On the data/conf issue Debian Policy is essentially silent so the
>> statement is "purge doesn't delete data, it deletes conf" is a possible
>> interpretation of the policy but not a necessary one.
>>
>> There is a bug report covering this exact issue,
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535577. My reading of
>> the consensus in that is that *if* we delete the data, we must
>> explicitly ask the user via debconf. That is precisely what we are
>> proposing to do. Furthermore this only applies to new installs -
>> probably from 5.6 except for the experimental distribution.
> 
> Whether it only provides to new installs is hardly relevant I think.
> Databases from new installs are important too.

I'm not saying that new installs are less important and it strikes me as
disingenuous to suggest I was. First of all changing the behaviour for
upgrades could be considered a potentially more dangerous change of
behaviour. Secondly filtering it through new installs means it will come
in more slowly which will give more time for the message to get out.

> 
>>>
>>> It's like first setting a trap and then putting up a warning sign.
>> Umm no. First of all you are ignoring what can be done to warn the user
>> from within debconf - both during the initial install and before the
> 
> I'm not. But I'm trying to argue that one should not depend on that.

Sorry I don't get you. I am proposing to use debconf as it is intended
to be used.

> 
>> actual purge. Sure that can be suppressed as well - presumably for an
>> automated install (or even a piuparts test!), but in that case we cannot
>> be held responsible, since the user is claiming to know better and
>> should be testing his automated install.  And then we should probably
>> catch him on the purge anyway.
> 
> Probably isn't good enough when it's about important user data.
> When there's an emergency and the user is in a hurry, the warning
> might get lost.

Again you have lost me. The case where the user will miss the warning is
precisely the case where the user should be taking responsibility for
doing so.

Secondly if the data is important and the user is doing an upgrade in a
hurry and has no backup then the user is an idiot.

Thirdly you are saying that the user's data is so important that we
cannot actually fix any bugs in case doing so ends up deleting the
user's data. That just makes no sense.

> 
>> Secondly responsible users should keep backups of critical data. Sure if
>> something in the installation deletes data unexpectedly that is a
>> serious bug. But the question is just how do we ensure that the user
>> expects it.
> 
> We don't :p
> 
>> Thirdly we are proposing to do this at the earliest possible moment in
>> the next release cycle and engage the users as much as possible in a way
>> that we did not do this time.
> 
> Hmm. Not sure whether that's relevant.
> 
> You could maybe enable it during testing and then disable it again
> before next freeze to avoid it being an issue in stable.
> 
>>>
>>> Why are we trying so hard to avoid a piuparts exception?
>> Okay somewhere between a quarter and a third of the bug reports, I would
>> rather not touch without being able to do piuparts testing. I am not
>> saying that piuparts would constitute adequate testing, but it really
>> should be necessary.
> 
> Are we talking about two different kinds of exceptions?
> When I'm talking about an exception, I mean telling piuparts to ignore
> /var/lib/mysql
> Not to skip piuparts altogether.
> Or would ignoring /var/lib/mysql not be sufficient to catch bugs and
> do piuparts testing?

If an exception was acceptable to piuparts and I could do it for my own
testing then yes. But this is also about making mysql behave in an
expected way.

> 
>>
>>>
>>>
>>>> So I throw the question back to you. How would you respond to #511438?
>>>
>>> How big is the test and other optional stuff? If it's significant it
>>> seems reasonable to split it.
>>
>> Well the biggest package is mysql-source-5.5. Unfortunately not  a lot
>> can be done about that until we revisit how plugins are built - and that
> 
> But mysql-source-5.5 is only used for building stuff I assume, not for running.

yes
> 
>> is a low priority. The test stuff is a somewhat different question from
>> the server stuff, since the sort of user who complains about the size of
>> the server stack is never going to install mysql-testsuite anyway.
>>
>> If I had to reduce the number of issues to improve the clarity of the
>> questions I would focus on #511438 rather than the test suite.
> 
> I thought the test suite was the biggest offender. But yeah, look at
> what stuff is big but not always needed.
> 
> Olaf