On Sun, Jan 18, 2009 at 2:48 PM, Doug Philips <[email protected]> wrote: > On or about Sunday, January 18, 2009, at 09:24AM, TK Soh indited: >>On Sun, Jan 18, 2009 at 8:44 AM, Peer Sommerlund wrote: >>> Have you considered making at least one RC release part of the release >>> process? >> >>Release candidates are good to have. But with tortoisehg being very >>far from 1.0, we expect to see a lot of bug reports on each releases >>(and release candidates too). So I am not sure how much RC can really >>help us. > > Interesting. I guess I have a different philosophy. > > To me it feels from the discussions as if there are large parts which are > stable and "done." > Having RC prior to 0.X, to me, gives more people a chance to shake out bugs > in what is being released.
In my experience, non-developer users don't spend much time really testing the new releases. They just use them as usual, and report bugs if they find any along the way. As the project grows more mature, bugs become harder to find (hopefully), and it take longer to discover. I'm also getting a feeling that most bugs are discovered by new users, or those recently begin to use the features new to them. However, RC's will certainly help if there are some drastically new features/changes in the releases. Then again, developer resources remains a key factor. >>> I know that the developer count is 1 + 0.5 + 0.1 + 0.01 which is not much. >> >>Exactly (actually the '1' is more like 0.3 these days. We really need >>more 'full-time' developers) > > I'd agree with that. Too bad you didn't pick wxPython instead of Qt, that > would make -my personal contribution- much easier... :) We had to pick one. Actually PyGTK isn't that hard to learn, though I do wish they have more documentation on the usage. >>It takes a lot of energy to cut one release of TortoiseHg, and it's >>not really something I can afford very often. If anyone would like to >>volunteer to take care of this, then maybe we can make the release >>process more 'formal', ie. RC before final release. >> >>Hopefully thing will be simpler by the time we are done simplifying >>the build process. > > I believe this is a critically serious problem. > If the main developer(s) find the process so hard that they have to do it > only when necessary, that makes it virtually impossible for a potential > part-time contributor to step up, change something and test it before > submitting a patch. As I mention in the other reply, I was referring to building the installer. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
