[rfc][icedtea-web] Add netx-dist-dist-tests-whitelist to .hgignore

[Jacob Wisor]

On 02/18/2015 06:18 PM, Jiri Vanek wrote:
> On 02/18/2015 06:12 PM, Jacob Wisor wrote:
>> On 02/18/2015 03:37 PM, Jie Kang wrote:
>>> ----- Original Message -----
>>>> On 02/13/2015 02:36 PM, Jie Kang wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> On 02/12/2015 10:38 PM, Jacob Wisor wrote:
>>>>>>> On 02/12/2015 at 05:29 PM Jie Kang wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Title says it all. I think given the usage of the file, and the
>>>>>>>> extremely
>>>>>>>> low possibility of it
>>>>>>>> having committed changes, it'd be nice for developers to have it
>>>>>>>> included
>>>>>>>> in the .hgignore. This
>>>>>>>> is really just for convencience.
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>
>>>>>>> +1
>>>>>>
>>>>>> For record, this will not work as intendid:
>>>>>>
>>>>>> http://stackoverflow.com/questions/2339716/hgignore-not-working-for-mercurial
>>>>>>
>>>>>> http://stackoverflow.com/questions/15699917/mercurial-hg-ignore-does-not-work-properly
>>>>>>
>>>>>>
>>>>>
>>>>> Aw good catch. That's annoying :\
>>>>>
>>>>>> But satill I'm for doing it. Wheter forget this file in future or
>>>>>> workaround
>>>>>> with -x ...
>>>>>
>>>>> A template could work too but that seems like overkill. How about making
>>>>> the file part of configure/make process?
>>>>>
>>>>> I'd prefer forgetting over using -X
>>>>
>>>> Sop actually the solkution will be your original patch with:
>>>>
>>>> --- a/.hgignore    Fri Feb 13 12:48:24 2015 +0100
>>>> +++ b/.hgignore    Fri Feb 13 14:42:20 2015 +0100
>>>> @@ -11,4 +11,11 @@
>>>>    netx/net/sourceforge/jnlp/resources/COPYING.html
>>>>    netx/net/sourceforge/jnlp/resources/ChangeLog.html
>>>>    netx/net/sourceforge/jnlp/resources/NEWS.html
>>>> +# the netx-dist-tests-whitelist is tracked but ignored
>>>> +# adjust your .hgrc configuration file:
>>>> +# [defaults]
>>>> +# status = -X netx-dist-tests-whitelist
>>>> +# diff = -X netx-dist-tests-whitelist
>>>> +# commit = -X netx-dist-tests-whitelist
>>>> +# accordingly
>>>>    netx-dist-tests-whitelist
>>>>
>>>>
>>>>
>>>> oook? :))
>>>>
>>>> If it works forks for you, feel free to push
>>>
>>> I'm not sure if these comments are very useful to have.
>>>
>>> How about replacing the whitelist file with a template? Then devs just copy +
>>> rename to
>>> netx-dist-tests-whitelist and there won't be issues with changes to the
>>> actual whitelist file. See
>>> the attached patch.
>>>
>>> We could add comments to the template teaching people how to use it too (but
>>> might need to edit
>>> makefile to skip comments). And/or we could create the
>>> netx-dist-tests-whitelist as some part of
>>> autogen.sh, configure or make...
>>>
>>> Thoughts?
>>
>> I think, if ain't used then we should actually remove it from the repo (and
>> the respective comments
>> in .hgignore too). Tracking a file but not using it does not make sense to me.
>> If I am missing
>> something then please explain it to me.
>>
>> As I understand netx-dist-tests-whitelist has something to do with
>> whitelisting tests to build and
>> run. So, this information should go into the "Building" section of the README
>> file. Anyway, if this
>> file is required by or used only for tests then it should be auto generated
>> instead of being
>> tracked. It is no source file per se, but seems to be rather a configuration
>> file for building or
>> testing.
>>
>
> You understand it right. The reason to keep the file was to make it simple. I'm
> 50/50 to remove the file. Then, if file is not found, use default ".*". If its
> found, then it is used (no metter what is it)

Reads very reasonable to me and seems to be a far better approach than the 
current one.

> The only issue I have is that I will quickly forget  the name, then create the
> file with typo, and will be debugging why it was not used for hours... (well
> exaggerate a bit, but you should see my point... )

I understand what mean but one can never be made immune to typos, especially 
when it comes to names. Well then, the best way to prevent forgetting stuff is 
to document it. ;-) Maybe the configure script should perhaps mention the file 
too. Anyway, what is the file's expected format? Judging by ".*" it seems to be 
a list of regular expressions of test names. Well, that's just me guessing 
again, so documenting this is apparently overdue.

Jacob