From kirubakaran1989 at gmail.com Wed Nov 4 16:53:39 2009 From: kirubakaran1989 at gmail.com (kirubakaran S) Date: Wed, 4 Nov 2009 11:53:39 -0500 Subject: self introduction - Kirubakaran Message-ID: <103659030911040853i1b75a487l21423ede31ac89c1@mail.gmail.com> Hello developers, Name : Kirubakaran.S Chennai , India College of Engineering Guindy, Anna university I would like to help in developing patches and fixing bugs. I am a newcomer ( since I m pursuing my undergraduate studies), Amazingly this is my first open source initiative and I am sure I will definitely learn a lot and contribute towards Bugzilla. I am quite comfortable with PHP, java. I m in learning mode of CGI/PERL Other skills can be like managing projects, fixing time line and interacting with developers.I am a quick learner. since I am a new comer, I am confused where to start?. Right now I am learning tons of code in API documentation. Can anyone pls guide me how to be comfortable with bugzilla? Thank you Happy developing "Bugzilla" :) -- Kirubakaran.S Anna university, Chennai -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Mon Nov 9 19:44:32 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 09 Nov 2009 11:44:32 -0800 Subject: Bugzilla->input_params Message-ID: <4AF87120.2090502@bugzilla.org> There is a new way to get CGI paramters under some circumstances, on HEAD, Bugzilla->input_params: http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla.html#input_params Generally, for now you should continue using Bugzilla->cgi to get parameters, but input_params should be used if you have to get CGI parameters inside of modules (with careful thought about how that will work in the WebService). -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Tue Nov 10 01:43:33 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 09 Nov 2009 17:43:33 -0800 Subject: Bugzilla::Comment, $bug->longdescs becomes $bug->comments Message-ID: <4AF8C545.6020903@bugzilla.org> I just checked in a Bugzilla::Comment object--thanks to James Robson for the first nine revisions of the patch (which was most or much of work, really). Bugzilla::Bug::GetComments no longer exists. $bug->longdescs has become $bug->comments, and it can limit its return value by date, and sort its return value in various ways. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From justdave at bugzilla.org Wed Nov 11 04:34:14 2009 From: justdave at bugzilla.org (David Miller) Date: Tue, 10 Nov 2009 23:34:14 -0500 Subject: Proliferation of custom fields Message-ID: <4AFA3EC6.40405@bugzilla.org> So, it shouldn't be any surprise that custom fields actually get used now that they're available. We're starting to add quite a few of them for specific purposes at Mozilla. When you add a custom field that isn't a multi-select or a map, (just a string or a date for example) it gets added as a column to the bugs table. I've got a little voice in the back of my head telling me that's going to hurt eventually if we keep adding fields. Is my little voice correct, or have I nothing to worry about? Is there a better way to architect it in the long run that won't cause as much damage? Maybe a second table for bugs_custom that is only joined once by bug_id and is otherwise just custom fields for bugs? That only buys you so much time, too, but potentially less stress on things that look at bugs and don't touch custom fields... -- 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 gerv at mozilla.org Mon Nov 9 10:59:12 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 09 Nov 2009 10:59:12 +0000 Subject: self introduction - Kirubakaran In-Reply-To: <98736b43-dbb3-45d1-b90b-8c69f67798a1@g7g2000vbi.googlegroups.com> References: <98736b43-dbb3-45d1-b90b-8c69f67798a1@g7g2000vbi.googlegroups.com> Message-ID: On 04/11/09 16:59, kirubakaran wrote: > since I am a new comer, I am confused where to start?. Right now I > am learning > tons of code in API documentation. Can anyone pls guide me how to be > comfortable > with bugzilla? Max or anyone, are you able to suggest a "good first bug" for Kirubakaran? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From krzysdrewniak at gmail.com Sat Nov 7 03:04:19 2009 From: krzysdrewniak at gmail.com (Krzysztof Drewniak) Date: Fri, 06 Nov 2009 21:04:19 -0600 Subject: Self introduction: Krzysztof Drewniak Message-ID: <1257563059.23813.81.camel@krzys-desktop.home> Hi. My name is Krzysztof Drewniak. I don't currently have a nick on irc.mozilla.org. I live in (Dallas area), Texas, United States. I know Perl to the point of getting by. I can probably pick up some intermediate SQL if I ever need to work with it. I know simple HTML (the template files' HTML seems understandable enough (for me)). I am bot familiar with Template, but the Template documentation will most likely be self-explanatory. I have not worked on any FOSS projects before, but this seemed like a good place to start my development experience. I haven't figured out what I will be working on, but I plan to fix bug #369080 for starters. P.S. Where's the message sending code? P.P.S. Is ; a legal email address character (Google didn't help much). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lpsolit at gmail.com Fri Nov 6 14:09:51 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 06 Nov 2009 15:09:51 +0100 Subject: Minutes of our last Bugzilla meeting Message-ID: <4AF42E2F.2010407@gmail.com> For those who couldn't attend last week, here is a brief summary of what we discussed at our last Bugzilla meeting: https://wiki.mozilla.org/Bugzilla:Meetings:2009-10-27 The other minutes are available here: https://wiki.mozilla.org/Bugzilla:Meetings LpSolit From mkanat at bugzilla.org Thu Nov 5 16:42:44 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 05 Nov 2009 08:42:44 -0800 Subject: The Bugzilla Migration Framework In-Reply-To: <4AE2AFE3.8010005@bugzilla.org> References: <4AE293E2.2020604@bugzilla.org> <4AE2AFE3.8010005@bugzilla.org> Message-ID: <4AF30084.7040900@bugzilla.org> On 10/24/2009 12:42 AM, David Miller wrote: > 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. I did this today, basically, as part of the latest Bugzilla Update: http://bugzillaupdate.wordpress.com/2009/11/05/release-3-4-3/ By the way, I highly encourage anybody who reads this list to also subscribe to the Bugzilla Update--it's a good concise summary of what's been going on with the Bugzilla Project, and I hope to update it more often than we release--that is, on a somewhat regular schedule. > 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... I think the thing to do for now is to play it by ear. If there's a situation that's going to break import from an old version, but the version is like 10 years old, then I think it's less important than if we're breaking import from the latest stable version in order to get compatibility with a development version. (Those would be the two extremes.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From rahul at mapmyindia.com Thu Nov 5 04:36:03 2009 From: rahul at mapmyindia.com (rahul at mapmyindia.com) Date: Thu, 05 Nov 2009 10:06:03 +0530 Subject: self introduction - Kirubakaran In-Reply-To: <103659030911040853i1b75a487l21423ede31ac89c1@mail.gmail.com> References: <103659030911040853i1b75a487l21423ede31ac89c1@mail.gmail.com> Message-ID: <20091105100603.yde9tv6ggss4o8s0@mail.mapmyindia.com> Hello there; BUGZILLA has perl modules in it...it does not have some piece of coding in perl involved...however knowing perl might help you in customizing bugzilla . Bugzilla is error tracking tool. if you need to get a feel of it......u should go to bugzilla.org and click on the link of sample bugzilla running to work on it and see how to work on bugzilla.and in case you want to install bugzilla you will have to search google for bugzilla installation on your system(this is what i did). The installation is pretty simple and u will just have basic computer knowledge to work around it. Thanking you Rahul Pandia Quoting kirubakaran S : > Hello developers, > > Name? : Kirubakaran.S > Chennai , India > College of Engineering Guindy, Anna university > > ? ?I would like to help in developing patches and fixing bugs. > > ? ?I am a newcomer ( since I m pursuing my undergraduate studies), Amazingly > this > ? ?is my first open source initiative and I am sure I will definitely learn > ? ?a lot and contribute towards Bugzilla. > > ? ?I am quite comfortable with PHP, java. I m in learning mode of CGI/PERL > > ? ?Other skills can be like managing projects, fixing time line and > interacting with > ? ?developers.I am a quick learner. > > ? ? since I am a new comer, I am confused where to start?. Right now I am > learning > ? ?tons of code in API documentation. Can anyone pls guide me how to be > comfortable > ? ?with bugzilla? > > ? ?Thank you > ? ?Happy developing "Bugzilla" :) > > -- > Kirubakaran.S > Anna university, > Chennai > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Thu Nov 5 03:27:22 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 04 Nov 2009 19:27:22 -0800 Subject: self introduction - Kirubakaran In-Reply-To: <103659030911040853i1b75a487l21423ede31ac89c1@mail.gmail.com> References: <103659030911040853i1b75a487l21423ede31ac89c1@mail.gmail.com> Message-ID: <4AF2461A.8080403@bugzilla.org> On 11/04/2009 08:53 AM, kirubakaran S wrote: > I would like to help in developing patches and fixing bugs. > > I am a newcomer ( since I m pursuing my undergraduate studies), > Amazingly this > is my first open source initiative and I am sure I will definitely learn > a lot and contribute towards Bugzilla. Great, welcome! :-) > since I am a new comer, I am confused where to start?. Right now I am > learning > tons of code in API documentation. Can anyone pls guide me how to be > comfortable > with bugzilla? Probably the best thing to do is to look through the list of "Intro Bugs" and just try to fix one. That will get you experience reading and writing Bugzilla's code. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From kirubakaran1989 at gmail.com Wed Nov 4 16:59:29 2009 From: kirubakaran1989 at gmail.com (kirubakaran) Date: Wed, 4 Nov 2009 08:59:29 -0800 (PST) Subject: self introduction - Kirubakaran Message-ID: <98736b43-dbb3-45d1-b90b-8c69f67798a1@g7g2000vbi.googlegroups.com> Name : Kirubakaran.S Chennai , India College of Engineering Guindy, Anna university I would like to help in developing patches and fixing bugs. I am a newcomer ( since I m pursuing my undergraduate studies), Amazingly this is my first open source initiative and I am sure I will definitely learn a lot and contribute towards Bugzilla. I am quite comfortable with PHP, java. I m in learning mode of CGI/ PERL Other skills can be like managing projects, fixing time line and interacting with developers.I am a quick learner. since I am a new comer, I am confused where to start?. Right now I am learning tons of code in API documentation. Can anyone pls guide me how to be comfortable with bugzilla? Thank you Happy developing "Bugzilla" :) _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From olivier.berger at it-sudparis.eu Tue Nov 3 17:28:52 2009 From: olivier.berger at it-sudparis.eu (Olivier Berger) Date: Tue, 03 Nov 2009 18:28:52 +0100 Subject: The Bugzilla Migration Framework In-Reply-To: <4AE293E2.2020604@bugzilla.org> References: <4AE293E2.2020604@bugzilla.org> Message-ID: <1257269332.8353.124.camel@hortense> Hi. Le vendredi 23 octobre 2009 ? 22:42 -0700, Max Kanat-Alexander a ?crit : > 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. > Interesting news. I have one question : if I understand it correctly, it works by connecting to both bugtrackers' databases to do the "on the fly" conversion, right ? Have you thought about using some dump + restore approach involving some intermediate interchange format ? Thanks in advance. Best regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ing?nieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) From dmarshal at yahoo-inc.com Thu Nov 12 05:50:45 2009 From: dmarshal at yahoo-inc.com (David Marshall) Date: Wed, 11 Nov 2009 21:50:45 -0800 Subject: Proliferation of custom fields In-Reply-To: <4AFA3EC6.40405@bugzilla.org> Message-ID: On 11/10/09 8:34 PM, "David Miller" wrote: > So, it shouldn't be any surprise that custom fields actually get used > now that they're available. We're starting to add quite a few of them > for specific purposes at Mozilla. > > When you add a custom field that isn't a multi-select or a map, (just a > string or a date for example) it gets added as a column to the bugs > table. I've got a little voice in the back of my head telling me that's > going to hurt eventually if we keep adding fields. Is my little voice > correct, or have I nothing to worry about? Is there a better way to > architect it in the long run that won't cause as much damage? Maybe a > second table for bugs_custom that is only joined once by bug_id and is > otherwise just custom fields for bugs? That only buys you so much time, > too, but potentially less stress on things that look at bugs and don't > touch custom fields... At Yahoo!, we're we have over 3500 products, when that great day arrives that we make it to 3.4, we're going to have per-product custom fields. As such, it won't be quite feasible to add columns to table bugs for these. I haven't done any design on this yet, but I foresee a custom_fieldsdef table that describes custom fields for a given product_id. Then there will be a table such as custom_fields that records custom field values for a given bug_id. I haven't done any work on use cases for when a bug moves from one product to another and custom fields become obsolete. This is intentionally analogous to keyworddefs/keywords. I'll share more when this nears actual fruition. From guy.pyrzak at gmail.com Thu Nov 12 06:18:46 2009 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Wed, 11 Nov 2009 22:18:46 -0800 Subject: Getting more data from inside a template In-Reply-To: References: Message-ID: you can access lots of perl stuff without EVAL_PERL being turned on. For example you can call Bugzilla.get_fields to get fields that match the value that you want and they come back as perl fields. That being said, I'm not sure if such an method currently exists for statuses as it does for fields. We have altered our version to treat all fields the same (custom and not) and therefore we can access the field_values via the field. I'm not sure if this is true for core bugzilla though. If it was once you got the field you could do field.legal_values. The other option is you just add the method to an existing object that is exposed to template, in this example i was using Bugzilla, but you can expose other objects as well. -Guy On Mon, Oct 19, 2009 at 8:24 AM, Gervase Markham wrote: > 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 > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Thu Nov 12 06:33:31 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Nov 2009 22:33:31 -0800 Subject: Proliferation of custom fields In-Reply-To: <4AFA3EC6.40405@bugzilla.org> References: <4AFA3EC6.40405@bugzilla.org> Message-ID: <4AFBAC3B.5070409@bugzilla.org> On 11/10/2009 08:34 PM, David Miller wrote: > When you add a custom field that isn't a multi-select or a map, (just a > string or a date for example) it gets added as a column to the bugs > table. I've got a little voice in the back of my head telling me that's > going to hurt eventually if we keep adding fields. Is my little voice > correct, or have I nothing to worry about? I'm pretty sure that would only be a problem if you were adding hundreds of fields. Even then, it might not be a problem. So it's not something to worry about, really. Some of my clients have like 40 or 50 custom fields and I haven't heard any particular performance complaints from them that were related to the bugs table. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 12 06:34:45 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Nov 2009 22:34:45 -0800 Subject: Proliferation of custom fields In-Reply-To: References: Message-ID: <4AFBAC85.8080502@bugzilla.org> On 11/11/2009 09:50 PM, David Marshall wrote: > At Yahoo!, we're we have over 3500 products, when that great day arrives > that we make it to 3.4, we're going to have per-product custom fields. As > such, it won't be quite feasible to add columns to table bugs for these. Are you sure? How many fields will there actually be? Why not share the same field between many products? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 12 06:36:19 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Nov 2009 22:36:19 -0800 Subject: The Bugzilla Migration Framework In-Reply-To: <1257269332.8353.124.camel@hortense> References: <4AE293E2.2020604@bugzilla.org> <1257269332.8353.124.camel@hortense> Message-ID: <4AFBACE3.4080906@bugzilla.org> On 11/03/2009 09:28 AM, Olivier Berger wrote: > I have one question : if I understand it correctly, it works by > connecting to both bugtrackers' databases to do the "on the fly" > conversion, right ? It doesn't *have* to do anything. It's just Perl modules that have methods that return data. > Have you thought about using some dump + restore approach involving some > intermediate interchange format ? If you wanted to write a migrator that did that, you would be welcome to do so, provided that it were well-architected and maintainable by us. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 12 06:39:54 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Nov 2009 22:39:54 -0800 Subject: Self introduction: Krzysztof Drewniak In-Reply-To: <1257563059.23813.81.camel@krzys-desktop.home> References: <1257563059.23813.81.camel@krzys-desktop.home> Message-ID: <4AFBADBA.2020204@bugzilla.org> On 11/06/2009 07:04 PM, Krzysztof Drewniak wrote: > I know Perl to the point of getting by. I can probably pick up some > intermediate SQL if I ever need to work with it. I know simple HTML (the > template files' HTML seems understandable enough (for me)). I am bot > familiar with Template, but the Template documentation will most likely > be self-explanatory. I have not worked on any FOSS projects before, but > this seemed like a good place to start my development experience. Great! Welcome! :-) > I > haven't figured out what I will be working on, but I plan to fix bug > #369080 for starters. I'm not entirely sure that that bug is something we should be doing. It was marked as a "[Good Intro Bug]" by its reporter, not by us. > P.S. Where's the message sending code? Bugzilla/BugMail.pm. The actual email gets sent by Bugzilla/Mailer.pm. > P.P.S. Is ; a legal email address character (Google didn't help much). http://en.wikipedia.org/wiki/E-mail_address#RFC_specification -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 12 06:41:46 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Nov 2009 22:41:46 -0800 Subject: The Bugzilla Migration Framework In-Reply-To: References: Message-ID: <4AFBAE2A.4000408@bugzilla.org> On 10/26/2009 03:22 AM, Gervase Markham wrote: > Do we then have an install of GNATS on Landfill that we are planning to > use to test the migrator with? We don't, currently. I have the client's database that I used to develop the migrator with, but I don't think I can make that public. > An obvious consequence of this is that someone could write a Bugzilla > migrator, and you could use it to merge Bugzilla installations. Totally. Though it would require quite a bit more work on Bugzilla::Migrate itself (and probably on Bugzilla itself) to make that feasible. >> 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. Thanks!! :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 12 06:44:46 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Nov 2009 22:44:46 -0800 Subject: Getting more data from inside a template In-Reply-To: References: Message-ID: <4AFBAEDE.9010708@bugzilla.org> On 10/19/2009 09:24 AM, Gervase Markham wrote: > 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.) There isn't really much way to do that, at least not for objects you don't already have some sort of access to. In 3.6 there's going to be a template-before_process hook that allows extensions to add additional variables into $vars before any template is loaded, so that would help a bit for extensions. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 12 06:46:40 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Nov 2009 22:46:40 -0800 Subject: Configuration object In-Reply-To: References: Message-ID: <4AFBAF50.3080309@bugzilla.org> On 10/15/2009 08:53 AM, Gervase Markham wrote: > 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. To be honest, there really is so much complexity, and so many things that are going to possibly be changing about Bugzilla's configuration and backend in the future, that I'm not sure I can give a good review on this right now. I'd say to use your best judgment (which seems pretty good so far for the API stuff) and then if there are specific questions, ask those and see if we have some answers. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 12 06:48:55 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 11 Nov 2009 22:48:55 -0800 Subject: The timezone problem In-Reply-To: References: Message-ID: <4AFBAFD7.7010403@bugzilla.org> On 10/13/2009 09:14 AM, Gervase Markham wrote: > 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 The XML-RPC "time" method does return that information. If you log out of Bugzilla you'll always get Bugzilla's local timezone. > => 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? I think that would work. You could even use DateTime like we do, so you'd be using the same code to get convert it backward that we're using to spit out the timezone info in the first place. The only problem is that we're not *storing* times in UTC, so DST times will actually be wrong when converted, I think (not sure). -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From bugzilla at colinogilvie.co.uk Thu Nov 12 07:29:50 2009 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Thu, 12 Nov 2009 07:29:50 +0000 Subject: Mass influx of old emial Message-ID: <4AFBB96E.50007@colinogilvie.co.uk> Not strictly on topic... but am I the only one to have suddenly received a load of CVS commit messages, review requests and a few messages from this list that have been stuck on Mozilla servers for more than a week or so? Colin From justdave at bugzilla.org Thu Nov 12 07:35:13 2009 From: justdave at bugzilla.org (David Miller) Date: Thu, 12 Nov 2009 02:35:13 -0500 Subject: Mass influx of old emial In-Reply-To: <4AFBB96E.50007@colinogilvie.co.uk> References: <4AFBB96E.50007@colinogilvie.co.uk> Message-ID: <4AFBBAB1.2070600@bugzilla.org> Colin Ogilvie wrote on 11/12/09 2:29 AM: > Not strictly on topic... but am I the only one to have suddenly received > a load of CVS commit messages, review requests and a few messages from > this list that have been stuck on Mozilla servers for more than a week > or so? Nope, the inbound queue in majordomo was jammed because a logfile filled up. I rotated the logs and gave it a kick a couple hours ago. -- 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 emmanuel.seyman at club-internet.fr Thu Nov 12 09:56:04 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Thu, 12 Nov 2009 10:56:04 +0100 Subject: Bugzilla meeting now on IRC!! Join us! In-Reply-To: References: <4AE7377D.8050104@gmail.com> Message-ID: <20091112095604.GB13111@orient.maison.lan> * Itamar Reis Peixoto [12/11/2009 10:21] : > > what irc-server ? We meet and discuss on irc.mozilla.org . Emmanuel _______________________________________________ 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 Nov 12 11:36:33 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Nov 2009 11:36:33 +0000 Subject: Self introduction: Krzysztof Drewniak In-Reply-To: References: Message-ID: <2-6dndlR_f3fbmbXnZ2dnUVZ_qJi4p2d@mozilla.org> On 07/11/09 03:04, Krzysztof Drewniak wrote: > P.S. Where's the message sending code? SendMessageToMTA? > P.P.S. Is ; a legal email address character (Google didn't help much). No, it's not - certainly not in practice, anyway. 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 Nov 12 11:48:17 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Nov 2009 11:48:17 +0000 Subject: Configuration object In-Reply-To: References: Message-ID: On 12/11/09 06:46, Max Kanat-Alexander wrote: > To be honest, there really is so much complexity, and so many things > that are going to possibly be changing about Bugzilla's configuration > and backend in the future, that I'm not sure I can give a good review on > this right now. I'd say to use your best judgment (which seems pretty > good so far for the API stuff) and then if there are specific questions, > ask those and see if we have some answers. OK, fair enough :-) Here are some specific questions: 1) This data in JSON form is 157k for bugzilla.mozilla.org[0], and is likely to be more for Bugzillas with more products, components or flags. In particular, as flags are valid per-component, 2/3 of that 157k is saying which flags are valid for every component. It could be that people don't always want all the data. So I'd like to add an option or two that they can add as parameters to not include some stuff. The question is, what? I've added "flags=0" to remove all flags stuff. You could still use the resulting data for anything except adding flags to bugs or attachments. Are there other slices and dices which might still be useful but of lower volume? 2) Does my reasoning for not wrapping Classifications around Products make sense? 3) Can you think of any more params we should obviously expose? 4) Should we index the "group" hash by "id" or "name"? Both are unique. 5) Are there any plans to make request_group and grant_group multi-valued? Gerv [0] https://bugzilla-stage-tip.mozilla.org/config.cgi?ctype=json (note: this is down as I write but should be back soon) _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From bbaetz at gmail.com Thu Nov 12 12:42:13 2009 From: bbaetz at gmail.com (Bradley Baetz) Date: Thu, 12 Nov 2009 23:42:13 +1100 Subject: The timezone problem In-Reply-To: <4AFBAFD7.7010403@bugzilla.org> References: <4AFBAFD7.7010403@bugzilla.org> Message-ID: <99435f5b0911120442r2d32f618od3d05f4f991ad9fc@mail.gmail.com> On Thu, Nov 12, 2009 at 5:48 PM, Max Kanat-Alexander wrote: > > ? ? ? ?I think that would work. You could even use DateTime like we do, so > you'd be using the same code to get convert it backward that we're using > to spit out the timezone info in the first place. The only problem is > that we're not *storing* times in UTC, so DST times will actually be > wrong when converted, I think (not sure). Yeah, the DST thing is a common issue. I'd like for us to say that all times are UTC, always, and the front ends do the conversion, but I'm not 100% sure that stuff won't break. I'm pretty sure that we require the DB server and the web server to be in the same timezone because of these issues (do we still?), so if you're doing any client-side conversion there may be issues. Long term it'd be best to do UTC and fix what breaks, rather than encode a local timestamp into a brand new interface, though. Bradley From bbaetz at gmail.com Thu Nov 12 12:48:48 2009 From: bbaetz at gmail.com (Bradley Baetz) Date: Thu, 12 Nov 2009 23:48:48 +1100 Subject: Proliferation of custom fields In-Reply-To: <4AFA3EC6.40405@bugzilla.org> References: <4AFA3EC6.40405@bugzilla.org> Message-ID: <99435f5b0911120448uf1df48fl4fe4535b2c5bd0de@mail.gmail.com> On Wed, Nov 11, 2009 at 3:34 PM, David Miller wrote: > So, it shouldn't be any surprise that custom fields actually get used > now that they're available. ?We're starting to add quite a few of them > for specific purposes at Mozilla. > > When you add a custom field that isn't a multi-select or a map, (just a > string or a date for example) it gets added as a column to the bugs > table. ?I've got a little voice in the back of my head telling me that's > going to hurt eventually if we keep adding fields. ?Is my little voice > correct, or have I nothing to worry about? ?Is there a better way to > architect it in the long run that won't cause as much damage? ?Maybe a > second table for bugs_custom that is only joined once by bug_id and is > otherwise just custom fields for bugs? ?That only buys you so much time, > too, but potentially less stress on things that look at bugs and don't > touch custom fields... I disliked the idea of adding fields to the bugs table originally, but didn't have a better idea. Pros: * don't have to join to lots of tables. Big plus given mysql's optmizer, plus locality of data, etc * Some of the buglist stuff becomes a bit more painful once you need to handle aggregates * We can easily have FK constraints enforced on the data * Any 'bugs_custom' is going to have to be looked up almost any time you wanted to read the bugs table anyway * More precise indexes (ie on each column rather than a mega (fielddef,value) index - again, better cache size, etc Cons: * Schema changes through the web interface feel icky (especially the error cases, and script timeouts, and etc, since this mostly can't happen in a transaction) * Extra data that isn't needed all the time is present * full table scans take longer because there is more data (of course a full table scan is almost always a bug) * It let us not have to think about what happens to data as a bug is moved between components/products/etc. (e.g buglist.cgi on a cf may show bugs where that CF doesn't apply) As the dependant field stuff gets more complicated this may have to be revisited anyway. Bradley From Nick.Barnes at pobox.com Thu Nov 12 13:19:51 2009 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Thu, 12 Nov 2009 13:19:51 +0000 Subject: Self introduction: Krzysztof Drewniak In-Reply-To: <2-6dndlR_f3fbmbXnZ2dnUVZ_qJi4p2d@mozilla.org> from Gervase Markham of "Thu, 12 Nov 2009 11:36:33 +0000" Message-ID: <26563.1258031991@thrush.ravenbrook.com> At 2009-11-12 11:36:33+0000, Gervase Markham writes: > On 07/11/09 03:04, Krzysztof Drewniak wrote: > > P.S. Where's the message sending code? > > SendMessageToMTA? > > > P.P.S. Is ; a legal email address character (Google didn't help much). > > No, it's not - certainly not in practice, anyway. See RFC822 (or RFC5322, which will supercede): Search 5322 for "atext". Short answer: you have to quote it. Unquoted, it has magic semantics as part of a mailbox group, like this: To: My Magic Recipient List: fred at bar.baz, Jim , "Sheila Semi;colon" ; The addresses in that group will generally be removed from the header by the MTA, so when Fred, Jim and Sheila get it, it will look like this: To: My Magic Recipient List:; I hope this helps. RFC5322 has appendices with lots more examples. Nick B From ghendricks at novell.com Thu Nov 12 17:07:18 2009 From: ghendricks at novell.com (Gregary Hendricks) Date: Thu, 12 Nov 2009 10:07:18 -0700 Subject: Mass influx of old emial In-Reply-To: <4AFBBAB1.2070600@bugzilla.org> References: <4AFBB96E.50007@colinogilvie.co.uk> <4AFBBAB1.2070600@bugzilla.org> Message-ID: <4AFBDE56020000D20005D8A3@soto.provo.novell.com> >>> On 11/12/2009 at 12:35 AM, in message <4AFBBAB1.2070600 at bugzilla.org>, David Miller wrote: > Colin Ogilvie wrote on 11/12/09 2:29 AM: > > Not strictly on topic... but am I the only one to have suddenly received > > a load of CVS commit messages, review requests and a few messages from > > this list that have been stuck on Mozilla servers for more than a week > > or so? > > Nope, the inbound queue in majordomo was jammed because a logfile filled > up. I rotated the logs and gave it a kick a couple hours ago. Oh good, I was wondering how it was that we could time warp back to the next Bugzilla meeting scheduled for two weeks ago. ;-) From mkanat at bugzilla.org Thu Nov 12 18:44:45 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 12 Nov 2009 10:44:45 -0800 Subject: The timezone problem In-Reply-To: <99435f5b0911120442r2d32f618od3d05f4f991ad9fc@mail.gmail.com> References: <4AFBAFD7.7010403@bugzilla.org> <99435f5b0911120442r2d32f618od3d05f4f991ad9fc@mail.gmail.com> Message-ID: <4AFC579D.20008@bugzilla.org> On 11/12/2009 04:42 AM, Bradley Baetz wrote: > Yeah, the DST thing is a common issue. I'd like for us to say that all > times are UTC, always, and the front ends do the conversion, but I'm > not 100% sure that stuff won't break. I think the UTC thing should still be done. It's something that we'd have to think about quite a bit and start on early in a development cycle--maybe for 3.8. > I'm pretty sure that we require > the DB server and the web server to be in the same timezone because of > these issues (do we still?), so if you're doing any client-side > conversion there may be issues. Yeah, we do still require that. > Long term it'd be best to do UTC and fix what breaks, rather than > encode a local timestamp into a brand new interface, though. Agreed. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Nov 12 18:50:19 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 12 Nov 2009 10:50:19 -0800 Subject: Configuration object In-Reply-To: References: Message-ID: <4AFC58EB.50100@bugzilla.org> On 11/12/2009 03:48 AM, Gervase Markham wrote: > 1) This data in JSON form is 157k for bugzilla.mozilla.org[0], and is > likely to be more for Bugzillas with more products, components or flags. > In particular, as flags are valid per-component, 2/3 of that 157k is > saying which flags are valid for every component. Hmm. Yeah, that's quite a bit. Is it still very large with gzip or deflate? > It could be that people don't always want all the data. So I'd like to > add an option or two that they can add as parameters to not include some > stuff. The question is, what? I've added "flags=0" to remove all flags > stuff. You could still use the resulting data for anything except adding > flags to bugs or attachments. Are there other slices and dices which > might still be useful but of lower volume? Some people might want to only request specific products, which config.cgi already supports. That helps a bit. > 2) Does my reasoning for not wrapping Classifications around Products > make sense? Yeah, seems reasonable. > 3) Can you think of any more params we should obviously expose? utf8, and the data returned by Bugzilla.time from the WebService. Maybe others, would have to go through the list and think about it. > 4) Should we index the "group" hash by "id" or "name"? Both are unique. Depends on how the rest of the API uses them. If you return ids elsewhere, then ids should be the key, and should generally be used everywhere. If you return names, then names should be the key. > 5) Are there any plans to make request_group and grant_group multi-valued? No, I don't think so, because there's group inheritance. > [0] https://bugzilla-stage-tip.mozilla.org/config.cgi?ctype=json > (note: this is down as I write but should be back soon) > _______________________________________________ > 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: > -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Fri Nov 13 10:03:19 2009 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Nov 2009 10:03:19 +0000 Subject: Configuration object In-Reply-To: References: Message-ID: <1rudnR61t9Z1s2DXnZ2dnUVZ_tudnZ2d@mozilla.org> On 12/11/09 18:50, Max Kanat-Alexander wrote: > Hmm. Yeah, that's quite a bit. Is it still very large with gzip or deflate? 129k -> 18k with gzip. So no. I guess that could be a solution. Does Apache magically gzip stuff as a transport-encoding or do you have to tell it to in some way? > Some people might want to only request specific products, which > config.cgi already supports. That helps a bit. I could certainly add that. >> 3) Can you think of any more params we should obviously expose? > > utf8, and the data returned by Bugzilla.time from the WebService. Maybe > others, would have to go through the list and think about it. Rather than exposing the utf8 parameter, I would prefer that all interactions with the API were in utf8, and if Bugzilla was not using utf8, the API proxy did conversions. In fact, I would rather just make utf8 being on a pre-requisite for using the proxy with a particular Bugzilla ;-) How unreasonable would that be? Are there still significant sites which haven't converted? >> 4) Should we index the "group" hash by "id" or "name"? Both are unique. > > Depends on how the rest of the API uses them. If you return ids > elsewhere, then ids should be the key, and should generally be used > everywhere. If you return names, then names should be the key. I'm returning both, as an object. https://wiki.mozilla.org/Bugzilla:REST_API:Objects#Group >> 5) Are there any plans to make request_group and grant_group multi-valued? > > No, I don't think so, because there's group inheritance. OK. I'll stop worrying about that, then. 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 Nov 13 20:39:23 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 13 Nov 2009 12:39:23 -0800 Subject: Configuration object In-Reply-To: <1rudnR61t9Z1s2DXnZ2dnUVZ_tudnZ2d@mozilla.org> References: <1rudnR61t9Z1s2DXnZ2dnUVZ_tudnZ2d@mozilla.org> Message-ID: <4AFDC3FB.1030900@bugzilla.org> On 11/13/2009 02:03 AM, Gervase Markham wrote: > 129k -> 18k with gzip. So no. I guess that could be a solution. Does > Apache magically gzip stuff as a transport-encoding or do you have to > tell it to in some way? I believe you have to tell it to, although I'm not certain. > Rather than exposing the utf8 parameter, I would prefer that all > interactions with the API were in utf8, and if Bugzilla was not using > utf8, the API proxy did conversions. Um, you can't do that, because unless utf8 is on, you have no idea what the encoding you're receiving is. > In fact, I would rather just make utf8 being on a pre-requisite for > using the proxy with a particular Bugzilla ;-) How unreasonable would > that be? Are there still significant sites which haven't converted? That would be entirely reasonable. There are no major sites that I know of that haven't converted, unless they're running a very old Bugzilla version. >>> 4) Should we index the "group" hash by "id" or "name"? Both are unique. >> >> Depends on how the rest of the API uses them. If you return ids >> elsewhere, then ids should be the key, and should generally be used >> everywhere. If you return names, then names should be the key. > > I'm returning both, as an object. > https://wiki.mozilla.org/Bugzilla:REST_API:Objects#Group Okay. If you return both everywhere, then I'd say that the name is a better key, as that's what clients will know and have, yes? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From bbaetz at gmail.com Thu Nov 12 06:29:31 2009 From: bbaetz at gmail.com (Bradley Baetz) Date: Thu, 12 Nov 2009 17:29:31 +1100 Subject: Getting more data from inside a template In-Reply-To: References: Message-ID: <99435f5b0911112229p646f19bic540cf32b0401865@mail.gmail.com> On Tue, Oct 20, 2009 at 3:24 AM, Gervase Markham wrote: > 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.) Not directly, but the Bugzilla object is available > (I want to call Bugzilla::Status->get_all to get information on status > transitions that config.cgi isn't giving me.) Is that exposed in Bugzilla.pm? If so then Bugzilla.foo() will work. Bradley PS I just got a bunch of messages from late october that I hadn't seen before - was something mailman-related stuck? From szabgab at gmail.com Sun Nov 15 13:36:10 2009 From: szabgab at gmail.com (Gabor Szabo) Date: Sun, 15 Nov 2009 15:36:10 +0200 Subject: Bugzilla on FOSDEM CeBIt and on Perl events Message-ID: On the wiki meeting https://wiki.mozilla.org/Bugzilla:Meetings:2009-10-27 I mentioned that I am trying to get some Perl action on various events. In addition I think I never seen a Bugzilla talk on any of the YAPC::EU events I participated. So I would like to get these things moving in both directions. FOSDEM http://www.fosdem.org/2010/ is 6-7 February 2010 in Brussels, Belgium. CeBIT is http://www.cebit.de/opensource_e 206 March 2010 in Hannover, Germany On FOSDEM I am going to apply for a stand for Perl where I would like to have representatives of several Perl related projects. We will have to man the stand during the two days. In addition there are going to be developer rooms with talks probably grouped by fields but it is still not clear to me. I'd like to make sure many such rooms will have at least one Perl related talk. I might propose a room for "development tools" where we can showcase things such as bug tracking system, editors (I am running a project called Padre) and other things. On CeBit I think we might get a booth that we will have to man during the whole show. I don't think there are talks involved there. So I would like to know if anyone from the Bugzilla community is interested in participating either of these events? regards Gabor From lpsolit at gmail.com Sun Nov 15 16:10:55 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sun, 15 Nov 2009 17:10:55 +0100 Subject: Bugzilla on FOSDEM CeBIt and on Perl events In-Reply-To: References: Message-ID: <4B00280F.5020601@gmail.com> Le 15. 11. 09 14:36, Gabor Szabo a ?crit : > In addition there are going to be developer rooms > with talks > probably grouped by fields but it is still not clear to me. I'd like > to make sure > many such rooms will have at least one Perl related talk. Looks like Bugzilla is already something they have in mind, from what I can read at http://www.fosdem.org/2010/distrominiconf In the "Community Infrastructure" section, I can read "Bugzilla extensions". Does someone know which languages are used in these talks? English only? LpSolit From joesab2005 at gmail.com Sun Nov 15 17:09:35 2009 From: joesab2005 at gmail.com (JoeS) Date: Sun, 15 Nov 2009 12:09:35 -0500 Subject: Pre 3.4.3 upgrade question Message-ID: I use a bookmarklet to copy bug data into bbs format for a forum. Just wondering if it will have to be modified for 3.4.3 Here's the code: javascript:(function()%20{%20var%20title%20=%20document.title;%20function%20htmlEscape(s){return%20s;};%20var%20OS=document.getElementById(%22op_sys%22).value.substring(0,3)%20;var%20PR=document.getElementById(%22product%22).value%20;var%20comp=document.getElementById(%22component%22).value;if(comp==%22XSLT%22||comp==%22MathML%22||%20comp==%22XForms%22||comp==%22SVG%22||comp==%22Layout:%20Canvas%22||comp==%22Editor%22||comp==%22Build%20Config%22)%20PR=PR+%22:%22+comp;textToCopy=%22[*][url=%22%20+%20location.href%20+%20%22]#%20%22%20+%20/\d+/(title)[0]%20+%20%22[/url]%20[%22%20+%20PR%20+%22]%20-%20%22+htmlEscape(/%E2%80%93.*/(title)[0].slice(2))%20+%22%20[%22+OS%20+%22]%22+%20%22%22;document.write(%22%20%22);%20document.close();%20document.f.ta.value%20=%20textToCopy;%20document.f.ta.select();%20})() If someone could look through that could see if there are problems for the new version, that would be much appreciated. -- JoeS _______________________________________________ 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 Nov 15 19:59:14 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 15 Nov 2009 11:59:14 -0800 Subject: Pre 3.4.3 upgrade question In-Reply-To: References: Message-ID: <4B005D92.6040709@bugzilla.org> On 11/15/2009 09:09 AM, JoeS wrote: > I use a bookmarklet to copy bug data into bbs format for a forum. > Just wondering if it will have to be modified for 3.4.3 Probably the best place to ask this would be the support-bugzilla mailing list, described here: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Mon Nov 16 09:53:46 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Nov 2009 09:53:46 +0000 Subject: Getting more data from inside a template In-Reply-To: References: Message-ID: <0vGdnYCLu4W3vJzWnZ2dnUVZ_uGdnZ2d@mozilla.org> On 12/11/09 06:29, Bradley Baetz wrote: > Is that exposed in Bugzilla.pm? If so then Bugzilla.foo() will work. I'll look; thanks. > PS I just got a bunch of messages from late october that I hadn't seen > before - was something mailman-related stuck? Apparently so, according to justdave. 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 Nov 16 09:56:22 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Nov 2009 09:56:22 +0000 Subject: Bugzilla on FOSDEM CeBIt and on Perl events In-Reply-To: References: Message-ID: <0vGdnYKLu4VavJzWnZ2dnUVZ_uGdnZ2d@mozilla.org> On 15/11/09 16:10, Fr?d?ric Buclin wrote: > Looks like Bugzilla is already something they have in mind, from what I > can read at http://www.fosdem.org/2010/distrominiconf > > In the "Community Infrastructure" section, I can read "Bugzilla extensions". > > Does someone know which languages are used in these talks? English only? Pretty much everything that happens at FOSDEM is in English, yes. 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 Nov 16 09:55:24 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Nov 2009 09:55:24 +0000 Subject: Configuration object In-Reply-To: References: <1rudnR61t9Z1s2DXnZ2dnUVZ_tudnZ2d@mozilla.org> Message-ID: <0vGdnYOLu4URvJzWnZ2dnUVZ_uGdnZ2d@mozilla.org> On 13/11/09 20:39, Max Kanat-Alexander wrote: > That would be entirely reasonable. There are no major sites that I know > of that haven't converted, unless they're running a very old Bugzilla > version. OK, I'll document that restriction. >> I'm returning both, as an object. >> https://wiki.mozilla.org/Bugzilla:REST_API:Objects#Group > > Okay. If you return both everywhere, then I'd say that the name is a > better key, as that's what clients will know and have, yes? Surely they are more likely to have the ID? After all, isn't it true that group names can in some cases be confidential, and that's why the IDs are exposed and used on the process_bug edit interface? 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 Nov 16 09:57:18 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 16 Nov 2009 09:57:18 +0000 Subject: Bugzilla on FOSDEM CeBIt and on Perl events In-Reply-To: References: Message-ID: <0vGdnb2Lu4VjvJzWnZ2dnUVZ_uGdnZ2d@mozilla.org> On 15/11/09 13:36, Gabor Szabo wrote: > So I would like to get these things moving in both directions. > > FOSDEM http://www.fosdem.org/2010/ is 6-7 February 2010 in Brussels, Belgium. I am at FOSDEM every year, and plan to attend next year. > So I would like to know if anyone from the Bugzilla community is interested in > participating either of these events? I am happy to give a talk on Bugzilla at FOSDEM, but given my Mozilla responsibilities, I would not be able to help man a stand. 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 Nov 16 20:31:22 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 16 Nov 2009 12:31:22 -0800 Subject: Configuration object In-Reply-To: <0vGdnYOLu4URvJzWnZ2dnUVZ_uGdnZ2d@mozilla.org> References: <1rudnR61t9Z1s2DXnZ2dnUVZ_tudnZ2d@mozilla.org> <0vGdnYOLu4URvJzWnZ2dnUVZ_uGdnZ2d@mozilla.org> Message-ID: <4B01B69A.3030206@bugzilla.org> On 11/16/2009 01:55 AM, Gervase Markham wrote: > Surely they are more likely to have the ID? After all, isn't it true > that group names can in some cases be confidential, and that's why the > IDs are exposed and used on the process_bug edit interface? To be honest, I've never interacted with groups via the API, so I think you would know better than me. I'd like to make things work based on how Bugzilla should ideally be working (that is, as it will be working in the future) because that way we don't have to change things or aren't left around with legacy cruft when Bugzilla does "catch up" in some areas. This is, of course, as long as this strategy doesn't interfere with making certain features work now. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Tue Nov 17 14:45:10 2009 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 17 Nov 2009 14:45:10 +0000 Subject: The timezone problem In-Reply-To: References: Message-ID: On 13/10/09 17:14, Gervase Markham wrote: > So I'm looking at trying to solve (as best I can) the timezone problem > for my API. OK, I think I've cracked this. Every timezone on the API is now output in the following form: YYYY-MM-DDTHH:MM:SSZ (literal T and Z), which is ISO 8601 extended format. And assuming you tell the API what the timezone of the target Bugzilla is, all the timestamps are correct. (Yes, I could have determined this programmatically at every startup, but it seemed easier to just have it as a config.) I _think_ this will work even if the user changes their TZ preferences, because the stamps output still have TZ info attached, which means I can convert back to UTC. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From michael.j.tosh at lmco.com Mon Nov 16 16:25:18 2009 From: michael.j.tosh at lmco.com (Tosh, Michael J) Date: Mon, 16 Nov 2009 11:25:18 -0500 Subject: Mass influx of old emial In-Reply-To: <4AFBDE56020000D20005D8A3@soto.provo.novell.com> References: <4AFBB96E.50007@colinogilvie.co.uk> <4AFBBAB1.2070600@bugzilla.org> <4AFBDE56020000D20005D8A3@soto.provo.novell.com> Message-ID: <8A06826F0DE9AD4087CEBD52E769C0DC0E5413B9@HVXMSPB.us.lmco.com> Gregary Hendricks wrote: > Oh good, I was wondering how it was that we could time warp back to the next > Bugzilla meeting scheduled for two weeks ago. > ;-) > And here I thought Mozilla Foundation was working on an Open Source Time Machine... Darn. From gerv at mozilla.org Fri Nov 20 10:27:34 2009 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 20 Nov 2009 10:27:34 +0000 Subject: Raindrop, mailing lists and Majordomo Message-ID: http://www.melez.com/mykzilla/2009/11/skinny-on-raindrops-mailing-list.html says that: "Majordomo2 (used by the Bugzilla and OpenBSD projects, among others) is not supported, because it doesn't send List-* headers (alhough supposedly it can be configured to do so)." Is ours configured to do so? If not, can it be? Also, the bugzilla-dev list is gatewayed to mozilla.dev.apps.bugzilla, which is a Mailman list, and therefore supported, right? 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 Nov 21 04:16:16 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 20 Nov 2009 20:16:16 -0800 Subject: Freeze Reminder: November 24 Message-ID: <4B076990.4060209@bugzilla.org> We have our soft freeze for Bugzilla 3.6 on November 24. That means that, after that point, no enhancements will be accepted that do not already have a patch under review. Two weeks after that (December 8) will be the "hard freeze", when no new enhancements will be accepted at all (shortly after that we will branch for 3.6). -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From xerces9 at gmail.com Mon Nov 23 12:26:38 2009 From: xerces9 at gmail.com (=?UTF-8?Q?David_Bala=C5=BEic?=) Date: Mon, 23 Nov 2009 13:26:38 +0100 Subject: Simplified users Timezone handling Message-ID: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> (originally posted on nntp mozilla.support.bugzilla : http://groups.google.com/group/mozilla.support.bugzilla/browse_thread/thread/c36721d5ec8f8820/cfcdad7d5af3405d posting here on suggestion from Max Kanat-Alexander ) Hi! In version 3.4.3 for the displaying times and dates in users timezone, currently this is required: - a bunch of code on the server (bugzilla) - user must login (on each visit, unless "cookied") - user must set timezone in preferences I suggest a much simpler solution: - a few lines of code in the server That's it. No user action required. This solution also automatically handles daylight saving time changes. It puzzles me why (web) server software writers go through all this trouble when a few lines of code does it all ;-) The code (as sent to users web browser): Time of action (in your local tz !): * - the time as miliseconds since epoch inserted by server ** - regular time inserted by server, as it is done now (or before, when it was always in servers TZ) It needs Java/ECMAScript, obviously, so the NOSCRIPT fallback. JS is already used so while many (me included) think JS is evil, this is no change in that regard. If user happens to have no JS (or have disabled it), a fallback to old behavior is done, so no harm. Regards, David From lpsolit at gmail.com Mon Nov 23 14:14:24 2009 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 23 Nov 2009 15:14:24 +0100 Subject: Simplified users Timezone handling In-Reply-To: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> References: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> Message-ID: <4B0A98C0.3070907@gmail.com> Le 23. 11. 09 13:26, David Bala?ic a ?crit : > That's it. No user action required. > > This solution also automatically handles daylight saving time changes. This won't work. Your suggestion only works when viewing bugs from a web browser *and* having JS turned on. This won't work for bugmails. And I'm pretty sure you still have to store the timezone somewhere to do the conversion correctly. LpSolit From gerv at mozilla.org Mon Nov 23 16:34:38 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 23 Nov 2009 16:34:38 +0000 Subject: Configuration object In-Reply-To: References: <1rudnR61t9Z1s2DXnZ2dnUVZ_tudnZ2d@mozilla.org> <0vGdnYOLu4URvJzWnZ2dnUVZ_uGdnZ2d@mozilla.org> Message-ID: On 16/11/09 20:31, Max Kanat-Alexander wrote: > On 11/16/2009 01:55 AM, Gervase Markham wrote: >> Surely they are more likely to have the ID? After all, isn't it true >> that group names can in some cases be confidential, and that's why the >> IDs are exposed and used on the process_bug edit interface? > > To be honest, I've never interacted with groups via the API, so I think > you would know better than me. I'm just quoting something I thought I heard you say a while back - that group names of groups a person is not a member of are considered confidential. Isn't that right? If that is true, it seems to make sense that sometimes a user will have an ID and not a name, and so we should make IDs primary. > I'd like to make things work based on how Bugzilla should ideally be > working (that is, as it will be working in the future) because that way > we don't have to change things or aren't left around with legacy cruft > when Bugzilla does "catch up" in some areas. This is, of course, as long > as this strategy doesn't interfere with making certain features work now. Absolutely :-) 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 Tue Nov 24 00:35:54 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 23 Nov 2009 16:35:54 -0800 Subject: Configuration object In-Reply-To: References: <1rudnR61t9Z1s2DXnZ2dnUVZ_tudnZ2d@mozilla.org> <0vGdnYOLu4URvJzWnZ2dnUVZ_uGdnZ2d@mozilla.org> Message-ID: <4B0B2A6A.4040601@bugzilla.org> On 11/23/2009 08:34 AM, Gervase Markham wrote: > I'm just quoting something I thought I heard you say a while back - that > group names of groups a person is not a member of are considered > confidential. Isn't that right? That's right. > If that is true, it seems to make sense that sometimes a user will have > an ID and not a name, and so we should make IDs primary. That makes sense. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Tue Nov 24 00:37:06 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 23 Nov 2009 16:37:06 -0800 Subject: Simplified users Timezone handling In-Reply-To: <4B0A98C0.3070907@gmail.com> References: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> <4B0A98C0.3070907@gmail.com> Message-ID: <4B0B2AB2.3090004@bugzilla.org> On 11/23/2009 06:14 AM, Fr?d?ric Buclin wrote: > Le 23. 11. 09 13:26, David Bala?ic a ?crit : >> That's it. No user action required. >> >> This solution also automatically handles daylight saving time changes. > > This won't work. Your suggestion only works when viewing bugs from a web > browser *and* having JS turned on. Well, it does work for that case, though. And it works for logged-out users, which is nice. > And I'm > pretty sure you still have to store the timezone somewhere to do the > conversion correctly. Yeah, we'd have to store it on the server still, which would probably confuse people. I don't think we can get Olson timezone names (like America/Los_Angeles) from JS. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From justdave at bugzilla.org Tue Nov 24 07:19:42 2009 From: justdave at bugzilla.org (David Miller) Date: Tue, 24 Nov 2009 02:19:42 -0500 Subject: Simplified users Timezone handling In-Reply-To: <4B0B2AB2.3090004@bugzilla.org> References: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> <4B0A98C0.3070907@gmail.com> <4B0B2AB2.3090004@bugzilla.org> Message-ID: <4B0B890E.3060608@bugzilla.org> Max Kanat-Alexander wrote on 11/23/09 7:37 PM: > Yeah, we'd have to store it on the server still, which would probably > confuse people. I don't think we can get Olson timezone names (like > America/Los_Angeles) from JS. But that's the beauty of it, you wouldn't need to. All the JS cares is the local timezone of the browser that's accessing it. The only reason the server needs to know is the fallback timezone to use for the noscript block. The JS block he gave asks the browser to use its own timezone in the conversion. -- 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 mkanat at bugzilla.org Tue Nov 24 09:50:13 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 24 Nov 2009 01:50:13 -0800 Subject: Simplified users Timezone handling In-Reply-To: <4B0B890E.3060608@bugzilla.org> References: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> <4B0A98C0.3070907@gmail.com> <4B0B2AB2.3090004@bugzilla.org> <4B0B890E.3060608@bugzilla.org> Message-ID: <4B0BAC55.2020005@bugzilla.org> On 11/23/2009 11:19 PM, David Miller wrote: > Max Kanat-Alexander wrote on 11/23/09 7:37 PM: >> Yeah, we'd have to store it on the server still, which would probably >> confuse people. I don't think we can get Olson timezone names (like >> America/Los_Angeles) from JS. > > But that's the beauty of it, you wouldn't need to. All the JS cares is > the local timezone of the browser that's accessing it. The only reason > the server needs to know is the fallback timezone to use for the > noscript block. The JS block he gave asks the browser to use its own > timezone in the conversion. Yeah, but we still need to know the Olson timezone on the server-side for the various things that can't use JS, like bugmail. We can't just store the last offset the user had when he logged in, because that doesn't account for DST changes or the fact that the user might be traveling. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From xerces9 at gmail.com Tue Nov 24 11:41:19 2009 From: xerces9 at gmail.com (=?UTF-8?Q?David_Bala=C5=BEic?=) Date: Tue, 24 Nov 2009 12:41:19 +0100 Subject: Simplified users Timezone handling In-Reply-To: <4B0BAC55.2020005@bugzilla.org> References: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> <4B0A98C0.3070907@gmail.com> <4B0B2AB2.3090004@bugzilla.org> <4B0B890E.3060608@bugzilla.org> <4B0BAC55.2020005@bugzilla.org> Message-ID: <9948385e0911240341y29025002j5013847feddbff55@mail.gmail.com> 2009/11/24 Max Kanat-Alexander : > ? ? ? ?Yeah, but we still need to know the Olson timezone on the server-side > for the various things that can't use JS, like bugmail. We can't just > store the last offset the user had when he logged in, because that > doesn't account for DST changes or the fact that the user might be > traveling. Yes, the proposal works for the web pages displayed in the users web browser and not for other purposes. About storing the timezone in users preferences for other purposes, I saw on some web forums, that the user registration page uses JS to autodetect the timezone (but the user can still change it, it is a regular drop down list, it is just initialized by JS). Regards, David From mkanat at bugzilla.org Tue Nov 24 12:04:09 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 24 Nov 2009 04:04:09 -0800 Subject: Simplified users Timezone handling In-Reply-To: <9948385e0911240341y29025002j5013847feddbff55@mail.gmail.com> References: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> <4B0A98C0.3070907@gmail.com> <4B0B2AB2.3090004@bugzilla.org> <4B0B890E.3060608@bugzilla.org> <4B0BAC55.2020005@bugzilla.org> <9948385e0911240341y29025002j5013847feddbff55@mail.gmail.com> Message-ID: <4B0BCBB9.6090500@bugzilla.org> On 11/24/2009 03:41 AM, David Bala?ic wrote: > About storing the timezone in users preferences for other purposes, I saw on > some web forums, that the user registration page uses JS to autodetect > the timezone (but the user can still change it, it is a regular drop down list, > it is just initialized by JS). Yeah, that's kind of what I was saying--I don't know how to reliably translate the JS timezone into an Olson timezone. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From justdave at bugzilla.org Tue Nov 24 20:52:16 2009 From: justdave at bugzilla.org (David Miller) Date: Tue, 24 Nov 2009 15:52:16 -0500 Subject: Simplified users Timezone handling In-Reply-To: <4B0BCBB9.6090500@bugzilla.org> References: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> <4B0A98C0.3070907@gmail.com> <4B0B2AB2.3090004@bugzilla.org> <4B0B890E.3060608@bugzilla.org> <4B0BAC55.2020005@bugzilla.org> <9948385e0911240341y29025002j5013847feddbff55@mail.gmail.com> <4B0BCBB9.6090500@bugzilla.org> Message-ID: <4B0C4780.8010301@bugzilla.org> Max Kanat-Alexander wrote on 11/24/09 7:04 AM: > On 11/24/2009 03:41 AM, David Bala?ic wrote: >> About storing the timezone in users preferences for other purposes, I saw on >> some web forums, that the user registration page uses JS to autodetect >> the timezone (but the user can still change it, it is a regular drop down list, >> it is just initialized by JS). > > Yeah, that's kind of what I was saying--I don't know how to reliably > translate the JS timezone into an Olson timezone. Include the TZ offset in the dropdown select in parentheses after the TZ name. Sort the select box by the TZ offset. Autoselect the first one that matches. Let the user change it to one of the ones right after if it was the wrong one. -- 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 mkanat at bugzilla.org Wed Nov 25 01:44:24 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 24 Nov 2009 17:44:24 -0800 Subject: Simplified users Timezone handling In-Reply-To: <4B0C4780.8010301@bugzilla.org> References: <9948385e0911230426q1892ca20k332ba64d8024c2c7@mail.gmail.com> <4B0A98C0.3070907@gmail.com> <4B0B2AB2.3090004@bugzilla.org> <4B0B890E.3060608@bugzilla.org> <4B0BAC55.2020005@bugzilla.org> <9948385e0911240341y29025002j5013847feddbff55@mail.gmail.com> <4B0BCBB9.6090500@bugzilla.org> <4B0C4780.8010301@bugzilla.org> Message-ID: <4B0C8BF8.2000800@bugzilla.org> On 11/24/2009 12:52 PM, David Miller wrote: > Include the TZ offset in the dropdown select in parentheses after the TZ > name. Sort the select box by the TZ offset. Autoselect the first one > that matches. Let the user change it to one of the ones right after if > it was the wrong one. Yeah, that would work. We wouldn't even need JS for that, if the user's browser sends any header containing a time with a timestamp. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Nov 25 07:55:30 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 24 Nov 2009 23:55:30 -0800 Subject: Soft Serve Message-ID: <4B0CE2F2.808@bugzilla.org> We're soft frozen for Bugzilla 3.6. That means that if you have a patch going through the review process right now, you have exactly two weeks to get it in to Bugzilla if you want it to be part of Bugzilla 3.6. Enhancements without patches on them currently will not be accepted for Bugzilla 3.6, as of now. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Nov 25 10:53:56 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 25 Nov 2009 02:53:56 -0800 Subject: The new Bugzilla::Extension system Message-ID: <4B0D0CC4.7030406@bugzilla.org> I spent the last several days re-writing Bugzilla's extensions system. The old system suffered from a few problems, many of which I encountered personally while writing several large extensions: * Template hooks went in a strange location that was partially inexplicable from looking at the code. (Did they go in template/en/hook, or template/en/default/hook, or template/en/extension, or what?) * Code was in individual .pl files that had to be compiled every time they were run, and couldn't really have subroutines in them (because Bugzilla would complain you were redefining the subroutine if the hook was called more than once in the same request). There were other things that were strange about them, but those were the two big points. The new system is pretty neat. It's mostly documented in the POD of the new Bugzilla::Extension module: Here are some of the highlights: * Extensions are a directory which contain templates, libraries, and two special files: Config.pm and Extension.pm. Config.pm contains information about the extension's requirements. Extension.pm contains all the code hooks the extension implements, as subroutines. * Extensions can also be all in one file, so you could just have extensions/Foo.pm for an extension named "Foo" that does nothing but add code hooks. * The Extension module is named like Bugzilla::Extension::Foo, where "Foo" is the "name" of the extension. * An extension loads its libraries like Bugzilla::Extension::Foo::Bar. The extensions system magically maps that to extensions/Foo/lib/Bar.pm, with no extra effort required by the extension developer. Once the Bugzilla::Extension::Foo package is loaded, *any* part of Bugzilla can load Bugzilla::Extension::Foo::Bar directly, if it wants to, just like "use Bugzilla::Extension::Foo::Bar;". This means, also, that these libraries could be installed globally in Perl (as Bugzilla/Extension/Foo/Bar.pm in /usr/lib/perl5/) and still be loaded properly. Note that the old magic @INC behavior of extensions is gone--they *must* name their packages like Bugzilla::Extension::Foo::Bar. (This is much better than the strange mix of Foo::Bar and extensions::foo::lib::Bar that we had before.) * Template hooks now live in template/en/default/hook, both in an extensions directory (extensions/Foo/template/en/default/hook), and in the base Bugzilla template directory. Templates in extensions (including hooks) are now precompiled by checksetup.pl. Additionally, template hooks are cached by Bugzilla the first time they're run, so running them over and over should just just as fast as (or faster than) processing a normal template. * For new extension authors, there is a script called extensions/create.pl. You just give it a name of a new extension, as a single argument, and it creates a whole default layout for an extension in the extensions// directory. * There is support for loading extensions that are not installed in the extensions/ directory at all, but are installed globally in Perl instead. This means that extensions could be packaged and distributed via CPAN, and various code has already been written to make this possible in Bugzilla itself (though no code has yet been written to make it easy to make an extension into a CPAN package--this is something that could still be done). * Under mod_perl, extension code will be compiled exactly once, when the web server starts up. This should make extensions lightning-fast under mod_perl. (It does mean that to add new extensions, a server restart is required, though.) * To help people who have already written extensions, there is a file, contrib/extension-convert.pl, which will do a lot of the work of converting your extension from the pre-3.6 format to the 3.6 format. I think extensions should generally be a lot better now, and should only be getting even better in the future. :-) Please let me know if you encounter any problems with the new system, or have any suggestions about it! I'd love to hear from extension authors about their thoughts on it, particularly if it's after working with it. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Thu Nov 26 14:19:59 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 26 Nov 2009 14:19:59 +0000 Subject: Fwd: REST APIs, and Tags Message-ID: Here are David Ascher's thoughts on tagging and Bugzilla usability, which I thought might be good food for thought. (He gave them to me in the context of the REST API.) I definitely think that over the ten+ years of Bugzilla's life, we've had about five goes at the "tag" thing (status whiteboard, keywords, flags, saved searches, and now the tag system in the footer) and each time we've missed the simplicity and ease of what seems to have evolved as the standard way to set and search for tags (a freeform, comma-separated list anyone can search on a la Flickr and del.icio.us). keywords are too bondage-and-discipline and centrally controlled, the whiteboard is too freeform and is a (slower) text search, and the footer tag system seems really complicated in its UI and hard to share with others. It would be great to start a discussion on our future plans for this sort of thing. For example, can we merge keywords and what we now call tags into one tag implementation (incorporating both public and private tags) which has these desirable properties? Gerv -------- Original Message -------- Subject: REST APIs, and Tags Date: Thu, 02 Jul 2009 15:17:56 -0700 From: David Ascher To: Gervase Markham CC: Mark Surman , Dan Mosedale , Aza Raskin In both of these areas, I think that Flickr has set a role model that's worthy of emulation: http://www.flickr.com/services/api/ (with some humor even: http://www.flickr.com/services/api/misc.encoding.html) see e.g. http://www.flickr.com/services/api/flickr.favorites.add.html and the explorer tool: http://www.flickr.com/services/api/explore/?method=flickr.favorites.add The key bits here is that by looking at these pages, people can understand the API model for flickr w/o having to dig any deeper. The RESTful thing makes it easier to approach than an RPC-model, easier to see how it could scale, etc. --- On tags, the usual challenge is how to give people structure (e.g. official milestones, operating systems) that is needed for aggregation queries ('show me all mac blockers'), while decentralizing the locus of that structure, so that different groups can come up with different structures. It's also critical to distinguish the structure-by-convention from the structure-imposed-by-the-database. In particular, one could argue that bugzilla should just have one "tags" field for a bug, but let different bits of the UI rely on different "schemas" for tags. You asked for problems w/ the current scheme: 1) there's no rationale for whether something goes in the status whiteboard or a keyword, except that keywords are tightly controlled and some bizarre, frozen-in-time list which which mostly doesn't change because it applies to _all products_, and status whiteboard is freeform-but-laden-with-conventions. 2) user tags are too hard to share, hence pointless IMO -- tags worked in flickr and delicious because they became fast and easy ways to share sets of URIs. In Bugzilla, it's the horrible thing called a saved search, which is way, way too hard to work with, and requires that people be logged in for no good reasons. If I could just post http://bugs.mozilla.org/bugs/davidascher/tags/tb3+student_project to the world, i'd be much happier. I can imagine a version of bugzilla with a tags field which on disk looked like one big json blob which encoded components, products, milestones, keywords, status whiteboard. (per-user tags probably don't belong on the same table). A lot of the current _structure_ of each bug is not particularly useful per se, and could be implemented with rss/atom feeds on tag-based searches. Let me give an example -- in a previous version of the ActiveState bugzilla DB, we "suffered" from the problem that each product team had a different culture, a different way of dealing w/ QA, regressions, bug triaging, etc. The Komodo team wanted to use "tags" like "on-radar", "off-radar", but the Perl team didn't. Bugzilla didn't allow for the right kind of per-product separation, so we put those distinctions strictly in the UI, and from the DB's point of view we just used the status whiteboard field. -david _______________________________________________ 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 Thu Nov 26 14:42:30 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 26 Nov 2009 06:42:30 -0800 Subject: Fwd: REST APIs, and Tags In-Reply-To: References: Message-ID: <4B0E93D6.9060108@bugzilla.org> On 11/26/2009 06:19 AM, Gervase Markham wrote: > It would be great to start a discussion on our future plans for this > sort of thing. Actually, we'd be mostly continuing an old discussion, one that at least *I* think has actually been resolved, we just don't have anybody to implement the resolution. > For example, can we merge keywords and what we now call > tags into one tag implementation (incorporating both public and private > tags) which has these desirable properties? That's basically the resolution. :-) Except they won't be one implementation, they will just look similar or identical in the UI. For example, we call Keywords "global tags" and we call our current tags "personal tags" and we just style them differently in a list of tags. The reason for the separation of personal and global tags (which doesn't exist in most web apps) is that the structure of global tags is necessary for something like a bug-tracker, which has strict data conformity and management requirements (whereas something like Flickr is not used in that sort of circumstance). Some (or all) of this redesign is this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=372023 You don't have to pay attention to the blockers if you don't want to. The keynote of that bug is "make tagging good". An additional component to this would be adding the ability to share searches publicly, so that one could share one's personal tags publicly. There might already be a bug filed for that, but I'm not sure. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Fri Nov 27 10:32:53 2009 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 27 Nov 2009 10:32:53 +0000 Subject: Fwd: REST APIs, and Tags In-Reply-To: References: Message-ID: <4B0FAAD5.1030003@mozilla.org> On 26/11/09 14:42, Max Kanat-Alexander wrote: > Actually, we'd be mostly continuing an old discussion, one that at > least *I* think has actually been resolved, we just don't have anybody > to implement the resolution. OK :-) > >> For example, can we merge keywords and what we now call >> tags into one tag implementation (incorporating both public and private >> tags) which has these desirable properties? > > That's basically the resolution. :-) Except they won't be one > implementation, they will just look similar or identical in the UI. For > example, we call Keywords "global tags" and we call our current tags > "personal tags" and we just style them differently in a list of tags. But one of the problems with keywords is the frozen-in-time-list thing that David Ascher proposed. Under this new plan, would keywords get unrestricted? I agree it's good to have two classes of tags, because we need "tags that show up when other people view the bug" and "tags which don't". Because if we don't make that split, bugs will start growing enormous lists of tags, and people will be disincentivised from adding new ones to help them track stuff the way they want to. So I'm all for "global tags" and "personal tags". But other than that difference, they should work identically. Because any difference is going to cause confusion. In particular, if I search for "tag=wibble", then it should show me all bugs with either the personal or the global tag "wibble". Search should not care about the distinction. And yes, it should be possible for someone else to do that search too. tag=wibble&taguser=gerv at mozilla.org, or some better UI. So that searches can be shared by just sending or posting a URL, without needing any complicated internal Bugzilla system. > https://bugzilla.mozilla.org/show_bug.cgi?id=372023 Great :-) > An additional component to this would be adding the ability to share > searches publicly, so that one could share one's personal tags publicly. > There might already be a bug filed for that, but I'm not sure. Why do the idea of "tags" and the idea of "saved search" have to be connected? I've never understood that. How are the currently connected, and what was the rationale? 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 Nov 27 13:07:24 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 27 Nov 2009 05:07:24 -0800 Subject: Fwd: REST APIs, and Tags In-Reply-To: <4B0FAAD5.1030003@mozilla.org> References: <4B0FAAD5.1030003@mozilla.org> Message-ID: <4B0FCF0C.8010803@bugzilla.org> On 11/27/2009 02:32 AM, Gervase Markham wrote: > But one of the problems with keywords is the frozen-in-time-list thing > that David Ascher proposed. Under this new plan, would keywords get > unrestricted? I'm not sure that they would. Remember, right now you could make "editbugs" a member of "editkeywords" if you wanted. Why don't you? (The answer to that question has nearly the same answer as "why not let everybody make global tags?") This is open for debate, but it's something that I'd want more data from a broad set of organizations on before we really go and make a (for us) radical decision about it. I'd also be interested to know if other trackers have implemented a tag system, and what the developers of those systems think about whether or not their implementation was successful. > Because if we don't make that split, bugs will start growing enormous > lists of tags, and people will be disincentivised from adding new ones > to help them track stuff the way they want to. Mmm, I'm not entirely sure that's the case. Everybody can edit the status whiteboard now, and bugs don't have tremendous numbers of tags in the Whiteboard. Of course, right now only a small number of people actually put tags in the status whiteboard, so it may not be the same once we have a field actually called "tags". > In particular, if I search for "tag=wibble", then it should show me all > bugs with either the personal or the global tag "wibble". Search should > not care about the distinction. It won't, but that doesn't require all personal tags to be publicly visible. > And yes, it should be possible for someone else to do that search too. > tag=wibble&taguser=gerv at mozilla.org, or some better UI. So that searches > can be shared by just sending or posting a URL, without needing any > complicated internal Bugzilla system. That's accomplished most easily, with the present system, by allowing Bugzilla to have public shared searches. > Why do the idea of "tags" and the idea of "saved search" have to be > connected? I've never understood that. How are the currently connected, > and what was the rationale? They don't have to be connected. I think that it was just convenient to piggyback tags on to Saved Searches, because they essentially do the same thing, in a way--they list bugs. It would be more database-like to store a many-to-many mapping of a bug_id and tag_id column for each tag instead, but shared searches give us footer listing, sharing with a limited group, etc. for free. I don't think the backend matters as much as the UI, for this. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Sun Nov 29 19:32:03 2009 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sun, 29 Nov 2009 20:32:03 +0100 Subject: Fwd: REST APIs, and Tags In-Reply-To: <4B0FCF0C.8010803@bugzilla.org> References: <4B0FAAD5.1030003@mozilla.org> <4B0FCF0C.8010803@bugzilla.org> Message-ID: <4B12CC33.3030007@gmail.com> Le 27. 11. 09 14:07, Max Kanat-Alexander a ?crit : > I'm not sure that they would. Remember, right now you could make > "editbugs" a member of "editkeywords" if you wanted. Why don't you? (The > answer to that question has nearly the same answer as "why not let > everybody make global tags?") If everybody could add global keywords, then it wouldn't make sense to separate keywords and the status whiteboard anymore. The reason we don't let everybody edit keywords is that it would be much more difficult to search for bugs based on them. >> And yes, it should be possible for someone else to do that search too. >> tag=wibble&taguser=gerv at mozilla.org, or some better UI. So that searches >> can be shared by just sending or posting a URL, without needing any >> complicated internal Bugzilla system. Oh, this violates privacy. Other people should only be allowed to query for personal things you agree to share, which is what we are doing currently with shared searches. I wouldn't want people to know which tags I'm using for such or such bugs without my consent. > They don't have to be connected. I think that it was just convenient to > piggyback tags on to Saved Searches, because they essentially do the > same thing, in a way--they list bugs. Yes, that's the exact reason why I implemented tags this way. LpSolit