[Mageia-dev] (second attempt) suggesting sectool be dropped

[Claire Robinson]

On 18/11/11 10:37, Colin Guthrie wrote:
> 'Twas brillig, and Claire Robinson at 17/11/11 12:49 did gyre and gimble:
>> On 17/11/11 10:26, Michael scherer wrote:
>>> On Tue, Nov 15, 2011 at 11:39:29AM +0100, Florian Hubold wrote:
>>>> Am 15.11.2011 07:29, schrieb Michael Scherer:
>>>>> Le lundi 14 novembre 2011 à 22:09 -0800, Robert M. Riches Jr. a écrit :
>>>>>> (New list subscriber...needed to fix registered email address to
>>>>>> post...)
>>>>>>
>>>>>> I was asked to submit this suggestion to the mailing list:
>>>>>>
>>>>>> As a Mageia user, I believe msec was much better off with_OUT_
>>>>>> sectool.  In its present state, sectool is BADLY broken.  It
>>>>>> whines for pages about file permissions that are exactly as they
>>>>>> should be.
>>>>> Can you be more specific ?
>>>> It think he means this: https://bugs.mageia.org/show_bug.cgi?id=2808
>>>> or https://bugs.mageia.org/show_bug.cgi?id=2255#c21 or
>>>> https://bugs.mageia.org/show_bug.cgi?id=2255#c22
>>>>
>>>> I've also become supportive of this, sectool is basically duplicating
>>>> partly msec functionality, there was no adaption for Mageia,
>>>> currently it's
>>>> checking on Mageia with the upstream Fedora configuration.
>>>>
>>>> Honestly this should have been done when importing it, as
>>>> tmb already mentioned. msec should be patched to not require it.
>>>>
>>>> When we can't even get our default security tool to work properly,
>>>> what's the point in adding a second one which needs even more
>>>> maintenance?
>>>
>>> As you say, the question is again "why was it uploaded in the first
>>> place".
>>> It seems some packages were uploaded, and there seemed to have not enough
>>> tests. While that's hard or impossible to avoid totally, that's not
>>> really
>>> the way to achieve a good distribution :/
>>>
>>> I neither use msec or sectool, so I personnaly do not care that much.
>>> Afaik, sectool was created by a ex mandriva/mandrake guy ( vincent
>>> danen ),
>>> because he was ( rightfully ) wanting to rewrite  msec, who is/was
>>> a mess of bash + python + perl code ( and rather ugly code, afaik,
>>> last time
>>> I took a look ), but if msec is supported, and sectool is not, then I
>>> guess
>>> we could drop. However, I still think we should first attempt to
>>> collaborate
>>> and fix it. ( ie, always have the reflex of "try to fix and
>>> collaborate" ).
>>>
>>
>>
>> As one of the people who tested it and the one who filed the bug linked
>> to above which expresses the need for it to be configured, I object to
>> this being blamed on QA! It seems we are kicked whenever anything is wrong.
>>
>> I believe it is assigned to those higher up to provide a proper
>> configuration.
>>
>> The bug was dated 22nd September and as yet no configuration exists.
>> That does not reflect well on the distribution, not that QA haven't
>> performed sufficient testing, which we obviously did.
>
> Knowing misc a little bit I don't think for a second he was intending to
> blame QA team here.
>
> More the initial "blind import" (which was a hard time to do overly much
> testing as I'm sure all will agree!) without properly checking things then.
>
> So please don't take it personally, I really don't think he was
> targeting you :)
>
> Col
>
>

A bug was created for the issues found during testing to be resolved. No 
new issues have arisen since then.

What is being discussed now are only the issues raised by QA at the time 
showing, if anything, that testing was quite thoroughly completed. No 
extra testing time was necessary.

I don't take this personally and I hope you will see this correction of 
the facts in the same light. This is the second time in a week though 
that QA has had to offer corrections against the assumption of a level 
of neglect.

Claire