On Mon, Jan 19, 2009 at 5:30 AM, Douglas Philips <[email protected]> wrote: > On 2009 Jan 18, at 7:07 PM, TK Soh wrote: >> >> 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 find this attitude puzzling. Perhaps it is because building the installer > is just too much work? > Frankly I don't see the problem with saying: "We're one week out from the > release, time for a RC build." > If no issues come up, then push the button again and build the final > release.
It's more complicated than that. At least in our case. It has nothing to do with attitude, just a different view. For the record, I am not against the release of RC, and understand the [good] purpose it serve. In case you are not aware of, we actually did it with 0.4 (took use quite a few RC's to finally release). I just don't feel have the capacity to manage it. > That at least gives folks who have opened bugs a chance to validate the > fixes, if they choose. > Maybe they won't choose, but the only loss here is the push of a button and > some uploads. > I admit, even with full automation it is not blindingly trivial, but if it > is non-trivial, I feel it critical to make it trivial instead of focusing on > how to avoid building releases. > >> We had to pick one. Actually PyGTK isn't that hard to learn, though I >> do wish they have more documentation on the usage. > > Understood. > >>> 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. > > As was I. It should not be that hard. > And yes, I looked at the page for installing source to patch/develop > against, and no it isn't simple, esp. if one has only one Windows machine on > which one has to run real work on. I don't have the luxury of a spare > Windows box to do from-source TortoiseHg work on, and one machine on which I > have to do my paying-$$-real-job. Let alone trying to debug the interactions > between a from-source setup and a installer setup (since I have to support > other members of my group with the released version that we are using). > > Well, either I'm confused or it just doesn't matter. Thanks for listening. > > -Doug > > > ------------------------------------------------------------------------------ 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
