This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Future developers? Code? What are you talking about???
This isn't in the code base, nor is it "code" - it is config options in the private platform files for configuring clusters of contributors. We -never- review what is in that area, leaving it up to their respective owners. The contents of that area have no impact on anyone other than their owners.
In some cases, like this one, the platform file may reflect uses outside of the main code base. Nobody has to explain them to anyone.
Eventually, when my other uses catch up, I will indeed remove it. Shouldn't be much longer as I'm close to completing the integration of my branches back to the trunk, but (frankly) that's my concern, not yours.
On Mar 10, 2011, at 7:16 PM, Eugene Loh wrote:
> No big deal one way or the other. It's a symbolic gesture against bit rot, I suppose. The fact is that there are different pieces of the code base that move forward while vestiges of old stuff get left behind elsewhere. At first, it's easier to leave that stuff in. With time, the history gets forgotten and there gets left more and more mysterious stuff that future developers have to figure out.
> Let's say there's code that doesn't do anything. One can ask, "Why not just leave it in?" Or, one can ask, "Why not just strip it out?"
> This particular case (*.conf enable_progress) is minor. Either way, things are fine. My concern is more around the accumulation of many such instances.
> Ralph Castain wrote:
>> On Mar 10, 2011, at 5:54 PM, Eugene Loh wrote:
>>> Ralph Castain wrote:
>>>> Just stale code that doesn't hurt anything
>>> Okay, so it'd be all right to remove those lines. Right?
>> They are in my platform files - why are they a concern?
>> Just asking - we don't normally worry about people's platform files. I would rather not have to go thru everyone's files and review what they have there.
>>>> - frankly, I wouldn't look at platform files to try to get a handle on such things as they tend to fall out of date unless someone needs to change it.
>>>> We always hard-code progress threads to off because the code isn't thread safe in key areas involving the event library, for one.
>>>> On Mar 10, 2011, at 3:43 PM, Eugene Loh wrote:
>>>>> In the trunk, we hardwire progress threads to be off. E.g.,
>>>>> % grep progress configure.ac
>>>>> # Hardwire all progress threads to be off
>>>>> [Hardcode the ORTE progress thread to be off])
>>>>> [Hardcode the OMPI progress thread to be off])
>>>>> So, how do I understand the following?
>>>>> % grep enable_progress contrib/platform/*/*.conf
>>>>> contrib/platform/cisco/linux-static.conf:orte_enable_progress_threads = 1
>>>>> contrib/platform/cisco/macosx-dynamic.conf:orte_enable_progress_threads = 1
>>>>> contrib/platform/openrcm/debug.conf:orte_enable_progress_threads = 1
>>>>> % grep enable_progress contrib/platform/*/*/*.conf
>>>>> contrib/platform/cisco/ebuild/hlfr.conf:orte_enable_progress_threads = 1
>>>>> contrib/platform/cisco/ebuild/ludd.conf:orte_enable_progress_threads = 1
>>>>> contrib/platform/cisco/ebuild/native.conf:orte_enable_progress_threads = 1
>>>>> These seem to try to turn progress threads on. Ugly, but not a problem?
> devel mailing list