Hi Kristis, I just did some basic testing with Bugzilla 3.6rc1 too (since I see final release is planned for quite soon). No problems observed so far: adding comments and changing status seems viable (with same this patches + adding 3.6 to the "latest" version_type).
Regards, Yavor On Tue, Apr 6, 2010 at 16:36, Kristis Makris <[email protected]> wrote: > Hi Yavor, > > These seem like great patches. I'll be able to have a closer look soon. > > Kristis > > On Sun, 2010-04-04 at 23:40 +0300, Yavor Nikolov wrote: > > Hi, > > > > As promised - I'm sending the patched version of Bugzilla.pm. I tested > > with latest versions only (scmbug 0.2.6.17 and Bugzilla 3.4.6): > > + Removed bz_lock/unlock_tables since that is incompatible with > > Bugzilla 3.2.x+. Transaction management implemented instead with > > bz_{start, commit, rollback}_transaction > > + Some checks have been removed since Bugzilla API has built-in > > checks when changing bug status & resolution. > > + A modified version of my previous fix in integration_add_comment is > > also included. I did it 1) to place bug update in transaction block; > > 2) to better handle logging and feedback on error (the problem was > > that with invalid user Bug->check calls die and things abort quite > > abruptly - svn user didn't get a message for root cause). > > > > Best regards, > > Yavor > > > > On Sun, Apr 4, 2010 at 00:47, Yavor Nikolov <[email protected]> > > wrote: > > Hi Kristis, > > > > (1) Replacing bz_{lock,unlock}_tables with > > bz_{start,commit,rollback}_transaction prevented the error > > from occurring and seemed updating to RESOLVED FIXED worked > > fine. (I haven't tested other scenarios). > > (2) Anyway - I have implemented status/resolution updating > > using Bugzilla perl API instead of direct database updates > > (seems more robust approach otherwise I'm afraid we may cause > > database corruption if database schema changes in future > > bugzilla versions /or maybe even this one/). > > > > I'll upload the patch for (2) soon. (I just want to add my > > changes in is_latest_version block since in current version > > I've probably broken some old version compatibility). So far > > things seem to work OK In my environment (tested changing to > > RESOLVED FIXED, ASSIGNED, ASSIGNED <user>, REOPENED, DUPLICATE > > <dup-id>). > > > > * Looking at scmbug Bugzilla.pm tracker code (and the modified > > method in particular) - things are getting much bloated with > > these many version-specific if/else if cases. I just wonder - > > wouldn't it be better to just refactor version-specific code > > as separate sub-classes (the right one instantiated by Daemon > > depending on specified version; or on specified class name)? > > That would make things look simpler and easier to maintain - > > at least for the most recent bugtracker versions. > > > > Regards, > > Yavor > > > > > > > > On Fri, Mar 26, 2010 at 21:31, Yavor Nikolov > > <[email protected]> wrote: > > Hi Kristis, > > > > > > On Fri, Mar 26, 2010 at 21:15, Kristis Makris > > <[email protected]> wrote: > > Hi Yavor, > > > > This is a big mistake on my part. I'm sorry. > > > > I thought that the status resolution work > > needed was already included in > > the patches from Elias and Uditha. I was not > > aware of the fact that > > bz_lock_tables was causing problems. > > > > On Fri, 2010-03-26 at 18:09 +0200, Yavor > > Nikolov wrote: > > > Sorry for the wrong subject from initial > > report of this issue. > > > > > > Seems bugzilla 3.2+ removed bz_lock_tables > > in it's code and is > > > handling database changes in > > > bz_start_transaction/bz_commit_transaction > > blocks. > > > > > > I can see some earlier complains for this > > problem.. but it has been > > > announced that v0.26.17 is supporting status > > changes for bugzilla 3.4 > > > now. > > > > > > Do you recall where ? I can't find it any > > report related to > > bz_lock_tables in the issue-tracker. > > Google for scmbug and bz_lock_tables may help for > > this. In particular I see following is related: > > > http://permalink.gmane.org/gmane.comp.bug-tracking.scmbug.user/2106 > > However Alex's patch has just commented these calls to > > bz_lock_tables. I'm not sure what would be the best > > way to handle this - but at least seems a better idea > > to add bz_start_transaction/bz_commit_transaction as > > replacement of removed bz_lock*/bz_unlock* statements. > > Something similar has been mentioned here: > > http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.pyrzak% > > 40gmail.com > &passw=&list=developers&brief=on&func=archive-get-part&extra=200703/31 > > > > > > Regards, > > Yavor > > > > > > >
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
