From gerv at mozilla.org Thu Feb 2 16:14:49 2012 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 02 Feb 2012 16:14:49 +0000 Subject: New Bugzilla Release Manager In-Reply-To: References: Message-ID: <4F2AB679.1080706@mozilla.org> On 31/01/12 23:51, David Miller wrote: > Fortunately, Dave Lawrence (dkl) has stepped up to take on the Release > Manager role for Bugzilla. Dave's been helping with it for the last > couple releases, and been doing awesome, and today's release is the > first one he's actually doing in an official capacity. Awesome :-) Congratulations, dkl. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From deepakpatil84 at gmail.com Wed Feb 8 09:21:57 2012 From: deepakpatil84 at gmail.com (Deepak Patil) Date: Wed, 8 Feb 2012 14:51:57 +0530 Subject: Bugzilla - New Front End Message-ID: Hello , Presently i am working on a project to create new Front End for bugzilla in JSP using OpenWAF(openwaf.com) This project is opensource (not yet hosted anywhere .Planning to host on code.google.com with Apache 2.0 license) This will work on existing bugzilla database i.e. only dbschema will be used from bugzilla project. So is there any licensing or legal issue by doing this ? Screenshots http://openwaf.com/bugzilla/Groups.png http://openwaf.com/bugzilla/Products.png http://openwaf.com/bugzilla/FieldValues.png http://openwaf.com/bugzilla/NewBug.png Thanks and Regards Deepak Patil http://openwaf.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepakpatil84 at gmail.com Wed Feb 8 18:58:02 2012 From: deepakpatil84 at gmail.com (Deepak Patil) Date: Thu, 9 Feb 2012 00:28:02 +0530 Subject: Bugzilla - New Front End In-Reply-To: <4F3284C1.2020000@mozilla.org> References: <4F3284C1.2020000@mozilla.org> Message-ID: Since the technology is different , i am going to write everything from scratch. By doing this it will be ensured that no code will be copied from bugzilla project. Regarding motivation for doing this, Bugzilla is most popular open source bug tracking system. But it is implemented in old technology which involves many postbacks and makes browsing little(more?) slow. At least i can say not as friendly as today's web 2.0 applications. I want to keep it very simple and very similar to bugzilla so that migration will be very easy. i.e. Just install Web application and give access to existing bugzilla database. I understand bugzilla is pretty big project so i am going step by step. First create basic bug browser/editor and some part of reporting. Not considering testopia and other plugins right now. Regarding license, since this will be open source project. We can release it with any license which will be beneficial to the community and keep it free. So can i go ahead with this ? Regards, Deepak Patil On Wed, Feb 8, 2012 at 7:50 PM, Gervase Markham wrote: > On 08/02/12 09:21, Deepak Patil wrote: > >> So is there any licensing or legal issue by doing this ? >> > > It depends. > > Here is a rough rule of thumb: if you have copied and pasted any code or > information from Bugzilla files, then the files you have copied them into > (even if you subsequently went through "converting" to JSP and deleting the > old stuff) need to be licensed under the MPL. > > If you just read the documentation and wrote the code from scratch, you > can license it how you like. > > Can I ask, though: what motivated you to do this project? It seems like a > great deal of work. Are you planning to reimplement the entirety of > Bugzilla in Java? Bugzilla is a lot more than a database and a display > system. > > Gerv > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepakpatil84 at gmail.com Tue Feb 7 09:07:19 2012 From: deepakpatil84 at gmail.com (Deepak Patil) Date: Tue, 7 Feb 2012 14:37:19 +0530 Subject: Bugzilla - Ajaxified(New Project) In-Reply-To: References: Message-ID: Hello Bugzilla Team, I have few questions regarding licensing and legal things. First Let me tell you what exactly i am doing. I am presently working on a project to Ajaxify Bugzilla. This will be totally new code for front end and database access. and only existing bugzilla database will be used. I am using OpenWAF (openwaf.com) as Toolkit/Framework for this project. This project will be Open Source with apache 2.0 license(or any other in case) So the question is ..since this does not share any code from bugzilla and only same DB schema is used to use it as alternative to existing bugzilla installation. Is there any legal or licensing violation issue by doing this. Once again this project will be totally open source and will be hosted on code.google.com or similar. I have attached few screenshots of current project status. So can i go ahead with this ? Thanks and Regards, Deepak Patil +919482569518 openwaf.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FieldValues.png Type: image/png Size: 30060 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Groups.png Type: image/png Size: 37192 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NewBug.png Type: image/png Size: 27513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Products.png Type: image/png Size: 31786 bytes Desc: not available URL: From gerv at mozilla.org Wed Feb 8 14:20:49 2012 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 08 Feb 2012 14:20:49 +0000 Subject: Bugzilla - New Front End In-Reply-To: References: Message-ID: <4F3284C1.2020000@mozilla.org> On 08/02/12 09:21, Deepak Patil wrote: > So is there any licensing or legal issue by doing this ? It depends. Here is a rough rule of thumb: if you have copied and pasted any code or information from Bugzilla files, then the files you have copied them into (even if you subsequently went through "converting" to JSP and deleting the old stuff) need to be licensed under the MPL. If you just read the documentation and wrote the code from scratch, you can license it how you like. Can I ask, though: what motivated you to do this project? It seems like a great deal of work. Are you planning to reimplement the entirety of Bugzilla in Java? Bugzilla is a lot more than a database and a display system. Gerv From gerv at mozilla.org Thu Feb 9 13:04:06 2012 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 09 Feb 2012 13:04:06 +0000 Subject: Bugzilla - New Front End In-Reply-To: References: <4F3284C1.2020000@mozilla.org> Message-ID: <4F33C446.6020904@mozilla.org> On 08/02/12 18:58, Deepak Patil wrote: > Regarding motivation for doing this, Bugzilla is most popular open source > bug tracking system. But it is implemented in old technology which > involves many postbacks and makes browsing little(more?) slow. At least i > can say not as friendly as today's web 2.0 applications. That may be so, but you could fix that without a rewrite - just create a new set of templates, and use the web services interface to make the changes. This would be excellent, and far less work. > I want to keep it very simple and very similar to bugzilla so that > migration will be very easy. i.e. Just install Web application and give > access to existing bugzilla database. I think you are perhaps underestimating the amount of work this would be. How long do you think you'd need to spend on it? It's taken 14 years to develop Bugzilla... > So can i go ahead with this ? We don't have any rights to stop you :-) That's the joy of open source. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From jochen.wiedmann at gmail.com Fri Feb 10 10:42:36 2012 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 10 Feb 2012 11:42:36 +0100 Subject: Bugzilla - New Front End In-Reply-To: <4F3284C1.2020000@mozilla.org> References: <4F3284C1.2020000@mozilla.org> Message-ID: That's certainly true. But, given the technology that he uses, there's only one thing he might copy and that's the database schema. AFAIK, the schema's available as a set of Perl modules only, and not as a set of SQL commands. How about reverse engineering the schema. Would you consider that a problem? Jochen On Wed, Feb 8, 2012 at 3:20 PM, Gervase Markham wrote: > On 08/02/12 09:21, Deepak Patil wrote: >> >> So is there any ?licensing or legal issue by doing this ? > > > It depends. > > Here is a rough rule of thumb: if you have copied and pasted any code or > information from Bugzilla files, then the files you have copied them into > (even if you subsequently went through "converting" to JSP and deleting the > old stuff) need to be licensed under the MPL. > > If you just read the documentation and wrote the code from scratch, you can > license it how you like. > > Can I ask, though: what motivated you to do this project? It seems like a > great deal of work. Are you planning to reimplement the entirety of Bugzilla > in Java? Bugzilla is a lot more than a database and a display system. > > Gerv > - > To view or change your list settings, click here: > -- "Bildung kommt von Bildschirm und nicht von Buch, sonst hie?e es ja Buchung." Dieter Hildebrandt From emmanuel.seyman at club-internet.fr Fri Feb 10 11:04:06 2012 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 10 Feb 2012 12:04:06 +0100 Subject: Bugzilla - New Front End In-Reply-To: References: <4F3284C1.2020000@mozilla.org> Message-ID: <20120210110406.GA29922@orient.maison.lan> * Jochen Wiedmann [10/02/2012 11:55] : > > AFAIK, the schema's available as a set of Perl modules only, and not > as a set of SQL commands. How about reverse engineering > the schema. Would you consider that a problem? Given that all you need to do to get the schema is to install bugzilla then dump the database, I don't really see this as a problem. Emmanuel _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Tue Feb 14 16:25:00 2012 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 14 Feb 2012 17:25:00 +0100 Subject: Bugzilla meeting on Wednesday, February 15th, 2012 (16:00 GMT) Message-ID: <4F3A8ADC.2090408@gmail.com> Hi all, We will have a Bugzilla meeting on IRC tomorrow (Wednesday, Feb 15) at 16:00 GMT, in the #bugzilla-meeting channel. We didn't have any meeting for the last 8 months, so it's high time to talk together again. :) It will be focused on the release of Bugzilla 4.2 final, and the short term goals towards 4.4. Other topics can be discussed depending on questions and remarks made during the meeting. Everyone is free to attend, as usual. LpSolit From gerv at mozilla.org Wed Feb 15 11:37:29 2012 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 15 Feb 2012 11:37:29 +0000 Subject: Bugzilla meeting on Wednesday, February 15th, 2012 (16:00 GMT) In-Reply-To: References: Message-ID: On 14/02/12 16:25, Fr?d?ric Buclin wrote: > We will have a Bugzilla meeting on IRC tomorrow (Wednesday, Feb 15) at > 16:00 GMT, in the #bugzilla-meeting channel. We didn't have any meeting > for the last 8 months, so it's high time to talk together again. :) It > will be focused on the release of Bugzilla 4.2 final, and the short term > goals towards 4.4. Other topics can be discussed depending on questions > and remarks made during the meeting. Everyone is free to attend, as usual. Great - although it would be awesome if, in future, a little more notice could be provided :-)) See you in 5 hours, Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Feb 15 20:59:29 2012 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 15 Feb 2012 20:59:29 +0000 Subject: Bugzilla meeting on Wednesday, February 15th, 2012 (16:00 GMT) In-Reply-To: References:

Message-ID: On 15/02/12 11:37, Gervase Markham wrote: > See you in 5 hours, Oops. Is there an IRC transcript? :-| Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From netfuzzer at gmail.com Wed Feb 15 21:01:43 2012 From: netfuzzer at gmail.com (Mario Gomes) Date: Wed, 15 Feb 2012 19:01:43 -0200 Subject: Bugzilla meeting on Wednesday, February 15th, 2012 (16:00 GMT) In-Reply-To: References:

Message-ID: what? 2012/2/15 Gervase Markham : > On 15/02/12 11:37, Gervase Markham wrote: >> >> See you in 5 hours, > > > Oops. Is there an IRC transcript? :-| > > > Gerv > > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > From lpsolit at gmail.com Wed Feb 15 23:04:56 2012 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 16 Feb 2012 00:04:56 +0100 Subject: Bugzilla meeting on Wednesday, February 15th, 2012 (16:00 GMT) In-Reply-To: References:

Message-ID: <4F3C3A18.8090007@gmail.com> Le 15. 02. 12 21:59, Gervase Markham a ?crit : > Oops. Is there an IRC transcript? :-| http://logbot.glob.com.au/?c=bugzilla-meeting&a=date&s=15+Feb+2012&e=15+Feb+2012&h= LpSolit From anfisher at yahoo.com Thu Feb 16 02:31:21 2012 From: anfisher at yahoo.com (Andy) Date: Wed, 15 Feb 2012 18:31:21 -0800 Subject: API Access to series_data Table Message-ID: Does anyone know if it's possible to use the Bugzilla API to get read access to / query against the "series" and "series_data" tables? (If not, then I'll plan on querying directly against the database). Thanks _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mgoodwin at mozilla.com Wed Feb 15 21:29:27 2012 From: mgoodwin at mozilla.com (Mark Goodwin) Date: Wed, 15 Feb 2012 21:29:27 +0000 Subject: Bugzilla meeting on Wednesday, February 15th, 2012 (16:00 GMT) In-Reply-To: References:

Message-ID: <4F3C23B7.5050001@mozilla.com> On 15/02/2012 20:59, Gervase Markham wrote: > Oops. Is there an IRC transcript? :-| Yes: http://logbot.glob.com.au/?c=bugzilla-meeting _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Thu Feb 16 11:02:43 2012 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 16 Feb 2012 11:02:43 +0000 Subject: API Access to series_data Table In-Reply-To: References: Message-ID: On 16/02/12 02:31, Andy wrote: > Does anyone know if it's possible to use the Bugzilla API to get read > access to / query against the "series" and "series_data" tables? (If > not, then I'll plan on querying directly against the database). It is not possible. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Fri Feb 24 14:30:01 2012 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 24 Feb 2012 14:30:01 +0000 Subject: Locking bugs temporarily? Message-ID: I have an extension which integrates Bugzilla with another system. At the moment, it's possible for me to get a Bug object and, while I am working out how to change it as part of the sync, for someone else to update the bug. My changes then overwrite theirs. Obviously, there's a fairly small time window, but occurrences of this have been noted. I can't really implement conflict resolution logic - that needs a human. So I'd really like to lock the bug when I get a copy, make my update e.g. 2 seconds later, unlock it, for their change to then try and be committed and for _them_ (the human) to get a mid-air that they can resolve however they like. Is it possible to temporarily lock a bug? Either within Bugzilla or using a direct database command on a table row? Would that screw things up? Is there a better way of solving this? We are using MySQL and, at the moment, Bugzilla 3.6. Thanks, Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From dmarshal at yahoo-inc.com Fri Feb 24 16:47:05 2012 From: dmarshal at yahoo-inc.com (David Marshall) Date: Fri, 24 Feb 2012 08:47:05 -0800 Subject: Locking bugs temporarily? In-Reply-To: Message-ID: I don't like hard locks such as what you get with SELECT ... FOR UPDATE because they're better for database integrity than for mutual exclusion. Fortunately, you can use MySQL as a source of mutual exclusion with the GET_LOCK function: http://dev.mysql.com/doc/refman/5.1/en/miscellaneous-functions.html#function _get-lock SELECT GET_LOCK("bug:12345", 10) [or whatever] Of course, that's an advisory lock only! It's up to you to identify exactly which transactions should respect the lock. PostgreSQL implements advisory locks somewhat differently: http://www.postgresql.org/docs/9.1/static/explicit-locking.html#ADVISORY-LOC KS A truly enterprising chap could add subroutines Bugzilla::Object::lock, Bugzilla:Object::is_locked, and Bugzilla::Object::release_lock that take advantage of subroutines in Bugzilla::DB. I'm guessing that the overhead in fiddling with advisory locks is pretty low, albeit non-zero. I haven't though about it enough to say whether it's worth it for objects to deal with them by default. At Yahoo!, in addition to bug mid-airs, we also implement our own product mid-airs. With 4832 products (as of this morning), we have "product administrators" who can modify products. Some products have dozens of administrators, who can and do occasionally try to modify the same thing at the same time. On 2/24/12 6:30 AM, "Gervase Markham" wrote: > I have an extension which integrates Bugzilla with another system. At > the moment, it's possible for me to get a Bug object and, while I am > working out how to change it as part of the sync, for someone else to > update the bug. My changes then overwrite theirs. Obviously, there's a > fairly small time window, but occurrences of this have been noted. > > I can't really implement conflict resolution logic - that needs a human. > So I'd really like to lock the bug when I get a copy, make my update > e.g. 2 seconds later, unlock it, for their change to then try and be > committed and for _them_ (the human) to get a mid-air that they can > resolve however they like. > > Is it possible to temporarily lock a bug? Either within Bugzilla or > using a direct database command on a table row? Would that screw things > up? Is there a better way of solving this? > > We are using MySQL and, at the moment, Bugzilla 3.6. > > Thanks, > > Gerv > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Sun Feb 26 04:50:47 2012 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 25 Feb 2012 20:50:47 -0800 Subject: Locking bugs temporarily? In-Reply-To: References: Message-ID: <4F49BA27.6000306@bugzilla.org> My original plan for the API on this was to allow people to pass a parameter to Bug.update, perhaps "check_conflicts => (time)", which would then return an error if there had been changes since the specified time. The error would include the changes that had been made, in enough detail that an external app could re-create the "mid-air collision" page that Bugzilla currently has in its UI. One of the pre-requisites to this would be moving the mid-air collision logic into something re-usable in Bugzilla::Bug or something. -Max On 02/24/2012 06:30 AM, Gervase Markham wrote: > I have an extension which integrates Bugzilla with another system. At > the moment, it's possible for me to get a Bug object and, while I am > working out how to change it as part of the sync, for someone else to > update the bug. My changes then overwrite theirs. Obviously, there's a > fairly small time window, but occurrences of this have been noted. > > I can't really implement conflict resolution logic - that needs a human. > So I'd really like to lock the bug when I get a copy, make my update > e.g. 2 seconds later, unlock it, for their change to then try and be > committed and for _them_ (the human) to get a mid-air that they can > resolve however they like. > > Is it possible to temporarily lock a bug? Either within Bugzilla or > using a direct database command on a table row? Would that screw things > up? Is there a better way of solving this? > > We are using MySQL and, at the moment, Bugzilla 3.6. > > Thanks, > > Gerv > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/ From gerv at mozilla.org Mon Feb 27 09:41:03 2012 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 27 Feb 2012 09:41:03 +0000 Subject: Locking bugs temporarily? In-Reply-To: References:

Message-ID: <4F4B4FAF.8090304@mozilla.org> Hi Max, Thanks for taking the time - I know you are busy :-) On 26/02/12 04:50, Max Kanat-Alexander wrote: > My original plan for the API on this was to allow people to pass a > parameter to Bug.update, perhaps "check_conflicts => (time)", which > would then return an error if there had been changes since the specified > time. The error would include the changes that had been made, in enough > detail that an external app could re-create the "mid-air collision" page > that Bugzilla currently has in its UI. At the moment, if you pass a modification_time, the BzAPI will do collision checking and return an error if there's a collision. (It's up to the client to get a new copy of the bug, figure out how to merge the changes, perhaps with user assistance, and resubmit the request.) If you don't pass a modification_time, it does an unconditional overwrite. However, this doesn't solve the problem - my extension does not have the ability to talk to a "user" to resolve any mid-airs. Therefore, the mid-air needs to appear on the screen of the _other_ guy trying to change the bug - the real person. That means, I need to have a "lock" or something on the bug while I'm changing it, so that when the lock is released, _their_ change fails. I don't want users normally using the web interface to get a lock, only to respect my lock! :-)) Any thoughts on how to do that? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Mon Feb 27 09:55:57 2012 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 27 Feb 2012 09:55:57 +0000 Subject: Locking bugs temporarily? In-Reply-To: References: Message-ID: <4F4B532D.9020205@mozilla.org> On 24/02/12 16:47, David Marshall wrote: > Fortunately, you can use MySQL as a source of mutual exclusion with the > GET_LOCK function: Interesting :-) So the way to do it would be to change process.cgi and put a GET_LOCK call before getting data about each bug, and a RELEASE_LOCK call after updating it. Then, I could do the same in my extension. That way, only one bit of code could be updating a bug at once. Is that the idea? Do we currently have race conditions in process_bug? It grabs copies of all the necessary bugs (around line 112), checks for mid-airs (around line 150), but it only then opens a database transaction a bit later (on line 543). Surely some other process could perhaps update the bug in between, in which case some stale data might get written back to the bug? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Mon Feb 27 10:41:28 2012 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 27 Feb 2012 11:41:28 +0100 Subject: Locking bugs temporarily? In-Reply-To: <4F4B4FAF.8090304@mozilla.org> References:

<4F4B4FAF.8090304@mozilla.org> Message-ID: <4F4B5DD8.5090507@gmail.com> Le 27. 02. 12 10:41, Gervase Markham a ?crit : > mid-air needs to appear on the screen of the _other_ guy trying to > change the bug - the real person. That means, I need to have a "lock" or > something on the bug while I'm changing it, so that when the lock is > released, _their_ change fails. I don't see why BzAPI should have a higher priority on someone else's changes. You are not the only one to use remote clients to interact with Bugzilla, and the other client would have the same problem as you. So if you come after the other user, *you* should get the midair collision, not the other user. About GET_LOCK, depending on how it's used, you could easily block all changes to a single bug, if this lock isn't released for some reason. It sounds like a come back of LOCK TABLES to me, though not exactly the same thing. LpSolit From gerv at mozilla.org Mon Feb 27 12:03:57 2012 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 27 Feb 2012 12:03:57 +0000 Subject: Locking bugs temporarily? In-Reply-To: References:

<4F4B4FAF.8090304@mozilla.org> Message-ID: <4F4B712D.1040402@mozilla.org> On 27/02/12 10:41, Fr?d?ric Buclin wrote: > Le 27. 02. 12 10:41, Gervase Markham a ?crit : >> mid-air needs to appear on the screen of the _other_ guy trying to >> change the bug - the real person. That means, I need to have a "lock" or >> something on the bug while I'm changing it, so that when the lock is >> released, _their_ change fails. > > I don't see why BzAPI should have a higher priority on someone else's > changes. You are not the only one to use remote clients to interact with > Bugzilla, and the other client would have the same problem as you. So if > you come after the other user, *you* should get the midair collision, > not the other user. There appears to be some confusion here. My question is not about BzAPI, although part of the discussion with Max turned to what the BzAPI does. My question is more about my Sync extension. The reason the changes made by this extension need to have priority is that they are automatic syncings from another system, not in real time. I can't go back to that other system and say "you know the guy who committed a change 5 minutes ago? Get him back from his tea break, put him in front of a computer and get him to resolve this conflict". However, I can get the guy who is making a change in the 1 or 2 seconds between me requesting a copy of the bug data and me writing it - because he's still sitting at his computer, in front of a system I control (Bugzilla). So Sync changes need to always succeed, which means the real-life user has to get the mid-air. > About GET_LOCK, depending on how it's used, you could easily block all > changes to a single bug, if this lock isn't released for some reason. It > sounds like a come back of LOCK TABLES to me, though not exactly the > same thing. I wonder if it's possible to make the locks automatically time out after a certain length of time? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From wurblzap at gmail.com Mon Feb 27 13:39:42 2012 From: wurblzap at gmail.com (Marc Schumann) Date: Mon, 27 Feb 2012 14:39:42 +0100 Subject: Locking bugs temporarily? In-Reply-To: <4F4B712D.1040402@mozilla.org> References:

<4F4B4FAF.8090304@mozilla.org> <4F4B712D.1040402@mozilla.org> Message-ID: 2012/2/27 Gervase Markham > My question is more about my Sync extension. The reason the changes made > by this extension need to have priority is that they are automatic > syncings from another system, not in real time. I can't go back to that > other system and say "you know the guy who committed a change 5 minutes > ago? Get him back from his tea break, put him in front of a computer and > get him to resolve this conflict". However, I can get the guy who is > making a change in the 1 or 2 seconds between me requesting a copy of > the bug data and me writing it - because he's still sitting at his > computer, in front of a system I control (Bugzilla). > > So Sync changes need to always succeed, which means the real-life user > has to get the mid-air. > In order to avoid a mid-air, you need to lock as soon as changes start happening on your syncing system. Otherwise, changes might conflict. And if you say that change might have happened 5 minutes ago, then that's way too long a time for a lock imho. On a related note, what do you want to happen if two sync users conflict? Marc _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Tue Feb 28 08:07:11 2012 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 28 Feb 2012 00:07:11 -0800 Subject: Locking bugs temporarily? In-Reply-To: <4F4B4FAF.8090304@mozilla.org> References:

<4F4B4FAF.8090304@mozilla.org> Message-ID: <4F4C8B2F.9020008@bugzilla.org> On 02/27/2012 01:41 AM, Gervase Markham wrote: > However, this doesn't solve the problem - my extension does not have the > ability to talk to a "user" to resolve any mid-airs. Therefore, the > mid-air needs to appear on the screen of the _other_ guy trying to > change the bug - the real person. That means, I need to have a "lock" or > something on the bug while I'm changing it, so that when the lock is > released, _their_ change fails. I don't want users normally using the > web interface to get a lock, only to respect my lock! :-)) Okay. I'm not sure why the user isn't getting a mid-air. Are you not updating delta_ts? It's theoretically possible for Bugzilla to have conflicting transactions that both go through and both happen after the mid-air check, but the probability is extremely small. Other than that, as long as you're updating delta_ts, there's no way for two changes to happen without mid-airs unless both of them are API clients who aren't respecting the mid-air protection. -Max -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/ From mkanat at bugzilla.org Tue Feb 28 08:09:40 2012 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 28 Feb 2012 00:09:40 -0800 Subject: Locking bugs temporarily? In-Reply-To: References: Message-ID: <4F4C8BC4.4060006@bugzilla.org> On 02/24/2012 06:30 AM, Gervase Markham wrote: > At > the moment, it's possible for me to get a Bug object and, while I am > working out how to change it as part of the sync, for someone else to > update the bug. My changes then overwrite theirs. Ah, I see. That must be an abnormally long time window in order for this to happen any noticeable amount. What amount of time are we talking about, and what's the nature of the plugin that causes it to take that much time to make the updating decision? Should it perhaps re-fetch the bug immediately before issuing an update() to make sure its logic is still sound? -Max -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/ From gerv at mozilla.org Tue Feb 28 12:08:14 2012 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 28 Feb 2012 12:08:14 +0000 Subject: Locking bugs temporarily? In-Reply-To: References:

<4F4B4FAF.8090304@mozilla.org> <4F4B712D.1040402@mozilla.org> Message-ID: <4F4CC3AE.7080808@mozilla.org> On 27/02/12 13:39, Marc Schumann wrote: > In order to avoid a mid-air, you need to lock as soon as changes start > happening on your syncing system. Otherwise, changes might conflict. And if > you say that change might have happened 5 minutes ago, then that's way too > long a time for a lock imho. Sure; I'm only looking at locking things between the time I get a copy of the bug for modification, and the time I write one back - a matter of a second or two. Sync errors of the sort you describe are easier to spot using timestamps. > On a related note, what do you want to happen if two sync users conflict? The updates from the remote system arrive periodically in one big bunch, as a set of "current states", not a set of "deltas"; there are no conflicts among them. (I.e. any problems at the other end have already been sorted out.) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Tue Feb 28 12:12:02 2012 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 28 Feb 2012 12:12:02 +0000 Subject: Locking bugs temporarily? In-Reply-To: References:

Message-ID: <4F4CC492.6010606@mozilla.org> On 28/02/12 08:09, Max Kanat-Alexander wrote: > Ah, I see. That must be an abnormally long time window in order for > this to happen any noticeable amount. What amount of time are we talking > about, and what's the nature of the plugin that causes it to take that > much time to make the updating decision? Should it perhaps re-fetch the > bug immediately before issuing an update() to make sure its logic is > still sound? I could shrink the window still further by implementing some sort of final-delta_ts_check-and-retry-if-its-changed logic, which I may end up doing, but I was wondering if there was a good locking system I could use to shut the window entirely. Given that the window inside Bugzilla isn't _totally_ shut, perhaps I'll go with the above style solution. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From eaolson73 at att.net Wed Feb 29 04:14:36 2012 From: eaolson73 at att.net (Eric Olson) Date: Tue, 28 Feb 2012 20:14:36 -0800 (PST) Subject: Locking bugs temporarily? In-Reply-To: References:

Message-ID: <1330488876.89838.YahooMailNeo@web83804.mail.sp1.yahoo.com> > I don't like hard locks such as what you get with SELECT ... FOR UPDATE > because they're better for database integrity than for mutual exclusion. I'm not sure I get why the application lock is preferred over the SELECT FOR UPDATE lock. It seems to me that method has several disadvantages. Since you're presumably obtaining a lock on the database row anyway (though maybe implicitly when you do an update), why not just use that mechanism? _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla