Re: [Pythoncard-users] Pythoncard fork: latest post here.

[Alex T. <al...@tw...>]

Nextime wrote:
> On Wed, Nov 26, 2008 at 10:36:54PM +0000, Alex Tweedly wrote:
>   
>> Nextime wrote:
>>     
>>> Hello all.
>>>
>>> As a demostration that nothing is moving here, after few posts saying  
>>> "i don't agree with a fork", nothing more on this list or in
>>> developement of PythonCard.
>>>
>>>   
>>>       
>> Other than my post on the 13th ?
>> I haven't yet seen any reply to what I said.
>>     
>
>
> Sorry but i don't see nor in the archive nor in my email any post from
> you on the 13th.
>
>   
Hmmmm - odd. I know I sent it, and received a copy of it back - no idea 
why you don't / didn't see it.

Most of it is probably out of date now, so I'll include just the two 
most relevant paragraphs again here :
>  What new things do we have ?  Which of them are *ready* to go into 
> the actual project ?
>
>  I know for sure that my sizer code isn't ready to be committed. 
> That's why it's on a separate website - it's still 'experimental'. It 
> hasn't been tested anywhere near enough to be ready to put it into 
> CVS. It's fine for someone who has been actively following discussions 
> to try something that may break, or behave strangely, or indeed may 
> work but just not be the right approach in the long run; but it would 
> be very wrong to put such experiments into the repository where anyone 
> trying out Pythoncard for the first time is exposed to those dangers.

>>>  - Patched with changes from Alex Tweedly for sizers
>>>   
>>>       
>> I strongly recommend that these not be used, other than for testing  
>> purposes.
>>     
>
> Well, do you know the words "developement version" and "pre-release"?
>
>   
Yes, thanks. I have spent a few years managing software development 
groups of 150+ engineers - I'm far too familiar wth both those terms 
:-)  And with the wide variety of meanings people attach to each of them.
> This is not a "stable download released" but a developement one.
> When those changes are tested enough they will be released as default
> download, for the moment they are in a developement version.
>
> Also, if you don't put the code in a branch or in a developement
> version, how can anyone test it and give you feedback?
>
>   
How can anyone test it or give feedback ?  Easy -
   I put it on a website.
   I announced it on the pythoncard-users list.
   A number of people (including you) managed to find it;
          quite a few expressed some interest in it;
           but very, very few tested it and provided any feedback.

All the other changes I made to Pythoncard followed the same, or 
similar, process:
 - put code (or diffs) on a website OR send them directly to fellow 
collaborators
 - announce to users list
 - get feedback, update, .....
 - once there has been enough feedback and/or enough bugs fixed, post 
diffs to developers list
 - incorporate any developer changes / suggestions
 - then and only then put into cvs

That worked pretty well, until we got the sizer changes. A good number 
of people were interested - but not sufficiently to actually test it 
thoroughly. That kind of convinced me that there was actually less need 
than I had thought, as confirmed by my own experience.

I found that many times I used Pythoncard for a quick, simple GUI for my 
own use without needing sizers (and if I wanted to use it 
cross-platform, then I'd just adjust things). If I did want to release 
the program to other people, I'd do so after some time - so the basic 
layout, controls, components, etc. were fairly settled - and in that 
case, it wasn't a big deal to put the sizers in as code (as is done, 
e.g., in 'findfiles'). And for the early experimentation, I much 
referred the static layout of the existing editor to the thought and 
effort needed to organize and put components into sizers). So even I 
didn't actually use the sizer changes enough :-)

Net result - it just hasn't been tested that much. It's at a very 
different stage of readiness than the rest of the code in the Pythoncard 
repository.
>> I'll look at any feedback (on this list), but can't guarantee  
>> to respond in a timely manner.
>>     
>
> You can have feedback if you put your code in Pythoncard, but the
> codebase of Picard will be different from the Pythoncard soon, so,
> feedback  from Picard will not be the one that you want here.
>
>   
I can have feedback from anyone who wants to download it from 
tweedly.net and test it - it's been there for almost 3 years now, 
without gathering much feedback. (Anyone who wants the URL, or docs, 
etc. can contact me off-list.)
> I will look at any feedback and i try to respond in timely manner on the
> right mailing list for the project *with* the code to be tested.
>
>   
>> I do not stand behind these  
>> not-yet-properly-tested changes, and I think it's a bad idea to have  
>> them included in the default download.
>>     
>
> It is a svn trunk version... not a default download.
>
>   
The way I read your email, these changes were (or were going to be) 
included in the svn trunk - so no-one can dowload Picard without getting 
these changes included. If that's not the case, and people can get the 
reliable version of the layoutEditor or *choose* to get this version, 
then that's fine. But if these changes come included by downloading 
Picard, then I think it would be worth a specific warning about this 
part of the code (though you could argue this email thread should be 
enough of a disclaimer).

Good luck

-- Alex.