From: Nextime <ne...@ne...> - 2008-11-28 00:00:06
|
On Thu, Nov 27, 2008 at 10:50:30PM +0000, Alex Tweedly wrote: > 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 I don't agree with this method. In my opinion, any changes or patch shuld be committed on an experimental branch (or even in trunk/HEAD for little projects ), only this way people interested in the developement version can test it and provide feedback in an actively manner. When and if the changes will be considered stable enough, they will be included in the release branch, or tag, or stable, or what you want to call it. This is how most of the projects go ahead, and i think is the only way to let developers that know what they do find, test, and patch or reply with feedback. > 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 don't agree. It don't work pretty well if we have about 1 commit a year. Also, this isn't the only one issue. Also there is the problem of the devel ml not responsive, and i don't want to see an answer to every message in few minutes/hours, but i want an answer at least in 1/2 weeks where i ask about the status of the project. Exceptions permitted, of course, but Jesus, this is the usual way on pythoncard, not an exception. > 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). I agree in this. Me too. But this isn't a reason to let the project stalled for *TWO YEARS*! > 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. Yes, no one can download it without those changes included. Exactly, no one can download the new *developement* branch without those changes included. When and only when i will release something that i will call "stable" you can argue with those things. > 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). People that download a trunk developement branch from an svn usually know what they do. People that don't know what to do, usually don't know how to use an svn repository nor how to install something that isn't an exe or msi installer. Anyway, after all, i've done my choice. I now have a fork with the things i want to have, i will have a new project that will evolve more quickly, probably in different direction of pythoncard. Anyone is free to follow me or to stay here... to wait something moving. > Good luck Thanks. -- Franco Lanza My blog: http://www.nexlab.it email: ne...@ne... Fax/Tel: +39 0331 682151 Cell: +39 339 8125940 Busto Arsizio (VA) - Italy ----------------------------------- Per consulenze telefoniche chiamate: ** 899.161.414 ** Servizio riservato ai maggiorenni, tariffazione flat Euro 15 iva inclusa (solo scatto alla risposta) abilitazione decreto ministero delle comunicazioni n. 145 del 02/03/2006, offerto da Deram Srl in collaborazione con UnixMedia Srl ----------------------------------- NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 ----------------------------------- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc ----------------------------------- |