[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1028381 - /subversion/site/publish/roadmap.html

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 28 Oct 2010 14:28:34 -0400

On 10/28/2010 01:58 PM, Greg Stein wrote:
> On Thu, Oct 28, 2010 at 13:04, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> On 10/28/2010 12:50 PM, Hyrum K. Wright wrote:
>>> On Thu, Oct 28, 2010 at 11:48 AM, <cmpilato_at_apache.org> wrote:
>>>> Author: cmpilato
>>>> Date: Thu Oct 28 16:48:06 2010
>>>> New Revision: 1028381
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1028381&view=rev
>>>> Log:
>>>> Add 'Remove obliterate code' to our 1.7 to-do list, per list discussion.
>>>
>>> Are we talking about 'svn rm'ing the code, or just disabling it for
>>> this release?
>>
>> If the task is left to me, the code will be completely removed.
>
> Why? I believe it is behind an #ifdef wall, so it isn't truly present
> today. If you remove it, then we just gotta put it back in later...

If the code is behind an #ifdef wall, not exposed via our public includes,
not generating any new hook scripts, etc. -- in other words, it's completely
invisible to users and blackbox API consumers -- then I agree, there's no
*required* work here.

That said, unless Julian is confident that the road he began down will
ultimately lead to some actual value, that #ifdef wall is now a development
burden. I lack that same confidence, and believe obliteration is something
we need to stop pretending we can realistically do and instead design into
FSv2. But my lack of confidence stems only from my own knowledge and
experience, and Julian's will necessarily differ. So really, he alone can
make this decision.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-10-28 20:29:15 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.