[Dev] Propose getting rid of developer release

[John Anderson]

Alec Flett wrote:

> John Anderson wrote:
>
>> I think it makes sense to have an end-user version that is stripped 
>> of all the unnecessary stuff, e.g. unused Python packages, pylint, 
>> pychecker, epydoc tests etc. if it reduces our footprint. Do we have 
>> any idea how much space can be saved by doing this?
>>
> I have to agree. In particular, I feel like pylint and epydoc are 
> really meta-development features - i.e. once you're already a 
> fully-fledged chandler developer, then you might want to actually use 
> these tools to improve code.
>
> Further, I don't think a "debug" version is very helpful if the 
> distinguishing characteristic is that it includes wx symbols. I 
> develop for chandler every day and have not done a "full" build of wx 
> in perhaps 3 months. Even when I did all the calendar UI/gradient work 
> I never needed more than a "make install" build. This is the kind of 
> development we should be encouraging for chandler, not environments 
> where people are loading up Visual C++ or gdb.

The distinguishing characteristic of the "debug" version that I find 
most useful is the asserts in Chandler, wx, and Python -- in that order. 
Last weekend I discovered that if you quit Chandler while editing a 
field in the Summary or Sidebar, Chandler crashes. I would have never 
discovered that if I weren't running the Debug version.

Today almost nobody runs the debug version -- I suspect mostly because 
it's slower. On Windows it's awkward to setup cygwin for most users just 
to do a build. On Mac you also have to install the developer disks, 
which some people don't want to do. Then you have to wait forever while 
the build runs -- or fails like it did over the weekend. If we make 
everyone jump over all these hurdles to run the debug version, even 
fewer people will run it and we'll miss bugs. Instead, I think we need 
to make the debug version easier to run (and not too slow), not harder 
to run.

>
> As for footprint, Python itself is 56M? I just looked, and did a 
> breakdown:
> wxPython: 21M
> Twisted: 4M
> PyICU + ICU: 13M
> PyLucene: 4.5M
>
> Total 3rd party libraries in site-packages, plus ICU: 48M
>
> I don't care how cheap disk space is these days, we're starting to 
> seem like OpenOffice if it takes more than 60M on disk just to run a PIM!
>
> I'm not sure what we can do about this right this moment, but its food 
> for thought.
>
> Alec
>
>> That said, if possibile, I think the end-user version should be 
>> identical to the developer versions, except for some missing files.
>>
>> I also think it's useful to have a "debug" version that can be 
>> downloaded, i.e. you don't have to build it. I find a significant 
>> number of bugs with the debug version, so I assume other people will 
>> too -- and building Chandler is too difficult for most people.
>>
>> John
>>
>> Heikki Toivonen wrote:
>>
>>>Bug 4743 asks us to add RunChandler scripts to the end user version of
>>>Chandler. This means we also need to include python executable and
>>>RunPython script. We've already added tools directory to the end user
>>>version.
>>>
>>>Since it seems the end user version is becoming more and more like the
>>>developer version I think we should again consider dropping the
>>>developer version and just adding all we want in the end user version,
>>>making it the one and only Chandler distribution.
>>>
>>>So it seems we need at least:
>>>
>>>tools
>>>RunChandler etc
>>>
>>>added in the end user distribution.
>>>
>>>I think we should also add:
>>>
>>>pylint, pychecker, epydoc?
>>>tests?
>>>
>>>Note that all of these are needed/used by some of the scripts in tools/.
>>>
>>>
>>>With the end user version people would have the option of editing
>>>RunChandler to remove -O argument for Python, which would get them a bit
>>>more debugging information than with what comes out of the box.
>>>
>>>The only thing people would miss are the debug symbols built into the
>>>components that were native code (C/C++). My opinion is that people who
>>>want this should just build Python etc. themselves, i.e. doing a
>>>Chandler full build.
>>>
>>>
>>>Going with one distribution per platform would have several advantages:
>>>
>>>* Simplify it for the people who come to download Chandler
>>>* Simplify it for developers, less need to guess what build/which
>>>distribution
>>>* Reduce manifest files from 6 to 3 - less work and possibilities of
>>>messing up
>>>* Reduce work needed by Tinderbox clients - Tbox clients cycle faster
>>>* Less space needed on download servers
>>>
>>>
>>>Opinions?
>>>
>>>  
>>>
>>>------------------------------------------------------------------------
>>>
>>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>>Open Source Applications Foundation "Dev" mailing list
>>>http://lists.osafoundation.org/mailman/listinfo/dev
>>>  
>>>
>>------------------------------------------------------------------------
>>
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>>Open Source Applications Foundation "Dev" mailing list
>>http://lists.osafoundation.org/mailman/listinfo/dev
>>  
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20051129/7d6ff942/attachment.htm