Yeah, thanks for the tip :) Above was really a question of disagreement with that workingDirectory -> branch thing, simply because IMHO, branches should be planned and managed following set criteria and purpose (again that's just me). Of course, there are many possible avenues, and it is possible I am talking through my hat here, and I have never met Professor Di Pierro but I do know he has dreamed up this great thing then brought it to life. So that has to be the the leading concern when wrt requirement/guide line to establish what needs to happens (at a high level) and here, it is clear:
“... the less I use mercurial the better. For example I keep one single branch of web2py. I simply apply patches, test them, and either revert or commit. This model has worked well for me and I would not like to change it. “ If this model helps Mr Di Pierro and enables him, then I say, by all means, lets start there and then fashion the tooling around that (even if we need to make Mercurial have the look and feel or Perforce, or CVS, etc... or what ever it takes). Its all do-able. Under-layers of getting code-to-production can still be improved without adding extra grief for Mr Di Pierro's. WRT bug tracking: a bug tracking system in the key of web2py!? What a great idea! And what better way to integrate a bug tracking system to a web2py front end for Mercurial than to integrate it with a web2py front end for Mercurial? Of course, handling permissions and privileges would be a challenge? Maybe not? (I'm thinking the contributing community vs web2py leads/leader)... but that just may be logistical. Mart :) On Aug 24, 6:52 pm, Michele Comitini <michele.comit...@gmail.com> wrote: > Actually I would like to ask if bug tracking is used on web2py? > > Code is available from either (btw Massimo how do you keep those 2 in > sync? just too curious :-) ): > a) googlecode (with hg) > b) launchpad (with bzr) > > both have some sort of bugtracking ticket system I do not know which > one is best (or worst), we could start with one those, but > the choice must taken with care and other systems must be evaluated > (on: usability, independece, web2py phylosophy ...), and first > they must meet Massimo needs. > > BTW: I would like to see a web2py application for doing serious > bugtracking in the future... so that submitting > a bug would be just one click on the ticket reported by any web2py > installation! mmm too easy... that would be dangerous! ;-) > > ciao, > mic > > 2010/8/24 mart <msenecal...@gmail.com>: > > > I don't know if you are currently using a specific bug tracking > > system, but they are typically easy to interface with and made part of > > build/release & test processes/automation. I.e. As part of a release > > process, I would set rules with the source control system where non- > > bugTraking releated changes can either be automatically rejected, or > > moved to another set of prioritiesArea, etc... the build (or packaged > > fileset, or whatever the output is) contains a detailed inventory of > > bug fixes/features/etc... as part of an automated delivery system > > (these are part of the build notes)...
