From gerv at mozilla.org Thu Oct 1 09:30:03 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 01 Oct 2009 10:30:03 +0100 Subject: API Design Questions (5) In-Reply-To: References: Message-ID: On 30/09/09 23:25, Max Kanat-Alexander wrote: > On 09/30/2009 06:28 AM, Gervase Markham wrote: >> https://wiki.mozilla.org/Bugzilla:REST_API:Objects > > Maybe instead of having a separate attachmentdata object, you should > allow people to specify ?include= or ?exclude= to include or exclude > certain fields from every object. I do have a limited include/exclude mechanism, including for attachment data. The attachmentdata object is an object solely because it has two related fields. I guess I could collapse it into the attachment object; maybe that would be simpler. It's only separate now due to a quirk of the XML output. Yes, OK, I'll 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 Thu Oct 1 09:27:13 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 01 Oct 2009 10:27:13 +0100 Subject: API Design Questions (4) In-Reply-To: References: Message-ID: On 30/09/09 11:42, Roman Pszonka wrote: >> { >> blocks: [ "http://bzapi.example.com/bug/23", >> "http://bzapi.example.com/bug/76" ] >> } > > That would allow linking between different databases, right? If you > later decide to support this by bugzilla, there won't be a need to > change API. It would. Exactly how blocks, depends_on and see_also integrate in that world is a... complicated question. But I think you could, without problem, define the fields as either bug number (in which case, it's the current installation) or URL. I don't want to have both, because it's an extra level of indirection. Perhaps I do just want URLs everywhere, and no bug numbers? Hmm... Max, what do you think? Is it RESTfully right for blocks (and depends_on, and other fields which contain bug numbers) to look like the above? 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 Thu Oct 1 09:27:37 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 01 Oct 2009 10:27:37 +0100 Subject: API Design Questions (4) In-Reply-To: References: <4AC281B9.2070301@bugzilla.org> <4AC2F142.3030403@bugzilla.org> Message-ID: On 30/09/09 11:33, Max Kanat-Alexander wrote: > On 09/30/2009 03:16 AM, Gervase Markham wrote: >> 3) Send timestamps with timezone information embedded in ISO 8601 style > > I'd suggest doing this, or include the actual timezone like > "America/Los Angeles" (which avoids the DST problem). ...but is language-specific and horrible to parse. :-| Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From bjb-bugzilla at deus.net Thu Oct 1 11:38:58 2009 From: bjb-bugzilla at deus.net (Ben Bell) Date: Thu, 1 Oct 2009 12:38:58 +0100 Subject: Self Introduction: Ben Bell Message-ID: <20091001113858.GA27240@deus.net> Gosh, isn't this formal! ;) * Full legal name (as you use it is fine) Ben Bell * City, Country; you may use your timezone if you have a compelling London, UK * What do you want to help out with? * Historical qualifications Well I've been a developer, primarily on Unix and Linux, for about fifteen years. Relevant technologies include perl, relational databases and web-based applications. * What do you want to help out with? I have a specific feature request for whines to mailing lists from a client which we want to fold back into the main code base rather than implementing as a one-off hack. I'll send more details in a separate mail with a more appropriate subject. From bjb-bugzilla at deus.net Thu Oct 1 12:16:25 2009 From: bjb-bugzilla at deus.net (Ben Bell) Date: Thu, 1 Oct 2009 13:16:25 +0100 Subject: Whines to Mailing Lists Message-ID: <20091001121625.GB27240@deus.net> I have a client with a feature request for bugzilla. They want to be able to send whine mails to lists as well as just users and groups. I'm new to the bugzilla code base but at a glance it looks like I'll probably want to: 1) define database table(s) for the lists and possible permissioning rules 2) add handling for a MAILTO_LIST type everywhere MAILTO_* is used 3) add support in the front end code for defining and managing mail lists 4) add support to the whines page for mail lists as a type Does this seem a reasonable approach? Is there any other work in progress or completed to support this sort of thing? bjb From mkanat at bugzilla.org Thu Oct 1 12:17:05 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 01 Oct 2009 05:17:05 -0700 Subject: API Design Questions (4) In-Reply-To: References: <4AC281B9.2070301@bugzilla.org> <4AC2F142.3030403@bugzilla.org> Message-ID: <4AC49DC1.1000702@bugzilla.org> On 10/01/2009 02:27 AM, Gervase Markham wrote: > ...but is language-specific and horrible to parse. :-| No, as far as I know that's a language-neutral standard, and is actually the only reliable (retains exact DST values over history including leap seconds, etc.) timezone format in existence. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Oct 1 12:19:23 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 01 Oct 2009 05:19:23 -0700 Subject: Self Introduction: Ben Bell In-Reply-To: <20091001113858.GA27240@deus.net> References: <20091001113858.GA27240@deus.net> Message-ID: <4AC49E4B.4010708@bugzilla.org> On 10/01/2009 04:38 AM, Ben Bell wrote: > Gosh, isn't this formal! ;) Hahaha, quite so, quite so. :-D Welcome to the Bugzilla Project! :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Oct 1 12:19:58 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 01 Oct 2009 05:19:58 -0700 Subject: Whines to Mailing Lists In-Reply-To: <20091001121625.GB27240@deus.net> References: <20091001121625.GB27240@deus.net> Message-ID: <4AC49E6E.8050000@bugzilla.org> On 10/01/2009 05:16 AM, Ben Bell wrote: > I have a client with a feature request for bugzilla. They want to be > able to send whine mails to lists as well as just users and groups. How does a list differ from a group? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Oct 1 12:21:02 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 01 Oct 2009 05:21:02 -0700 Subject: API Design Questions (4) In-Reply-To: References: Message-ID: <4AC49EAE.7030408@bugzilla.org> On 10/01/2009 02:27 AM, Gervase Markham wrote: > Max, what do you think? Is it RESTfully right for blocks (and > depends_on, and other fields which contain bug numbers) to look like the > above? No, I think see_also will be our only inter-Bugzilla field, so it would be best to stick just to numbers (which are far simpler to parse) for the other fields. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From bjb-bugzilla at deus.net Thu Oct 1 12:24:28 2009 From: bjb-bugzilla at deus.net (Ben Bell) Date: Thu, 1 Oct 2009 13:24:28 +0100 Subject: Whines to Mailing Lists In-Reply-To: <4AC49E6E.8050000@bugzilla.org> References: <20091001121625.GB27240@deus.net> <4AC49E6E.8050000@bugzilla.org> Message-ID: <20091001122428.GC27240@deus.net> On Thu, Oct 01, 2009 at 05:19:58AM -0700, Max Kanat-Alexander wrote: > On 10/01/2009 05:16 AM, Ben Bell wrote: > > I have a client with a feature request for bugzilla. They want to be > > able to send whine mails to lists as well as just users and groups. > > How does a list differ from a group? As far as I can tell from my brief perusal, groups are collections of bugzilla users with no email address of their own. What we effectively want is to be able to send mails to external email addresses other than those belonging to individual bugzilla users. bjb From Nick.Barnes at pobox.com Thu Oct 1 12:30:07 2009 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Thu, 01 Oct 2009 13:30:07 +0100 Subject: Whines to Mailing Lists In-Reply-To: <20091001122428.GC27240@deus.net> from Ben Bell of "Thu, 01 Oct 2009 13:24:28 +0100" Message-ID: <34499.1254400207@thrush.ravenbrook.com> At 2009-10-01 12:24:28+0000, Ben Bell writes: > On Thu, Oct 01, 2009 at 05:19:58AM -0700, Max Kanat-Alexander wrote: > > On 10/01/2009 05:16 AM, Ben Bell wrote: > > > I have a client with a feature request for bugzilla. They want to be > > > able to send whine mails to lists as well as just users and groups. > > > > How does a list differ from a group? > > As far as I can tell from my brief perusal, groups are collections of > bugzilla users with no email address of their own. What we effectively > want is to be able to send mails to external email addresses other than > those belonging to individual bugzilla users. Add them as disabled users? Nick B From bjb-bugzilla at deus.net Thu Oct 1 13:03:29 2009 From: bjb-bugzilla at deus.net (Ben Bell) Date: Thu, 1 Oct 2009 14:03:29 +0100 Subject: Whines to Mailing Lists In-Reply-To: <34499.1254400207@thrush.ravenbrook.com> References: <20091001122428.GC27240@deus.net> <34499.1254400207@thrush.ravenbrook.com> Message-ID: <20091001130329.GD27240@deus.net> On Thu, Oct 01, 2009 at 01:30:07PM +0100, Nick Barnes wrote: > > As far as I can tell from my brief perusal, groups are collections of > > bugzilla users with no email address of their own. What we effectively > > want is to be able to send mails to external email addresses other than > > those belonging to individual bugzilla users. > Add them as disabled users? We could do something like that but it's a bit of a hack and we'd prefer a cleaner solution. So it sounds like there probably isn't a facility I've missed (excepting suggestions like the above) to handle this. I'll be doing the work to put this into their 3.0.x series deployment anyway, and if the feature's considered useful rather than unnecessary bloat I'm happy to port it forward to the current version too. From mkanat at bugzilla.org Thu Oct 1 13:36:23 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 01 Oct 2009 06:36:23 -0700 Subject: Whines to Mailing Lists In-Reply-To: <20091001122428.GC27240@deus.net> References: <20091001121625.GB27240@deus.net> <4AC49E6E.8050000@bugzilla.org> <20091001122428.GC27240@deus.net> Message-ID: <4AC4B057.3060009@bugzilla.org> On 10/01/2009 05:24 AM, Ben Bell wrote: > What we effectively > want is to be able to send mails to external email addresses other than > those belonging to individual bugzilla users. Okay. So basically this is just the ability to send whines to email addresses without a Bugzilla account. Depending on how invasive it is, it's possible we'd be interested in having it upstream. (If it's very invasive or adds too much complexity, the complexity would overwhelm the benefit of including it in Bugzilla itself.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From ghendricks at novell.com Thu Oct 1 21:48:43 2009 From: ghendricks at novell.com (Gregary Hendricks) Date: Thu, 01 Oct 2009 15:48:43 -0600 Subject: Whines to Mailing Lists In-Reply-To: <4AC4B057.3060009@bugzilla.org> References: <20091001121625.GB27240@deus.net> <4AC49E6E.8050000@bugzilla.org> <20091001122428.GC27240@deus.net> <4AC4B057.3060009@bugzilla.org> Message-ID: <4AC4CF5B020000D200057EB1@novprvlin0050.provo.novell.com> >>> On 10/1/2009 at 07:36 AM, in message <4AC4B057.3060009 at bugzilla.org>, Max Kanat-Alexander wrote: > On 10/01/2009 05:24 AM, Ben Bell wrote: > > What we effectively > > want is to be able to send mails to external email addresses other than > > those belonging to individual bugzilla users. > > Okay. So basically this is just the ability to send whines to email > addresses without a Bugzilla account. Depending on how invasive it is, > it's possible we'd be interested in having it upstream. (If it's very > invasive or adds too much complexity, the complexity would overwhelm the > benefit of including it in Bugzilla itself.) Why not just create an account with the list email address as the email address? We do this all the time. Fake user with foo-list at lists.mycompany.com as the email. Then we can assign bugs, set in CC or QA to our hearts content and everyone gets the bug mail. Greg From dmarshal at yahoo-inc.com Thu Oct 1 22:12:41 2009 From: dmarshal at yahoo-inc.com (David Marshall) Date: Thu, 01 Oct 2009 15:12:41 -0700 Subject: Whines to Mailing Lists In-Reply-To: <4AC4CF5B020000D200057EB1@novprvlin0050.provo.novell.com> Message-ID: On 10/1/09 2:48 PM, "Gregary Hendricks" wrote: >>>> On 10/1/2009 at 07:36 AM, in message <4AC4B057.3060009 at bugzilla.org>, Max > Kanat-Alexander wrote: >> On 10/01/2009 05:24 AM, Ben Bell wrote: >>> What we effectively >>> want is to be able to send mails to external email addresses other than >>> those belonging to individual bugzilla users. >> >> Okay. So basically this is just the ability to send whines to email >> addresses without a Bugzilla account. Depending on how invasive it is, >> it's possible we'd be interested in having it upstream. (If it's very >> invasive or adds too much complexity, the complexity would overwhelm the >> benefit of including it in Bugzilla itself.) > > Why not just create an account with the list email address as the email > address? > We do this all the time. Fake user with foo-list at lists.mycompany.com as the > email. Then we can assign bugs, set in CC or QA to our hearts content and > everyone gets the bug mail. We do much the same at Yahoo! However, that's a little bit different from having whines for that user. Some of our users have expressed a desire to send whines to another user that happens to be a mailing list. We usually demur, saying that we don't allow users to create whines for other users. It's really rather trivial to redirect email that you get to whomever you like. We advise those interested in the capability to set up whines for themselves and filter/forward them as needed. There's a lot of information in the mail headers. How would you know that the external email address really does want mail from Bugzilla? Doesn't this just make it really easy to turn Bugzilla into a spam machine? Dealing with email capabilities is so annoying that I believe Bugzilla should be doing less with email rather than adding new email-related capabilities. When you can get the results of a search by RSS, doesn't that lower the value of the whine capability? If we absolutely must have this, perhaps it should be a list view that corresponds to the email that whine presents, so that I can perform a search and send off the results as I choose. In my crontab: */15 * * * * curl http://bugzilla.foo.com/buglist.cgi?cmdtype=runnamed&namedcmd=important&ctyp e=whine | mail my-mailing-list at foo.com From gerv at mozilla.org Fri Oct 2 20:01:47 2009 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 02 Oct 2009 21:01:47 +0100 Subject: API Design Questions (4) In-Reply-To: References: Message-ID: On 01/10/09 13:21, Max Kanat-Alexander wrote: > No, I think see_also will be our only inter-Bugzilla field, so it would > be best to stick just to numbers (which are far simpler to parse) for > the other fields. In which case, I need to talk to you about a better design idea I have for this whole area :-) But this can wait :-)) 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 Oct 2 20:00:46 2009 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 02 Oct 2009 21:00:46 +0100 Subject: Bugzilla API 0.1 released Message-ID: Hi everyone, I've just released API version 0.1. See the announcement: http://weblogs.mozillazine.org/gerv/archives/2009/10/bugzilla_http_restful_api_01_released.html and the comprehensive documentation: https://wiki.mozilla.org/Bugzilla:REST_API https://wiki.mozilla.org/Bugzilla:REST_API:Objects https://wiki.mozilla.org/Bugzilla:REST_API:Search You can even play with the API using a web browser and you'll get results as HTML-ified YAML. https://api-dev.bugzilla.mozilla.org/0.1/bug/35 https://api-dev.bugzilla.mozilla.org/0.1/bug?product=Bugzilla&severity=blocker It's only a 0.1, and I'm hoping that the form and structure of this API will be acceptable to the Bugzilla community for later implementation on top of the core. So if you see stuff you don't like, shout! :-) 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 Oct 2 20:04:25 2009 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 02 Oct 2009 21:04:25 +0100 Subject: API Design Questions (4) In-Reply-To: References: <4AC281B9.2070301@bugzilla.org> <4AC2F142.3030403@bugzilla.org> Message-ID: On 01/10/09 13:17, Max Kanat-Alexander wrote: > No, as far as I know that's a language-neutral standard, and is > actually the only reliable (retains exact DST values over history > including leap seconds, etc.) timezone format in existence. Although it requires a lot of external knowledge to parse correctly. What time was it UTC on 2005-10-30 01:50 America/Los Angeles? You need to know that the DST rules were different for the US back then, and the date of change was different, and that they change at 2am, etc. etc. Gerv _______________________________________________ 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 Fri Oct 2 23:28:54 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 02 Oct 2009 16:28:54 -0700 Subject: API Design Questions (4) In-Reply-To: References: <4AC281B9.2070301@bugzilla.org> <4AC2F142.3030403@bugzilla.org> Message-ID: <4AC68CB6.8060300@bugzilla.org> On 10/02/2009 01:04 PM, Gervase Markham wrote: > Although it requires a lot of external knowledge to parse correctly. > > What time was it UTC on 2005-10-30 01:50 America/Los Angeles? > > You need to know that the DST rules were different for the US back then, > and the date of change was different, and that they change at 2am, etc. > etc. In Perl, DateTime.pm does this for you. I suspect there are similar modules available for other languages. Technically all of this info is available in the zoneinfo database, also. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Fri Oct 2 23:36:17 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 02 Oct 2009 16:36:17 -0700 Subject: API Design Questions (4) In-Reply-To: <4AC68CB6.8060300@bugzilla.org> References: <4AC281B9.2070301@bugzilla.org> <4AC2F142.3030403@bugzilla.org> <4AC68CB6.8060300@bugzilla.org> Message-ID: <4AC68E71.4090802@bugzilla.org> On 10/02/2009 04:28 PM, Max Kanat-Alexander wrote: >> What time was it UTC on 2005-10-30 01:50 America/Los Angeles? >> >> You need to know that the DST rules were different for the US back then, >> and the date of change was different, and that they change at 2am, etc. >> etc. > > In Perl, DateTime.pm does this for you. I suspect there are similar > modules available for other languages. Technically all of this info is > available in the zoneinfo database, also. By the way, you need to know this information anyway in order to correctly parse/convert *any* date/time. The Olsen timezone format just makes it possible to actually do so. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From bjb-bugzilla at deus.net Tue Oct 6 15:42:23 2009 From: bjb-bugzilla at deus.net (Ben Bell) Date: Tue, 6 Oct 2009 16:42:23 +0100 Subject: Whines to Mailing Lists In-Reply-To: References: <4AC4CF5B020000D200057EB1@novprvlin0050.provo.novell.com> Message-ID: <20091006154223.GJ13145@deus.net> On Thu, Oct 01, 2009 at 03:12:41PM -0700, David Marshall wrote: > How would you know that the external email address really does want mail > from Bugzilla? Doesn't this just make it really easy to turn Bugzilla into > a spam machine? I don't really see that moving the facility from a faked up user to its own entity makes much difference here, assuming the same controls on who can set things up exist. > When you can get the results of a search by RSS, doesn't that > lower the value of the whine capability? If your users use RSS, perhaps. > In my crontab: Again, if the administrators of the bugzilla system are happy to maintain crontabs, that works. But those things don't match the client's requirements in my case :) I'm working against 3.0.4 so when the code's done I'll post the patch and if the bugzilla devs like it, I'll port it to head. If not, no harm done -- the client gets their functionality either way. From gerv at mozilla.org Thu Oct 22 16:25:12 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 22 Oct 2009 17:25:12 +0100 Subject: Ever-present fields Message-ID: In the past, people have suggested that most fields in the Bug object returned by the HTTP API should be always present. The idea is that it's easier for an API user to just check for a value without having to check for existence first. That would mean adding the following fields with the following default values to every downloaded Bug object: "attachments" => [], "blocks" => [], "cc" => [], "depends_on" => [], "flags" => [], "groups" => [], "is_cc_accessible" => "0", "is_reporter_accessible" => "0", "keywords" => [], "resolution" => "", "url" => "", (This would, of course, increase the size of every object.) However, in the case of the following fields, which are configurable on/off in Bugzilla preferences, the API user would still have to check for existence before checking a value. qa_contact classification target_milestone whiteboard alias see_also actual_time work_time deadline estimated_time remaining_time My suggestion is that the split between these two groups would seem to most Bugzilla users like an artificial distinction. Given that in the future, we might make more of the default fields optional or configurable, it seems wrong to hard-code a list of which fields are always present in the returned structure. So my current plan is to only supply fields which have a value. This keeps data size down and avoids hardcoding "special" lists of fields. Let me know if you think this reasoning is wrong. Gerv _______________________________________________ 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 Sat Oct 24 05:42:58 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Oct 2009 22:42:58 -0700 Subject: The Bugzilla Migration Framework Message-ID: <4AE293E2.2020604@bugzilla.org> I just checked in migrate.pl, a framework for migrating from other bug-tracking systems to Bugzilla. The exciting news is that this makes it very easy to write new migrators to migrate from any bug-tracking system to Bugzilla. Also, this makes migration a first-class part of Bugzilla, not part of contrib/. This means that we will maintain the migration framework, and the migrators themselves, and if they break, that's a regression. The first system implemented is GNATS, because (a) a client hired me to write a modern Bugzilla->GNATS migrator (which was actually the whole reason I wrote this framework) and (b) GNATS is dead (as far as I know) and so we won't have to change anything about the migrator in the future. The GNATS migrator is Bugzilla::Migrate::GNATS, if you want to see a sample of a migrator. The migration framework has the following features: 1) It is non-destructive. You can migrate into an existing Bugzilla installation! 2) It uses Bugzilla::Object stuff to create products, components, bugs, users, and attachments, so it will continue to work into the future, and automatically validates all data as it is inserted. 3) All of the inserting of data is handled by Bugzilla::Migrate, so your migration code doesn't have to do that. 4) It's relatively easy to implement new migrators for systems. Basically all you have to do is provide arrays of hashes describing the products, users, and bugs in your bug-tracker, and Bugzilla::Migrate does the rest of the work. It even contains a facility to translate values from the old bug-tracker to Bugzilla, and allows the end user to specify how that translation should work. 5) It is capable of doing a "dry-run" of your migration, so that you can see if everything is going to go well before actually committing anything to the database. 6) Bugzilla::Migtate prints output, handles configuration of your migrator--basically, it really does *everything* except for reading the data from your bug-tracker. So now, I'd really love to see some new migrators! The bug-trackers that I'd most like to see new migrators for are: JIRA Trac Mantis And any other bug-tracker that you want to write a migrator for will be welcome! The review requirements on migrators are slightly relaxed--I will believe you when you say that it works, as long as it's coded well and follows the Bugzilla Developers' Guide. Also, if anybody who wants to provide me (or the Bugzilla project in general) a dump of a large working installation of a bug-tracker, that will help people who want to write a migrator. Happy migrating! :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From justdave at bugzilla.org Sat Oct 24 07:42:27 2009 From: justdave at bugzilla.org (David Miller) Date: Sat, 24 Oct 2009 03:42:27 -0400 Subject: The Bugzilla Migration Framework In-Reply-To: <4AE293E2.2020604@bugzilla.org> References: <4AE293E2.2020604@bugzilla.org> Message-ID: <4AE2AFE3.8010005@bugzilla.org> Max Kanat-Alexander wrote on 10/24/09 1:42 AM: > I just checked in migrate.pl, a framework for migrating from other > bug-tracking systems to Bugzilla. This is *huge*. :) You should write up a version of this post targeted at integrators and consultants and send it to the announce list, might get some good traction on it. Should we make any kind of rule about not breaking import from an older version of something in order to make an import from a newer version work? I'm pretty sure the gnats2bz script in contrib got updated for a newer version of gnats at one point and it got wholesale replaced with the code for the new version instead of checking to see which schema it needed to work with. On the other hand, if it always works with the latest version I suppose we could tell people they need to ugprade whatever they're migrating from to the latest first. But then again, sometimes that costs money you wouldn't want to spend if you're moving away from that product anyway... -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From webbdeaf at hotmail.com Tue Oct 27 13:36:46 2009 From: webbdeaf at hotmail.com (sverker lindblom) Date: Tue, 27 Oct 2009 06:36:46 -0700 (PDT) Subject: Hello Message-ID: Jag ?r d?v ,, jag kan inte proffs sv?rt data nu ... jag tycker sv?rt proffs inte mig ... _______________________________________________ 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 Oct 27 18:10:05 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 27 Oct 2009 19:10:05 +0100 Subject: Bugzilla meeting now on IRC!! Join us! Message-ID: <4AE7377D.8050104@gmail.com> IRC channel: #bugzilla-meeting From itamar at ispbrasil.com.br Tue Oct 27 18:11:48 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Tue, 27 Oct 2009 16:11:48 -0200 Subject: Bugzilla meeting now on IRC!! Join us! In-Reply-To: <4AE7377D.8050104@gmail.com> References: <4AE7377D.8050104@gmail.com> Message-ID: what irc-server ? 2009/10/27 Fr?d?ric Buclin : > IRC channel: #bugzilla-meeting > - > To view or change your list settings, click here: > > -- ------------ Itamar Reis Peixoto e-mail/msn/google talk/sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From gerv at mozilla.org Mon Oct 26 10:22:44 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Oct 2009 10:22:44 +0000 Subject: The Bugzilla Migration Framework In-Reply-To: References: Message-ID: On 24/10/09 06:42, Max Kanat-Alexander wrote: > I just checked in migrate.pl, a framework for migrating from other > bug-tracking systems to Bugzilla. Cool :-) > Also, this makes migration a first-class part of Bugzilla, not part of > contrib/. This means that we will maintain the migration framework, and > the migrators themselves, and if they break, that's a regression. Do we then have an install of GNATS on Landfill that we are planning to use to test the migrator with? > 1) It is non-destructive. You can migrate into an existing Bugzilla > installation! An obvious consequence of this is that someone could write a Bugzilla migrator, and you could use it to merge Bugzilla installations. > 5) It is capable of doing a "dry-run" of your migration, so that you > can see if everything is going to go well before actually committing > anything to the database. That's particularly brilliant. Gerv _______________________________________________ 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 Mon Oct 26 01:52:08 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 25 Oct 2009 18:52:08 -0700 Subject: Bugzilla 3.6 Soft Freeze Date Change Message-ID: <4AE500C8.5030901@bugzilla.org> Obviously, we didn't freeze for Bugzilla 3.6 in September. The new freeze date is November 24, 2009. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Sat Oct 24 05:45:27 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Oct 2009 22:45:27 -0700 Subject: The Bugzilla Migration Framework In-Reply-To: <4AE293E2.2020604@bugzilla.org> References: <4AE293E2.2020604@bugzilla.org> Message-ID: <4AE29477.8080409@bugzilla.org> On 10/23/2009 10:42 PM, Max Kanat-Alexander wrote: > (a) a client hired me to > write a modern Bugzilla->GNATS migrator (which was actually the whole > reason I wrote this framework) Hahaha, that of course should read: "a modern GNATS->Bugzilla migrator" > The GNATS migrator is Bugzilla::Migrate::GNATS, if you want to see a > sample of a migrator. Oh, and that should be "Bugzilla::Migrate::Gnats". -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Fri Oct 23 01:48:46 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 22 Oct 2009 18:48:46 -0700 Subject: Ever-present fields In-Reply-To: References: Message-ID: <4AE10B7E.8060606@bugzilla.org> On 10/22/2009 09:25 AM, Gervase Markham wrote: > However, in > the case of the following fields, which are configurable on/off in > Bugzilla preferences, the API user would still have to check for > existence before checking a value. Oh, actually, my current goal is to have parameters only control the UI. They should only affect the backend when there is a really good reason. So, for example, qa_contact would *always* be returned by the WebService, even if it's disabled. This allows clients to have a totally consistent API no matter how the administrator has configured the system's parameters. It also greatly simplifies our implementation of parameters (it generally limits them to controlling only templates). > So my current plan is to only supply fields which have a value. This > keeps data size down and avoids hardcoding "special" lists of fields. > Let me know if you think this reasoning is wrong. Given the current direction of Bugzilla itself, I'd suggest that it would be better to just always return the value of every field. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Tue Oct 20 18:23:49 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 20 Oct 2009 20:23:49 +0200 Subject: Bugzilla meeting on Tuesday, October 27 at 11:00 PDT (18:00 GMT, 19:00 CET) Message-ID: <4ADE0035.1000005@gmail.com> Hello all, Our next Bugzilla meeting will take place next Tuesday, October 27 at 11:00 PDT (18:00 GMT, 19:00 CET) on IRC in the #bugzilla-meeting channel. As usual, everyone is free to attend. Please note that Europe stops using summertime this coming week-end, October 25, while USA keeps it one more week, so Europeans must join the meeting one hour earlier (19:00 CET instead of 20:00 CEST). I'm sure we will have fun due to that. :) The agenda is at https://wiki.mozilla.org/Bugzilla:Meetings. Feel free to add new items to it. See you next Tuesday, LpSolit From reed at reedloden.com Mon Oct 19 16:50:25 2009 From: reed at reedloden.com (Reed Loden) Date: Mon, 19 Oct 2009 11:50:25 -0500 Subject: API: Group write support In-Reply-To: References: Message-ID: <20091019115025.aa532bf7.reed@reedloden.com> On Wed, 14 Oct 2009 09:41:59 +0100 Gervase Markham wrote: > 3) Switch the XML to also produce group IDs; change the representation > of a group on the API from a single string to a "Group" object > containing name, ID and possibly description, with the ID being > canonical. This is an increase in interface complexity. https://bugzilla.mozilla.org/show_bug.cgi?id=378681 ~reed -- Reed Loden - _______________________________________________ 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 Oct 19 16:24:33 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 19 Oct 2009 17:24:33 +0100 Subject: Getting more data from inside a template Message-ID: Hi guys, In a template, can I "break out" and start instantiating Bugzilla::Foo objects, or am I limited to what the controlling .cgi chooses to pass me? (I know EVAL_PERL isn't set in Bugzilla, so that route won't work.) (I want to call Bugzilla::Status->get_all to get information on status transitions that config.cgi isn't giving me.) Thanks, 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 Thu Oct 15 15:53:47 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 15 Oct 2009 16:53:47 +0100 Subject: Configuration object Message-ID: Me again :-) I've done a design for the object that the /config call will return, which should tell you enough about Bugzilla's configuration to write a good client. https://wiki.mozilla.org/Bugzilla:REST_API:Objects:Configuration This is quite complicated, and I may have got some stuff wrong. So please let me know if you think the design is a good one. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From bjb-bugzilla at deus.net Wed Oct 14 15:27:09 2009 From: bjb-bugzilla at deus.net (Ben Bell) Date: Wed, 14 Oct 2009 16:27:09 +0100 Subject: Whines to Mailing Lists In-Reply-To: <4AC4B057.3060009@bugzilla.org> References: <20091001121625.GB27240@deus.net> <4AC49E6E.8050000@bugzilla.org> <20091001122428.GC27240@deus.net> <4AC4B057.3060009@bugzilla.org> Message-ID: <20091014152709.GA27710@deus.net> On Thu, Oct 01, 2009 at 06:36:23AM -0700, Max Kanat-Alexander wrote: > Depending on how invasive it is, it's possible we'd be interested in > having it upstream. FYI, I've attached the patch to newly create issue #522258. It was developed against 3.0.4 and ported forward. I'm hoping to have a chance to look into the proper process (test results and the like) but as there was doubt as to its usefulness, before I expend any more effort on I wanted to get it out there and visible. bjb -- +-----Ben Bell - "A song, a perl script and the occasional silly sig.-----+ /// email: bjb at deus.net www: http://www.deus.net/~bjb/ bjb Don't try to drive me crazy... \_/ ...I'm close enough to walk. From gerv at mozilla.org Wed Oct 14 08:41:59 2009 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 14 Oct 2009 09:41:59 +0100 Subject: API: Group write support Message-ID: I have a problem with the API implementation that I hope you can help me with :-) It relates to supporting groups - specifically, changing the groups on a bug. (The API already supports reading group names.) The issue is that group names are confidential to those who cannot see those groups. Therefore, the URL interface on process_bug.cgi for changing groups involves the group IDs rather than the group names. However, the XML bug representation returns only group names rather than IDs. Therefore, as things are now, if an API user attempts to change the groups of a bug, they would be sending back a list of group names. However, the API software cannot translate these into group IDs without knowledge of that mapping, which it doesn't currently have. This information is available in the RDF output of config.cgi. So it looks like one has to do one of the following: 1) Make, and cache the results of, a request to config.cgi for each API user (login), and use that information to convert names into numbers. This would decrease performance and increase memory requirements. 2) Have the API configuration give a superuser username and password for the Bugzilla. Make a single request for config.cgi using that username and password, and expect it to contain all groups. Use this for all conversions. This should be safe, as you are converting from names to numbers only, not the other way. Bugzilla will reject the setting of groups the user isn't allowed to set anyway. This requires the API machine to have privileged access to Bugzilla, which is unfortunate. 3) Switch the XML to also produce group IDs; change the representation of a group on the API from a single string to a "Group" object containing name, ID and possibly description, with the ID being canonical. This is an increase in interface complexity. I'm leaning towards 3). What do you guys think? 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 Oct 13 16:14:44 2009 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 13 Oct 2009 17:14:44 +0100 Subject: The timezone problem Message-ID: So I'm looking at trying to solve (as best I can) the timezone problem for my API. I acquire time information from basically two places - the legacy XML interface, and the XML-RPC interface. Times that I get from the legacy XML interface come with timezone information already, of the +0100 form - although this isn't stored in the timestamp itself, but is external. So when I ship a database between timezones, all the times change :-/ Which is annoying for automated tests which check values of things. Still, for normal databases which aren't weird like mine, I could add or subtract that timezone from the time itself to get the time in UTC. Right? Then, there remain the times from the XML-RPC interface. If: 1) the API proxy knew (in its config or by asking Bugzilla) the timezone and DST rules (as in e.g. "America/Los Angeles") the Bugzilla server was in, and 2) if the account using the API hadn't messed with the new "set my timezone" pref in 3.4, then: => the API could take the times that come back from Bugzilla and, using its knowledge of what zone they are actually in, convert them to UTC. Would that work? Or have I missed something? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla