From justdave at bugzilla.org Sun Jan 3 08:09:54 2010 From: justdave at bugzilla.org (David Miller) Date: Sun, 03 Jan 2010 03:09:54 -0500 Subject: Raindrop, mailing lists and Majordomo In-Reply-To: References: Message-ID: <4B4050D2.1010203@bugzilla.org> Gervase Markham wrote on 11/20/09 5:27 AM: > 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? It wasn't... it is now. I put it in the global default config, so it applies to every list on bugzilla.org now. -- 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 Jan 4 09:24:51 2010 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 04 Jan 2010 09:24:51 +0000 Subject: Raindrop, mailing lists and Majordomo In-Reply-To: References: Message-ID: On 03/01/10 08:09, David Miller wrote: > It wasn't... it is now. I put it in the global default config, so it > applies to every list on bugzilla.org now. Great! :-) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Wed Jan 6 23:06:54 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 07 Jan 2010 00:06:54 +0100 Subject: Bugzilla meeting next Tuesday, January 12 2010 Message-ID: <4B45178E.9030808@gmail.com> Hi all, And happy New Year to all of you! :) Our next Bugzilla meeting will take place next Tuesday, January 12 2010, at 11:00 PST (19:00 GMT, 20:00 CET) in the #bugzilla-meeting IRC channel, as usual (irc://irc.mozilla.org/bugzilla-meeting). The agenda is available here: https://wiki.mozilla.org/Bugzilla:Meetings Feel free to add new items to it. Everyone is free to attend. See you next week, LpSolit From gerv at mozilla.org Mon Jan 11 17:30:12 2010 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 11 Jan 2010 17:30:12 +0000 Subject: Bug Relationships Message-ID: [I've had this idea kicking around in my head for a while, but I don't think I've ever written it up properly for discussion. So here it is. It's inspired by a feature on a proprietary bug tracking system I used to use. It was generally terrible, but this was good.] I think that we should replace dependencies, See Also, and perhaps duplicate marking too with a more generic system of Bug Relationships. It would work like this: an admin would define a number of relationships there could be between bugs. (Some common ones would ship by default.) E.g. A depends on B C caused regression D E is the upstream of F G is a duplicate of H And, of course, the reciprocal language for each relationship would also be defined, if different: B blocks A D is a regression from C F is the downstream of E H is a duplicate of G Then, you would have UI on a bug like this: This bug [ blocks |V] [ ] where you would select a relationship, and then enter a bug number or a URL to a bug in another bug system (Bugzilla or otherwise) in the text box. (Or a comma/space separated list.) If you entered a bug number in the same Bugzilla (and even maybe, one day, with APIs, in other systems), the other bug would display the reciprocal relationship. This has several advantages: * It allows sites to codify things like "bug A is a regression from bug B" rather than what e.g. b.m.o does now, which is have a "regression" keyword, and then perhaps abuse dependencies. This might allow the gathering of stats showing things like "ooh, look, 50% of our regressions come from bugs fixed by Fred". * It simplifies the UI on the bug page. Instead of UI for depends, blocks and See Also, plus any custom fields a site might add (remember, Bug ID is a custom field type), we just have the above selector, plus editable details of existing relationships (which in many cases, will be none, so the common case is simpler). * It allows one to be more specific than "See Also", where each user has to load up the bugs in the list and work out what the relationship is and whether it's relevant to them. More useful semantic information is captured. So as I see it, it's a generalization which brings more power and makes things simpler, without losing any functionality. What do people think? 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 Jan 11 21:12:55 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 11 Jan 2010 13:12:55 -0800 Subject: Minimum Bzr Version Message-ID: <4B4B9457.5060906@bugzilla.org> Hey folks. So the bzr repository is almost ready (yay)! :-) There's one question that we want to pose to the group, though, before we start the migration process: What's the highest-acceptable minimum version of bzr for you? Here's why this is a question: As bzr has evolved, they have developed better and better in-disk formats for the repositories. In 0.92 (a very old version), they standardized on a format called "pack" as the default. It's nice, but there are *significant* speed advantages to the more modern formats, which are numbered along with the versions in which they were introduced: 1.9, 1.14, and 2.0. (The only difference is in speed--the functionality of bzr is identical with each format.) 2.0 is definitely the best--it shows really large differences for checking out, branching, committing, doing a diff, log, etc.--almost all the common commands, and it makes a real difference in everyday usage, in my experience. The only problem is that 2.0 is really new (September 21, 2009). It doesn't have any newer or different Python requirements than older versions, though, so any system that can run any older version can run the new version--it just might not be available from your standard package repository. So what LpSolit proposed (and I think is a good idea) is that we say this: If you want to commit to bzr, you should install 2.0. If you can't install 2.0, we will continue to mirror bzr back to CVS, and you can use CVS to do read-only access to the Bugzilla code base. Does that sound good to everybody, or would you rather require an older bzr version at the expense of some performance? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mockodin at gmail.com Mon Jan 11 21:16:50 2010 From: mockodin at gmail.com (Michael Thomas) Date: Mon, 11 Jan 2010 13:16:50 -0800 Subject: Minimum Bzr Version In-Reply-To: <4B4B9457.5060906@bugzilla.org> References: <4B4B9457.5060906@bugzilla.org> Message-ID: <6b9407351001111316l7676a9eaka4eea6e8d6bc6763@mail.gmail.com> Will adopt/utilize any version required. Windows being windows I'm running easy mode for such. Feature/Performance wise I would lean toward the latest-and-greatest -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steve.Roscio at hp.com Mon Jan 11 21:25:30 2010 From: Steve.Roscio at hp.com (Roscio, Steve) Date: Mon, 11 Jan 2010 21:25:30 +0000 Subject: Bug Relationships In-Reply-To: References: Message-ID: <81DC3A589F7C274A9D3D960BBD0F0B0C322CA684FE@GVW0670EXC.americas.hpqcorp.net> I think this is a good idea. We use Bugzilla to hold our requirements, user stories, sprint tasks, etc in addition to the bug-side of things. I could see this used to indicate which tasks are derived from what stories/requirements, and so on. Right now we just use "depends" and then add extra keywords to tag what things are. For regressions, we don't use 'depends'/'blocks' because it breaks the other kind of dependencies we do. So this idea -- typed dependencies -- would be useful to my team. FWIW. - Steve -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: Monday, January 11, 2010 10:30 AM To: dev-apps-bugzilla at lists.mozilla.org Subject: Bug Relationships [I've had this idea kicking around in my head for a while, but I don't think I've ever written it up properly for discussion. So here it is. It's inspired by a feature on a proprietary bug tracking system I used to use. It was generally terrible, but this was good.] I think that we should replace dependencies, See Also, and perhaps duplicate marking too with a more generic system of Bug Relationships. It would work like this: an admin would define a number of relationships there could be between bugs. (Some common ones would ship by default.) E.g. A depends on B C caused regression D E is the upstream of F G is a duplicate of H And, of course, the reciprocal language for each relationship would also be defined, if different: B blocks A D is a regression from C F is the downstream of E H is a duplicate of G Then, you would have UI on a bug like this: This bug [ blocks |V] [ ] where you would select a relationship, and then enter a bug number or a URL to a bug in another bug system (Bugzilla or otherwise) in the text box. (Or a comma/space separated list.) If you entered a bug number in the same Bugzilla (and even maybe, one day, with APIs, in other systems), the other bug would display the reciprocal relationship. This has several advantages: * It allows sites to codify things like "bug A is a regression from bug B" rather than what e.g. b.m.o does now, which is have a "regression" keyword, and then perhaps abuse dependencies. This might allow the gathering of stats showing things like "ooh, look, 50% of our regressions come from bugs fixed by Fred". * It simplifies the UI on the bug page. Instead of UI for depends, blocks and See Also, plus any custom fields a site might add (remember, Bug ID is a custom field type), we just have the above selector, plus editable details of existing relationships (which in many cases, will be none, so the common case is simpler). * It allows one to be more specific than "See Also", where each user has to load up the bugs in the list and work out what the relationship is and whether it's relevant to them. More useful semantic information is captured. So as I see it, it's a generalization which brings more power and makes things simpler, without losing any functionality. What do people think? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla - To view or change your list settings, click here: From mkanat at bugzilla.org Mon Jan 11 21:29:24 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 11 Jan 2010 13:29:24 -0800 Subject: Bug Relationships In-Reply-To: References: Message-ID: <4B4B9834.60805@bugzilla.org> On 01/11/2010 09:30 AM, Gervase Markham wrote: > I think that we should replace dependencies, See Also, and perhaps > duplicate marking too with a more generic system of Bug Relationships. Hey Gerv. We've discussed this a fair bit within a few bugs. I agree that dependson and blocks should become default implementations of a generic system for creating fields like that, which is described here: https://bugzilla.mozilla.org/show_bug.cgi?id=251556 The future functionality of See Also mostly excludes it from being usefully included in that generic system for now, though. ( https://bugzilla.mozilla.org/show_bug.cgi?id=bz-seealso ) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mattr at kde.org Mon Jan 11 21:31:46 2010 From: mattr at kde.org (Matt Rogers) Date: Mon, 11 Jan 2010 15:31:46 -0600 Subject: Minimum Bzr Version In-Reply-To: <4B4B9457.5060906@bugzilla.org> References: <4B4B9457.5060906@bugzilla.org> Message-ID: <201001111531.46145.mattr@kde.org> On Monday 11 January 2010 15:12:55 you wrote: > Hey folks. So the bzr repository is almost ready (yay)! :-) > > There's one question that we want to pose to the group, though, before > we start the migration process: What's the highest-acceptable minimum > version of bzr for you? > > Here's why this is a question: > > As bzr has evolved, they have developed better and better in-disk > formats for the repositories. In 0.92 (a very old version), they > standardized on a format called "pack" as the default. It's nice, but > there are *significant* speed advantages to the more modern formats, > which are numbered along with the versions in which they were > introduced: 1.9, 1.14, and 2.0. (The only difference is in speed--the > functionality of bzr is identical with each format.) > > 2.0 is definitely the best--it shows really large differences for > checking out, branching, committing, doing a diff, log, etc.--almost all > the common commands, and it makes a real difference in everyday usage, > in my experience. > > The only problem is that 2.0 is really new (September 21, 2009). It > doesn't have any newer or different Python requirements than older > versions, though, so any system that can run any older version can run > the new version--it just might not be available from your standard > package repository. > > So what LpSolit proposed (and I think is a good idea) is that we say > this: If you want to commit to bzr, you should install 2.0. If you can't > install 2.0, we will continue to mirror bzr back to CVS, and you can use > CVS to do read-only access to the Bugzilla code base. > > Does that sound good to everybody, or would you rather require an older > bzr version at the expense of some performance? > > -Max > Whatever gives us as developers the best performance is what we should go for, IMHO. -- Matt From michael.j.tosh at lmco.com Mon Jan 11 22:12:15 2010 From: michael.j.tosh at lmco.com (Tosh, Michael J) Date: Mon, 11 Jan 2010 17:12:15 -0500 Subject: Bug Relationships In-Reply-To: References: Message-ID: <8A06826F0DE9AD4087CEBD52E769C0DC13110CD4@HVXMSPB.us.lmco.com> Gervase Markham wrote: > It would work like this: an admin would define a number of relationships > there could be between bugs. (Some common ones would ship by default.) E.g. > > A depends on B > C caused regression D > E is the upstream of F > G is a duplicate of H BRILLIANT! Our Program Managers would LOVE this functionality. Off to discuss adding to our 3.0 version now... _______________________________________________ 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 Jan 11 23:58:22 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 11 Jan 2010 15:58:22 -0800 Subject: Bzr Commit Message Format Message-ID: <4B4BBB1E.7030901@bugzilla.org> Hey folks. So, bzr has a lot of features that CVS doesn't, one of which is that it supports a lot more information about commits. In particular it supports directly storing data about: 1) Which bug was fixed by this commit (--fixes 1234) 2) Who authored this commit, if it was different from the committer (--author awesome.contributor at example.com). So it seems like we should change the format of our commit messages. I'm not quite sure how we should do that, though. I was thinking maybe just a brief summary of the change and then the r= stuff on the same line? Or the r= stuff on the next line? What do you guys think? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Tue Jan 12 00:19:50 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 12 Jan 2010 01:19:50 +0100 Subject: Bzr Commit Message Format In-Reply-To: <4B4BBB1E.7030901@bugzilla.org> References: <4B4BBB1E.7030901@bugzilla.org> Message-ID: <4B4BC026.1040709@gmail.com> Le 12. 01. 10 00:58, Max Kanat-Alexander a ?crit : > So it seems like we should change the format of our commit messages. > I'm not quite sure how we should do that, though. I was thinking maybe > just a brief summary of the change and then the r= stuff on the same > line? Or the r= stuff on the next line? What do you guys think? Why not just use what we currently use for CVS? Bug 123456: Crash when hitting Ctrl+P - Patch by Foo Bar r=reviewer a=approver I know the "Patch by Foo Bar " part is mostly obsoleted by the --author argument, but I would like tooltips in the annotated file to contain this whole information as it makes tracking bugs much easier. So the current tooltips in Loggerhead would need to be hacked to reflect that (keeping what we currently have in Bonsai would be great). LpSolit From mkanat at bugzilla.org Tue Jan 12 00:48:53 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 11 Jan 2010 16:48:53 -0800 Subject: Bzr Commit Message Format In-Reply-To: <4B4BC026.1040709@gmail.com> References: <4B4BBB1E.7030901@bugzilla.org> <4B4BC026.1040709@gmail.com> Message-ID: <4B4BC6F5.7060301@bugzilla.org> On 01/11/2010 04:19 PM, Fr?d?ric Buclin wrote: > I know the "Patch by Foo Bar " part is mostly obsoleted > by the --author argument, but I would like tooltips in the annotated > file to contain this whole information as it makes tracking bugs much > easier. So the current tooltips in Loggerhead would need to be hacked to > reflect that (keeping what we currently have in Bonsai would be great). Yeah, I'd like the tooltips to be better too. I think the nice part about not putting people's email addresses into the commit message is that it doesn't expose people's email addresses without filtering. I don't know if loggerhead does filtering on "author" and "committer", but it *could*, whereas it probably doesn't for commit messages. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From olivier.berger at it-sudparis.eu Tue Jan 12 09:43:39 2010 From: olivier.berger at it-sudparis.eu (Olivier Berger) Date: Tue, 12 Jan 2010 10:43:39 +0100 Subject: Bug Relationships In-Reply-To: References: Message-ID: <1263289419.20973.6.camel@inf-8657.int-evry.fr> Hi. Le lundi 11 janvier 2010 ? 17:30 +0000, Gervase Markham a ?crit : > [I've had this idea kicking around in my head for a while, but I don't > think I've ever written it up properly for discussion. So here it is. > It's inspired by a feature on a proprietary bug tracking system I used > to use. It was generally terrible, but this was good.] > > I think that we should replace dependencies, See Also, and perhaps > duplicate marking too with a more generic system of Bug Relationships. > That'd be great. I'd advise you to have a look at what's cooking for OSLC-CM [0] V2 [1] attributes definition in order to eventually adopt the same wording as what will be defined for the next version of that standard. Of course this would be in prevision of the day when bugzilla becomes compatible with OSLC-CM : https://bugzilla.mozilla.org/show_bug.cgi?id=519177 My 2 cents, [0] : http://open-services.net/bin/view/Main/CmHome [1] : http://open-services.net/bin/view/Main/CmResourceDefinitionsV2 -- 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 gerv at mozilla.org Tue Jan 12 11:04:08 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 12 Jan 2010 11:04:08 +0000 Subject: Minimum Bzr Version In-Reply-To: References: Message-ID: On 11/01/10 21:12, Max Kanat-Alexander wrote: > Does that sound good to everybody, or would you rather require an older > bzr version at the expense of some performance? The Bugzilla tree, as trees go, is pretty tiny, isn't it? Will the worse performance characteristics of the older versions really affect us significantly? I mean, a really active Bugzilla developer might check out once a day, create a branch once a week, commit three times, do a dozen diffs. The time increase has to be traded off against the time needed to install a new version of bzr. If you are on Windows, of course, it doesn't matter too much - you need to install one whatever. But if you are on a more sane platform, you might have one packaged by your OS developer, and would prefer to stick with it. If diffs take 0.5 seconds longer and committing 2 seconds longer on the old versions, I would suggest the advantage doesn't outweigh the need to get everyone to install a new version of bzr. My OS, Ubuntu 9.10 comes with bzr 2.0.0. What do other major platforms come with in their repos? 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 Jan 12 11:06:28 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 12 Jan 2010 11:06:28 +0000 Subject: Bzr Commit Message Format In-Reply-To: References: <4B4BBB1E.7030901@bugzilla.org> <4B4BC026.1040709@gmail.com> Message-ID: On 12/01/10 00:48, Max Kanat-Alexander wrote: > Yeah, I'd like the tooltips to be better too. I think the nice part > about not putting people's email addresses into the commit message is > that it doesn't expose people's email addresses without filtering. Are people still trying to fight spam by keeping their email address from the spammers? I know I gave that up as a lost cause long ago. The utility of being able to just put my address anywhere without worrying about it, and people being able to contact me easily, definitely outweighs the small disadvantage of a bit of spam which requires me to press the J key in Thunderbird (I have good filters, so I only get a little bit). 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 Jan 12 11:09:13 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 12 Jan 2010 11:09:13 +0000 Subject: Bug Relationships In-Reply-To: References: Message-ID: On 11/01/10 21:29, Max Kanat-Alexander wrote: > Hey Gerv. We've discussed this a fair bit within a few bugs. I agree > that dependson and blocks should become default implementations of a > generic system for creating fields like that, which is described here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=251556 Super :-) > The future functionality of See Also mostly excludes it from being > usefully included in that generic system for now, though. ( > https://bugzilla.mozilla.org/show_bug.cgi?id=bz-seealso ) You are going to need to spell out for me why that is. To put the question another way: if I can mark b.m.o. bug 123 as "depends on" b.m.o. bug 456, why should I not be able to mark it as "depends on" bugzilla.gnome.org bug 789? In other words, why can the functionality you want to add to See Also, such as getting information from the remote bug system and displaying it, not become part of the generic implementation? 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 Jan 12 11:23:07 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 12 Jan 2010 11:23:07 +0000 Subject: Bug Relationships In-Reply-To: References: Message-ID: On 12/01/10 09:43, Olivier Berger wrote: > I'd advise you to have a look at what's cooking for OSLC-CM [0] V2 [1] > attributes definition in order to eventually adopt the same wording as > what will be defined for the next version of that standard. I think that, realistically, if Bugzilla ever supports OSLC-CM, it will be via export and import functions. So any attribute or data conversion required could be done at that stage. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From eblack at higherone.com Tue Jan 12 14:21:42 2010 From: eblack at higherone.com (Eric Black) Date: Tue, 12 Jan 2010 09:21:42 -0500 Subject: Minimum Bzr Version In-Reply-To: <4B4B9457.5060906@bugzilla.org> References: <4B4B9457.5060906@bugzilla.org> Message-ID: <4F91EB003F5C784084736E717AB5AFCA19FAD6A6E3@mail02.higherone.com> > So what LpSolit proposed (and I think is a good idea) is that we say > this: If you want to commit to bzr, you should install 2.0. If you can't > install 2.0, we will continue to mirror bzr back to CVS, and you can use > CVS to do read-only access to the Bugzilla code base. I'm not a committer to thje repository, but mirroring back to read only cvs sounds like a great idea especially for those that want to upgrade bugzilla from cvs and may never have heard of bzr. If it's not a pain for the maintenance of the repositories, it's a great solution. From fedrushkov at users.sourceforge.net Tue Jan 12 15:03:57 2010 From: fedrushkov at users.sourceforge.net (Vitaly Fedrushkov) Date: Tue, 12 Jan 2010 20:03:57 +0500 Subject: Bug Relationships In-Reply-To: References: Message-ID: <4B4C8F5D.9000003@users.sourceforge.net> On 12.01.2010 16:09, Gervase Markham wrote: > You are going to need to spell out for me why that is. To put the > question another way: if I can mark b.m.o. bug 123 as "depends on" > b.m.o. bug 456, why should I not be able to mark it as "depends on" > bugzilla.gnome.org bug 789? Yes you should be, but it is out of your control to make bugzilla.gnome.org implement relationship 'X blocks Y' as reciprocal to 'Y depends on X on b.m.o', 'Y depends on X on NASA PRACA', etc. Regards, Vitaly. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mattr at kde.org Tue Jan 12 15:15:54 2010 From: mattr at kde.org (Matt Rogers) Date: Tue, 12 Jan 2010 09:15:54 -0600 Subject: Minimum Bzr Version In-Reply-To: References: Message-ID: <201001120915.54693.mattr@kde.org> On Tuesday 12 January 2010 05:04:08 you wrote: > On 11/01/10 21:12, Max Kanat-Alexander wrote: > > Does that sound good to everybody, or would you rather require an older > > bzr version at the expense of some performance? > > The Bugzilla tree, as trees go, is pretty tiny, isn't it? Will the worse > performance characteristics of the older versions really affect us > significantly? I mean, a really active Bugzilla developer might check > out once a day, create a branch once a week, commit three times, do a > dozen diffs. > > The time increase has to be traded off against the time needed to > install a new version of bzr. If you are on Windows, of course, it > doesn't matter too much - you need to install one whatever. But if you > are on a more sane platform, you might have one packaged by your OS > developer, and would prefer to stick with it. If diffs take 0.5 seconds > longer and committing 2 seconds longer on the old versions, I would > suggest the advantage doesn't outweigh the need to get everyone to > install a new version of bzr. > > My OS, Ubuntu 9.10 comes with bzr 2.0.0. What do other major platforms > come with in their repos? > > Gerv SLED 11 (and I would assume openSUSE 11.1) comes with bzr 1.8. Fedora 11 comes with bzr 1.18. Fedora 12 comes with 2.0.3 -- Matt From fedrushkov at users.sourceforge.net Tue Jan 12 15:23:11 2010 From: fedrushkov at users.sourceforge.net (Vitaly Fedrushkov) Date: Tue, 12 Jan 2010 20:23:11 +0500 Subject: Bug Relationships In-Reply-To: References: Message-ID: <4B4C93DF.8020906@users.sourceforge.net> On 11.01.2010 22:30, Gervase Markham wrote: > [I've had this idea kicking around in my head for a while, but I don't > think I've ever written it up properly for discussion. So here it is. > It's inspired by a feature on a proprietary bug tracking system I used > to use. It was generally terrible, but this was good.] > It would work like this: an admin would define a number of relationships > there could be between bugs. (Some common ones would ship by default.) E.g. You forgot to mention: that system is also capable to bind objects of different types, like: Bug A is-reproducible-in Version N Bug A is-reproducible-in Version M Bug A is-fixed-in Version K Version M suffers-from Bug A Version K is-immune-to Bug A > G is a duplicate of H > And, of course, the reciprocal language for each relationship would also > be defined, if different: > H is a duplicate of G Here one should add 'commutative' check box, to search both sides in such relationships. Also, relationships are different in their effects on workflow. Example: B blocks A C documents-changes-introduced-by A both may prevent A from being resolved, while D is-a-root-cause-of A may not. Regards, Vitaly. _______________________________________________ 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 Jan 12 16:19:01 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 12 Jan 2010 17:19:01 +0100 Subject: Minimum Bzr Version In-Reply-To: References: Message-ID: <4B4CA0F5.5070605@gmail.com> Le 12. 01. 10 12:04, Gervase Markham a ?crit : > My OS, Ubuntu 9.10 comes with bzr 2.0.0. What do other major platforms > come with in their repos? Mandriva 2010.0: bzr 2.0.1 From gerv at mozilla.org Thu Jan 14 12:05:09 2010 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 14 Jan 2010 12:05:09 +0000 Subject: Bug Relationships In-Reply-To: <4B4C93DF.8020906@users.sourceforge.net> References: <4B4C93DF.8020906@users.sourceforge.net> Message-ID: On 12/01/10 15:23, Vitaly Fedrushkov wrote: > You forgot to mention: that system is also capable to bind objects of > different types, like: > > Bug A is-reproducible-in Version N Aargh. I smell scope creep :-) > Here one should add 'commutative' check box, to search both sides in > such relationships. That's a good idea. > Also, relationships are different in their effects on workflow. Example: > > B blocks A > C documents-changes-introduced-by A > > both may prevent A from being resolved, while > > D is-a-root-cause-of A > > may not. At the moment, we have an option which says "blockers prevent a bug being resolved". That would probably change to a system where you could identify a particular relationship as having this property. So "blocks" and "documents-changes-introduced-by" would have the property, and "is-a-root-cause-of" would not. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Jan 13 16:37:09 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 13 Jan 2010 16:37:09 +0000 Subject: Bugzilla cookies HTTP only Message-ID: What exactly are the security benefits we get from having our cookies HTTPonly? I ask because I was hoping to allow Greasemonkey scripts/Jetpacks etc. which run in the context of Bugzilla pages to grab the auth cookie and pass it on to the API, which can then use it to access Bugzilla. This obviates the rather irritating and insecure step of having to configure every Jetpack or Greasemonkey script with your Bugzilla username and password. However, having refactored BzAPI for this to work, I now realise the cookies are HTTPonly and I can't get to them :-| The usual threat that HTTPonly is said to protect against is cookie stealing by malicious scripts. 1) It doesn't work, because if they've managed to get code running in your Bugzilla page context, the attacker can just make any requests they want using XMLHttpRequest, and the auth cookies will get sent right along: http://www.gnucitizen.org/blog/why-httponly-wont-protect-you/ 2) Large sites now use a different domain name for attachments anyway. Given the above, should we reconsider the HTTPonly nature of Bugzilla cookies? Or are there attacks it mitigates which I've missed? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Jan 13 15:32:02 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 13 Jan 2010 15:32:02 +0000 Subject: Using URL param auth with XML-RPC interface Message-ID: Is it possible in some way to use the Bugzilla_login and Bugzilla_password URL parameters with the XML-RPC interface, thereby obviating the need to login? If you have to login, it means two requests to get one piece of data, which kills performance. Reading the code suggested there might be, tentative experiments suggest that there isn't. 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 Jan 14 16:32:23 2010 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 14 Jan 2010 16:32:23 +0000 Subject: Including and excluding fields Message-ID: I would like to implement a system in the BzAPI for people to be able to control what fields they get back on objects. Here are some design goals: 1) Generic - works for all object types 2) Robust in the face of future new fields 3) Makes it so the default (no field specifications) is useful Here are my use cases: A) "Give me everything" B) "Give me just these named fields" C) "Give me as much as possible while still being fast" Goal 3) makes me think that each call (e.g. the /bug/ single bug call or the /bug?foo=bar search) would have a set of default fields, which will not be every possible field. That is true today - by default, the single bug call doesn't return comments, attachmentdata or history, and the search call only returns a subset of fields (basically, the single-valued ones, with the exception of URL[0]). It seems that goal 3) and use case C) fit rather well. The default should be "what's fast" - so, for a search, everything in the bugs table, and for a single bug, everything that doesn't have an unbounded size (and so the download time can be O(N)). Use case B) suggests we need a "fields=" parameter which specifies the fields you want. That's fine for goal 1) and goal 2) - adding new fields doesn't affect this. So how do we hit use case A)? If the default is not everything, and you have a "fields" parameter which starts from scratch, you have to know the name of every field, or if it starts from the default, you have to know the name of every non_default field. Which isn't great if someone e.g. adds a new custom field. So we need a special value - "all" - for "fields", and then an exclude_fields option to subtract from that if people want to avoid getting big or slow fields. So my design is: fields= exclude_fields= "exclude_fields" overrides "fields". A field name can be a compound field name, e.g. attachments.data, which is the 'data' member of everything in the 'attachments' array. Algorithm: find data for all default fields, plus all fields in "fields". Throw away data for all fields in "exclude_fields". Note that this is different from the current design for the XML-RPC API, which as an include_fields parameter which, if used, starts from scratch rather than from the default, and doesn't have an "all" parameter. To my mind, that doesn't meet goal 2). But I've made the name of my field adding parameter different to avoid confusion. What's wrong with my design? :-) Gerv [0] https://bugzilla.mozilla.org/show_bug.cgi?id=25275 _______________________________________________ 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 Thu Jan 14 16:53:42 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 14 Jan 2010 17:53:42 +0100 Subject: Bugzilla cookies HTTP only In-Reply-To: References: Message-ID: <4B4F4C16.3010403@gmail.com> Le 13. 01. 10 17:37, Gervase Markham a ?crit : > What exactly are the security benefits we get from having our cookies > HTTPonly? Read bug 368502 From fedrushkov at users.sourceforge.net Fri Jan 15 01:28:57 2010 From: fedrushkov at users.sourceforge.net (Vitaly Fedrushkov) Date: Fri, 15 Jan 2010 06:28:57 +0500 Subject: Bug Relationships In-Reply-To: References: <4B4C93DF.8020906@users.sourceforge.net> Message-ID: <4B4FC4D9.4070809@users.sourceforge.net> On 14.01.2010 17:05, Gervase Markham wrote: >> You forgot to mention: that system is also capable to bind objects of >> different types, like: >> Bug A is-reproducible-in Version N > Aargh. I smell scope creep :-) Don't you like smell of 2-star cognac? https://bugzilla.mozilla.org/show_bug.cgi?id=336790 _______________________________________________ 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 Jan 15 05:22:47 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 14 Jan 2010 21:22:47 -0800 Subject: Using URL param auth with XML-RPC interface In-Reply-To: References: Message-ID: <4B4FFBA7.5070800@bugzilla.org> On 01/13/2010 07:32 AM, Gervase Markham wrote: > Is it possible in some way to use the Bugzilla_login and > Bugzilla_password URL parameters with the XML-RPC interface, thereby > obviating the need to login? If you have to login, it means two requests > to get one piece of data, which kills performance. > > Reading the code suggested there might be, tentative experiments suggest > that there isn't. As of 3.6, you can specify Bugzilla_login and Bugzilla_password as arguments to any WebService method: http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Fri Jan 15 06:09:32 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 14 Jan 2010 22:09:32 -0800 Subject: Including and excluding fields In-Reply-To: References: Message-ID: <4B50069C.6000107@bugzilla.org> On 01/14/2010 08:32 AM, Gervase Markham wrote: > fields= the default and adding> This is a reasonable idea--it does accomplish something I was thinking about, which is including extra fields in addition to the default fields, which I was going to accomplish by an extra_fields argument, in XML-RPC. I tend to prefer not overloading things with two meanings (in this case, "fields" means both "add this" and "keep this")--I think it's a little simpler to just have a separate param. But it might be simpler from an implementation perspective to just have "fields"--I actually don't know. Thinking about some use cases briefly, I suspect that "fields" would be easier for consumers, though I worry that it would be somewhat unclear and confusing when reading API documentation. If you do stick with this, I'd use "_default" instead of "all", though, since I'd interpret all to mean "every single field possible". -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Fri Jan 15 06:11:18 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 14 Jan 2010 22:11:18 -0800 Subject: Including and excluding fields In-Reply-To: <4B50069C.6000107@bugzilla.org> References: <4B50069C.6000107@bugzilla.org> Message-ID: <4B500706.8050505@bugzilla.org> On 01/14/2010 10:09 PM, Max Kanat-Alexander wrote: > If you do stick with this, I'd use "_default" instead of "all", though, > since I'd interpret all to mean "every single field possible". Oh, and you may also want a "_custom", which means "every custom field", for consumers who want only certain built-in fields, but who might not know what custom fields are available and want all of them. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Fri Jan 15 15:09:22 2010 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 15 Jan 2010 15:09:22 +0000 Subject: Bugzilla cookies HTTP only In-Reply-To: References: Message-ID: On 14/01/10 16:53, Fr?d?ric Buclin wrote: > Le 13. 01. 10 17:37, Gervase Markham a ?crit : >> What exactly are the security benefits we get from having our cookies >> HTTPonly? > > Read bug 368502 That bug lists lots of implementation detail, but at no point (that I can see) explains _why_ it actually increases our security. That is the question I am asking. The bug basically goes: - We should do this - Here's a patch - Will it break anything? - No - Here's a fixed patch - Checked in - Will it break this other thing, then? - No, it won't break that either There's no rationale anywhere. 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 Jan 15 21:14:54 2010 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 15 Jan 2010 21:14:54 +0000 Subject: Including and excluding fields In-Reply-To: References: Message-ID: On 15/01/10 06:09, Max Kanat-Alexander wrote: > This is a reasonable idea--it does accomplish something I was thinking > about, which is including extra fields in addition to the default > fields, which I was going to accomplish by an extra_fields argument, in > XML-RPC. I tend to prefer not overloading things with two meanings (in > this case, "fields" means both "add this" and "keep this")--I think it's > a little simpler to just have a separate param. But it might be simpler > from an implementation perspective to just have "fields"--I actually > don't know. It would be good if the result of this discussion was the emergence of a consensus on how to do it, and then both implementations could converge on it (even if XML-RPC had legacy additional capabilities). > Thinking about some use cases briefly, I suspect that "fields" would be > easier for consumers, though I worry that it would be somewhat unclear > and confusing when reading API documentation. You mean the "add these" model would be easier for consumers? > If you do stick with this, I'd use "_default" instead of "all", though, > since I'd interpret all to mean "every single field possible". "all" _does_ mean "every single field possible". Perhaps what I wrote above was unclear. Let me try again: fields=|"all" If the value is a list, then those fields are _added_ to the default set to produce the set returned. If the value is "all", then every possible field is returned. 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 Jan 15 21:24:48 2010 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 15 Jan 2010 21:24:48 +0000 Subject: Including and excluding fields In-Reply-To: References: Message-ID: On 15/01/10 21:14, Gervase Markham wrote: >> If you do stick with this, I'd use "_default" instead of "all", though, >> since I'd interpret all to mean "every single field possible". > > "all" _does_ mean "every single field possible". Perhaps what I wrote > above was unclear. Let me try again: > > fields=|"all" > > If the value is a list, then those fields are _added_ to the default set > to produce the set returned. > > If the value is "all", then every possible field is returned. Oh, hang on. I've just thought this through again and I see what you mean. We actually need: fields= exclude_fields= Either list can contain the special value '_custom' which is an '_all' for custom fields. Algorithm: fields sent = 'fields' - 'exclude_fields'. The default value for 'fields' is, conceptually, '_default'! This scheme allows for small-number-of-named, everything, default-plus-some and default-minus-some. Which covers all use cases. 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 Jan 15 21:28:43 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 15 Jan 2010 13:28:43 -0800 Subject: Including and excluding fields In-Reply-To: References: Message-ID: <4B50DE0B.8010402@bugzilla.org> On 01/15/2010 01:14 PM, Gervase Markham wrote: > It would be good if the result of this discussion was the emergence of a > consensus on how to do it, and then both implementations could converge > on it (even if XML-RPC had legacy additional capabilities). Hmm. Okay, so here's my proposal: We keep include_fields and exclude_fields as the names. To include_fields, we add the following possibilities: _default, _all This is easy enough to implement in Bugzilla--in filter(), _default & _all would just cause it to return everything, and then we'd check for extra fields or _all within the methods. We'd add a should_include function to Bugzilla::WebService::Util that checked for a field name or _all being present. I suppose we could add _default to exclude_fields as well, though I'm not sure how useful that would be. And for Bug.get: _custom How does that sound? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Fri Jan 15 21:25:30 2010 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 15 Jan 2010 21:25:30 +0000 Subject: Using URL param auth with XML-RPC interface In-Reply-To: References: Message-ID: On 15/01/10 05:22, Max Kanat-Alexander wrote: > As of 3.6, you can specify Bugzilla_login and Bugzilla_password as > arguments to any WebService method: > > http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN I _thought_ I'd seen that somewhere. Thanks! Was this a complicated fix? Any chance of a backport? 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 Jan 15 21:27:23 2010 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 15 Jan 2010 21:27:23 +0000 Subject: Using URL param auth with XML-RPC interface In-Reply-To: References: Message-ID: On 15/01/10 21:25, Gervase Markham wrote: > I _thought_ I'd seen that somewhere. Thanks! Was this a complicated fix? > Any chance of a backport? I should add that the reason I'd want one is that it makes the BzAPI basically stateless, which is a really big win for reduced complexity and increased performance. Performance would be more consistent, instead of the request being 2x slower the first time you used an XML-RPC-backed call. And I would almost never have to make 2 connections to Bugzilla rather than 1 to fulfil any request. 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 Jan 15 21:37:11 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 15 Jan 2010 13:37:11 -0800 Subject: Using URL param auth with XML-RPC interface In-Reply-To: References: Message-ID: <4B50E007.5000602@bugzilla.org> On 01/15/2010 01:25 PM, Gervase Markham wrote: > I _thought_ I'd seen that somewhere. Thanks! Was this a complicated fix? > Any chance of a backport? It was pretty complicated--it involved overriding stuff in the internals of both backend modules that we use for WebServices. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Fri Jan 15 21:39:46 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 15 Jan 2010 13:39:46 -0800 Subject: Including and excluding fields In-Reply-To: <4B50DE0B.8010402@bugzilla.org> References: <4B50DE0B.8010402@bugzilla.org> Message-ID: <4B50E0A2.80005@bugzilla.org> On 01/15/2010 01:28 PM, Max Kanat-Alexander wrote: > This is easy enough to implement in Bugzilla Oh, also, to implement your attachment.data thing (which is a good idea), we'd also have to modify filter() to account for fields named like that. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mockodin at gmail.com Fri Jan 15 21:41:19 2010 From: mockodin at gmail.com (Michael Thomas) Date: Fri, 15 Jan 2010 13:41:19 -0800 Subject: Using URL param auth with XML-RPC interface In-Reply-To: References: Message-ID: <6b9407351001151341v42f18f67g2288f1aa3e005f5d@mail.gmail.com> Sending passwords clear text is never a "good" thing, even for the upside of performance. On Wed, Jan 13, 2010 at 7:32 AM, Gervase Markham wrote: > Is it possible in some way to use the Bugzilla_login and > Bugzilla_password URL parameters with the XML-RPC interface, thereby > obviating the need to login? If you have to login, it means two requests > to get one piece of data, which kills performance. > > Reading the code suggested there might be, tentative experiments suggest > that there isn't. > > 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 Fri Jan 15 21:42:28 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 15 Jan 2010 13:42:28 -0800 Subject: Using URL param auth with XML-RPC interface In-Reply-To: <6b9407351001151341v42f18f67g2288f1aa3e005f5d@mail.gmail.com> References: <6b9407351001151341v42f18f67g2288f1aa3e005f5d@mail.gmail.com> Message-ID: <4B50E144.4020706@bugzilla.org> On 01/15/2010 01:41 PM, Michael Thomas wrote: > Sending passwords clear text is never a "good" thing, even for the > upside of performance. That's resolved by always using HTTPS. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Fri Jan 15 21:44:39 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 15 Jan 2010 13:44:39 -0800 Subject: Bugzilla cookies HTTP only In-Reply-To: References: Message-ID: <4B50E1C7.5010605@bugzilla.org> On 01/13/2010 08:37 AM, Gervase Markham wrote: > What exactly are the security benefits we get from having our cookies > HTTPonly? > [snip] I tell ya what--get dveditz or Jesse to weigh in on this; we're not as much security experts as they are. At the least, Bugzilla_login can have httponly removed--only Bugzilla_logincookie is actually sensitive. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mockodin at gmail.com Fri Jan 15 21:50:26 2010 From: mockodin at gmail.com (Michael Thomas) Date: Fri, 15 Jan 2010 13:50:26 -0800 Subject: Using URL param auth with XML-RPC interface In-Reply-To: <4B50E144.4020706@bugzilla.org> References: <6b9407351001151341v42f18f67g2288f1aa3e005f5d@mail.gmail.com> <4B50E144.4020706@bugzilla.org> Message-ID: <6b9407351001151350r3827271au28146d83ed0d91da@mail.gmail.com> In Transit yes, in the server logs however.. such as access log etc.. is typically logged unencrypted, AFAIK. Using SSL makes things better not perfect. On Fri, Jan 15, 2010 at 1:42 PM, Max Kanat-Alexander wrote: > On 01/15/2010 01:41 PM, Michael Thomas wrote: > > Sending passwords clear text is never a "good" thing, even for the > > upside of performance. > > That's resolved by always using HTTPS. > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Jan 15 21:46:37 2010 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 15 Jan 2010 21:46:37 +0000 Subject: Bug Relationships In-Reply-To: References: Message-ID: On 11/01/10 21:29, Max Kanat-Alexander wrote: > Hey Gerv. We've discussed this a fair bit within a few bugs. I agree > that dependson and blocks should become default implementations of a > generic system for creating fields like that, which is described here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=251556 Having looked at it, is that quite the same thing? An important part of the way the UI works for the feature I was suggesting, is that you don't have separate UI for dependson, blocks and any other relationships you want - it's a single unified UI. This would imply a database representation like the following: bug_id relationship target 123456 7 125632 563354 4 http://foo.com/bug/64564 ... rel_id forwards backwards commutative 4 "blocks" "depends_on" FALSE Or something like that. Is that's what's envisaged? Or, to put it another way, can you generically implement my UI on top of the system proposed in 251556? > The future functionality of See Also mostly excludes it from being > usefully included in that generic system for now, though. ( > https://bugzilla.mozilla.org/show_bug.cgi?id=bz-seealso ) I'm still hoping you'll reply to my query about this :-) 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 Jan 15 21:49:46 2010 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 15 Jan 2010 21:49:46 +0000 Subject: Including and excluding fields In-Reply-To: References: Message-ID: On 15/01/10 21:28, Max Kanat-Alexander wrote: > Hmm. Okay, so here's my proposal: Sounds good to me :-) > I suppose we could add _default to exclude_fields as well, though I'm > not sure how useful that would be. It wouldn't be useful, as far as I can see! If it falls out of the implementation, fine. If not, equally fine. 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 Jan 15 21:51:18 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 15 Jan 2010 13:51:18 -0800 Subject: Using URL param auth with XML-RPC interface In-Reply-To: <6b9407351001151350r3827271au28146d83ed0d91da@mail.gmail.com> References: <6b9407351001151341v42f18f67g2288f1aa3e005f5d@mail.gmail.com> <4B50E144.4020706@bugzilla.org> <6b9407351001151350r3827271au28146d83ed0d91da@mail.gmail.com> Message-ID: <4B50E356.8090803@bugzilla.org> On 01/15/2010 01:50 PM, Michael Thomas wrote: > In Transit yes, in the server logs however.. such as access log etc.. is > typically logged unencrypted, AFAIK. Using SSL makes things better not > perfect. I'm not aware of any server that logs POSTDATA, particularly not when it's XML. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mockodin at gmail.com Fri Jan 15 21:52:37 2010 From: mockodin at gmail.com (Michael Thomas) Date: Fri, 15 Jan 2010 13:52:37 -0800 Subject: Using URL param auth with XML-RPC interface In-Reply-To: <4B50E356.8090803@bugzilla.org> References: <6b9407351001151341v42f18f67g2288f1aa3e005f5d@mail.gmail.com> <4B50E144.4020706@bugzilla.org> <6b9407351001151350r3827271au28146d83ed0d91da@mail.gmail.com> <4B50E356.8090803@bugzilla.org> Message-ID: <6b9407351001151352r2d4e02f8s44020eff34a872ef@mail.gmail.com> Assumes it is POST. On Fri, Jan 15, 2010 at 1:51 PM, Max Kanat-Alexander wrote: > On 01/15/2010 01:50 PM, Michael Thomas wrote: > > In Transit yes, in the server logs however.. such as access log etc.. is > > typically logged unencrypted, AFAIK. Using SSL makes things better not > > perfect. > > I'm not aware of any server that logs POSTDATA, particularly not > when > it's XML. > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Fri Jan 15 21:54:47 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 15 Jan 2010 13:54:47 -0800 Subject: Bug Relationships In-Reply-To: References: Message-ID: <4B50E427.70200@bugzilla.org> On 01/15/2010 01:46 PM, Gervase Markham wrote: > This would > imply a database representation like the following: > > bug_id relationship target > 123456 7 125632 > 563354 4 http://foo.com/bug/64564 No, this would be overkill; there aren't going to be more than a few relationship custom fields on the average Bugzilla, if there's even one. When we go to many-to-many relationships (right now we just have many-to-one), we'll have separate tables for each field. Each relationship will be its own field, just like Depends On and Blocks are, now. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mockodin at gmail.com Fri Jan 15 21:54:54 2010 From: mockodin at gmail.com (Michael Thomas) Date: Fri, 15 Jan 2010 13:54:54 -0800 Subject: Using URL param auth with XML-RPC interface In-Reply-To: <6b9407351001151352r2d4e02f8s44020eff34a872ef@mail.gmail.com> References: <6b9407351001151341v42f18f67g2288f1aa3e005f5d@mail.gmail.com> <4B50E144.4020706@bugzilla.org> <6b9407351001151350r3827271au28146d83ed0d91da@mail.gmail.com> <4B50E356.8090803@bugzilla.org> <6b9407351001151352r2d4e02f8s44020eff34a872ef@mail.gmail.com> Message-ID: <6b9407351001151354i13a5d6c8rb7272030228ad94@mail.gmail.com> I took this: >Bugzilla_password URL parameters with the XML-RPC interface to mean Gervase was looking at a GET -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Fri Jan 15 21:56:42 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 15 Jan 2010 13:56:42 -0800 Subject: Bug Relationships In-Reply-To: References: Message-ID: <4B50E49A.3040607@bugzilla.org> On 01/12/2010 03:09 AM, Gervase Markham wrote: > You are going to need to spell out for me why that is. To put the > question another way: if I can mark b.m.o. bug 123 as "depends on" > b.m.o. bug 456, why should I not be able to mark it as "depends on" > bugzilla.gnome.org bug 789? > > In other words, why can the functionality you want to add to See Also, > such as getting information from the remote bug system and displaying > it, not become part of the generic implementation? Let's wait and see how the full and complete implementation of See Also turns out. The goal is to keep it as simple as possible, to interact with as many different possible trackers as possible, and to have the maximum useful functionality based on that simplicity. Right now I want to do that by making it a fully-mutual relationship, not a dual-one-way relationship like Depends On and Blocks are. We decided against those sorts of relationships when we were implementing See Also, for simplicity's sake, and it will probably stay that way for the foreseeable future. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From dveditz at mozilla.com Fri Jan 15 23:49:30 2010 From: dveditz at mozilla.com (Daniel Veditz) Date: Fri, 15 Jan 2010 15:49:30 -0800 Subject: Bugzilla cookies HTTP only In-Reply-To: References: Message-ID: Taking your points in reverse order > 2) Large sites now use a different domain name for attachments anyway. We introduced HTTPOnly cookies at least six months before we finally fixed the attachment bug. Smaller sites may not use a different domain. Attachments aren't the only thing you want to protect, in particular, bugzilla instances with zero private bugs may still want to prevent malicious outsiders from having free reign to mess with someone's account. > 1) It doesn't work, because if they've managed to get code running in > your Bugzilla page context, the attacker can just make any requests > they want using XMLHttpRequest, and the auth cookies will get sent > right along: True, but the damage can only be done while the victim is on that page. There's plenty of damage that can be done in that window of time, but it does at least prevent attackers from browsing the user's account later at their leisure. On 1/13/10 8:37 AM, Gervase Markham wrote: > I ask because I was hoping to allow Greasemonkey scripts/Jetpacks etc. > which run in the context of Bugzilla pages to grab the auth cookie and > pass it on to the API, which can then use it to access Bugzilla. Any add-on can get the real cookies through the cookie service. Maybe you don't want this to be a limited GreaseMonkey user-script. > This obviates the rather irritating and insecure step of having to > configure every Jetpack or Greasemonkey script with your Bugzilla > username and password. However, having refactored BzAPI for this Isn't it somewhat irritating--and temporary--that the BzAPI doesn't actually live at bugzilla.mozilla.org ? Once the API is production-ready it will presumably be hosted at BMO and this won't be a problem. The fact that a GreaseMonkey script wants to ship the BMO cookie off to a 3rd party server is suspicious and alarming and we shouldn't be training people that this is a perfectly normal and OK behavior. > The usual threat that HTTPonly is said to protect against is cookie > stealing by malicious scripts. That is the only thing it protects against, yes. And hey, it seems to work! The protection stopped you, and the only difference between what you're doing and a malicious script is whether people trust you not to be malicious. There's no way to bake that kind of judgment into software. To my mind requiring the explicit configuration is good because it's getting opt-in consent from users for you to use their credentials. Wait a minute, aren't bugzilla login cookies scoped to an IP address? If users are bouncing requests off your server why isn't BMO rejecting the cookie when it comes in from that different address? -Dan Veditz _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From craig5 at pobox.com Mon Jan 18 00:55:26 2010 From: craig5 at pobox.com (Craig) Date: Mon, 18 Jan 2010 01:55:26 +0100 Subject: sample data Message-ID: <4B53B17E.1060007@pobox.com> Hi all. Is there some kind of (small-ish) sample data set that I can use? Obviously, I can enter in a bunch of bogus bugs and then test, but that is a little tedious. If there is another solution I am all for it! (Keep in mind that my internet connection has been a little flaky since I moved to Europe. So, I would really prefer to load this onto my machine for the time being. But, that is not a "requirement"...) TIA! Craig From vitaly.fedrushkov at gmail.com Mon Jan 18 05:30:42 2010 From: vitaly.fedrushkov at gmail.com (SnowyOwl) Date: Sun, 17 Jan 2010 21:30:42 -0800 (PST) Subject: sample data References: Message-ID: <0bd436ca-ec74-43c3-8b82-6e5023ac11c7@l19g2000yqb.googlegroups.com> > Is there some kind of (small-ish) sample data set that I can use? You can pick any instance from landfill.bugzilla.org, export some subset to XML and then import. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From ghendricks at novell.com Mon Jan 18 17:21:48 2010 From: ghendricks at novell.com (Gregary Hendricks) Date: Mon, 18 Jan 2010 10:21:48 -0700 Subject: sample data In-Reply-To: <4B53B17E.1060007@pobox.com> References: <4B53B17E.1060007@pobox.com> Message-ID: <4B54363C020000D2000666C3@soto.provo.novell.com> >>> On 1/17/2010 at 05:55 PM, in message <4B53B17E.1060007 at pobox.com>, Craig wrote: > Hi all. > > Is there some kind of (small-ish) sample data set that I can use? > > Obviously, I can enter in a bunch of bogus bugs and then test, but that > is a little tedious. > > If there is another solution I am all for it! (Keep in mind that my > internet connection has been a little flaky since I moved to Europe. So, > I would really prefer to load this onto my machine for the time being. > But, that is not a "requirement"...) > You can use the installation on landfill at http://landfill.mozilla.org/testopia or you can load the test data found in the t/data directory of the testopia extentsion folder. Greg From mkanat at bugzilla.org Tue Jan 19 02:13:51 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 18 Jan 2010 18:13:51 -0800 Subject: Results of Community Research Message-ID: <4B55155F.3060007@bugzilla.org> Hey folks. So, as you know, I sent out a message a few weeks ago asking former contributors why they left. Also, as you may not know, before that, for several days I was involved in a statistical analysis of the history of Bugzilla contributions. Basically, I looked at how many different contributors we had in CVS for every 30 day period since the start of the Bugzilla Project. I wrote a script that gave me the data by parsing out who the "Patch By" email address was, or I used the committer if there was no "Patch By" in the commit message, and I joined people who I knew to be duplicates, which were very few. The resulting graph was very interesting. It showed two interesting things: * Freezes kill the community--every time we had a code freeze, the number of contributors would dramatically drop and then recover slowly. * Despite this, the size of the community generally increased until the start of 2005, and then leveled off through 2005, and then started to slowly decrease after that. No matter how I reorganized the data, or how I analyzed it, 2005 was the critical year. So my question was--what happened in 2005 that changed things so dramatically? After QUITE a bit of searching, I discovered the following: 1) The "review" and "review-requests" mailing lists were split at the start of 2005. Before, all reviewers had at least seen every single review request. Now they had to subscribe to review-requests and actually *request* all that spam, which nobody was going to do. (I didn't even know about the review-requests list by the time I became a reviewer, which was after this point.) I think that this particularly hurt people's ability to get review "from the wind", since only old-time and very dedicated reviewers would have been on the list where those requests went. 2) We froze *twice* for 2.20. #2 wouldn't have been so bad, and we would have recovered, I think, if not for #1. But why would that review-requests change have such a profound effect? Well, the answers to that were at least partially in the survey results. (By the way, I really appreciate all the answers that I got, they were extremely helpful.) The #1 reason that people leave is simply that they no longer have time to contribute, or that they were contributing as part of their job and now they have changed jobs. The survey data showed that it is to some degree inevitable that contributors are going to leave. I'd like to note here that nobody gave "the review process is too hard" as a reason for leaving. Some people here and there have banged the drum for a lowering of quality as an incentive to attract and retain community members, and there was absolutely no evidence in the survey that that would improve the situation at all. Both of the former documentors who responded mentioned the lack of kudos from the community as one reason that they weren't motivated to stay in the community. Several other people mentioned negative interactions or simply a lack of appreciation as part of the reason that they left. In fact, for nearly every person who responded, the factors involved in not staying, beyond "my job changed" or "I didn't have time", were surprisingly personal. I know that we all work with computers, and perhaps we'd like to think that engineering should be a totally cold scientific profession where we all do our jobs correctly according to the requirements of the machine, and not worry about our emotional or personal involvements. But nothing could be further from the truth--the personal interactions that people have with community members, the amount they feel appreciated, and the amount they feel assaulted, are actually the MOST IMPORTANT ASPECTS OF RETAINING COMMUNITY MEMBERS. And *retaining* community members is what we have to do, particularly *new* community members. Because the statistical analysis and the survey both showed that the eventual leaving of many contributors is *inevitable*. What we have to focus on is locating, accepting, and encouraging *new* contributors. If we don't continuously *grow* the community with new members, it will continuously shrink as old ones leave, no matter what else we do. The survey tells me that the keys to retaining new community members are: 1) Extremely rapid response to review requests. No matter how much review a contributor has to go through, they usually will go through it as long as there aren't LONG DELAYS between the request and the response. 2) Extreme kindness and visible appreciation. When people contribute on a volunteer basis, they aren't getting paid in money, they are getting paid in admiration, appreciation, the sense of a job well done, and the knowledge that they are helping create a product that affects millions of people directly and even more people indirectly (because people use Bugzilla as part of making other products). When somebody has contributed a patch, WE NEED TO THANK THEM. It doesn't matter if the patch is total crap and has to be re-written entirely, WE NEED TO THANK THEM. They have put some work into this, and if we don't appreciate that, THEY WILL LEAVE BEFORE THEY EVEN START. After all, most people get little enough appreciation at their workplace--they stay there because they get paid in money! They don't need to work FOR FREE with some other organization if it also doesn't appreciate their work, or even worse, assaults every aspect of their contribution before even thanking them for it. This isn't to say that we can't correct people on the faults in their patches. "Kindness" does not include putting bad code into Bugzilla. That isn't kind to anybody, including the contributor whose skills probably need to improve, and who may go on believing that something they did in error was in fact correct. We have to still be careful reviewers and very good coders. What this does mean is that in addition to telling people what's *wrong* with their code, it's important to appreciate what's *right* about their contribution, even if it's simply the fact that they took the time to contribute. And you have to ACTUALLY TELL THE CONTRIBUTOR THAT YOU APPRECIATE THE CONTRIBUTION. The more frequently and genuinely that all of us do this, the more likely we are to retain the contributor. Some people are hopeless programmers, and they're never going to get better no matter how much you help them or how many reviews you do. For these people, you don't have to imagine nice things to say about them--I don't expect anybody to ever make up stuff that isn't true, just to be nice. If somebody has demonstrated conclusively that they're never going to get any better, or that they're just going to cause trouble one way or another no matter what we do, the best thing you can do is simply personally choose to ignore them, which is a personal decision that you can make for yourself. But that represents a very, very small percentage of total contributors. For the vast majority of contributors, even though they're a little rough around the edges for the first few months, the correct action is to be helpful, kind, appreciative, and responsive. 3) A total absence of personal negativity. One thing that drives people away from a project with lightning speed is when they get personally attacked for attempting to do something positive. A "personal attack" can be as little as an unpleasant joke about their code, instead of just a straightforward technical description of what is wrong. Saying something like, "What is wrong with you?" instead of actually leaving some helpful comment. Disguising personal criticism as "an attempt to help them code better" or "help them get along with others". (If somebody does something that offends you, just tell them that it offended you--that's usually totally enough to resolve the problem. You don't have to pretend that other people have a problem just because you do.) Look, I understand that sometimes coding and working on a collaborative project with people who have different viewpoints can get REALLY frustrating! I've been an offender in this area just as much as anybody has been! But it's really not OK for us to insult other developers personally just because we're frustrated with them personally. If you're having a bad day, then please feel free to take a break. Getting angry or upset with other developers in a personal way could actually be more damaging to the long-term future of the Project than a single day's worth of contributions would help. And finally, if there's some contributor that you just can't live with, please feel free to come to me, and I will absolutely do my best to work it out, even if it's been a really long-term thing! I'm all about being effective, too--I'm not going to just brush it off and say "well, maybe it all will fix itself," I'll do something effective about it. And if it's *me* that you have a problem with, please go to justdave about it, and he'll talk to me about it--he's very good at that sort of thing. :-) The most important thing is that you don't take it out on the person you're unhappy with--I don't think that that helps anybody, and it definitely harms the long-term future of the Project. Now, #2 and #3 above pretty much cover my recommendations on how we should behave toward new community members: be really, abnormally, really, really kind, and don't be mean. But how do we address the problem of the delay on reviews? Well, here's my recommendations for how we handle the review problem: 1. I personally have started to prioritize review requests from non-core contributors above anything else, including security work, releases, ANYTHING. New contributors are my #1 priority, and I've already seen this have a big effect on the number of contributions we're getting from outside developers. 2. I think we should say that if you're a reviewer, it's your responsibility to receive the review-requests emails, and we should merge review-requests back into review at . You don't have to have them go into your inbox, but you should at least receive and read them. I think that this would get a lot of people more involved in review, because everybody would get every review request, and even review from the "wind" might start to work again. Particularly for the less-active reviewers, this would give them more ability to pick and choose a few items that they wanted to review now and then, and it would also let each reviewer know if there was some area of their interest under review so that they could chime in on it. So whew! That's the results and my recommendations! :-) What do you guys think? :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Tue Jan 19 02:17:53 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 18 Jan 2010 18:17:53 -0800 Subject: Results of Community Research In-Reply-To: <4B55155F.3060007@bugzilla.org> References: <4B55155F.3060007@bugzilla.org> Message-ID: <4B551651.1000201@bugzilla.org> On 01/18/2010 06:13 PM, Max Kanat-Alexander wrote: > * Freezes kill the community--every time we had a code freeze, the > number of contributors would dramatically drop and then recover slowly. Oh, and I forgot to address this! I think that we've actually handled this recently, with our new freeze policy where we actually branch immediately, instead of ever freezing, so I think that this won't be a problem anymore in the future, although it's important that we pay equal attention to trunk reviews and branch reviews, when we're in a pre-release branch situation. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From Callek at gmail.com Tue Jan 19 06:03:10 2010 From: Callek at gmail.com (Justin Wood (Callek)) Date: Tue, 19 Jan 2010 01:03:10 -0500 Subject: Results of Community Research In-Reply-To: References: <4B55155F.3060007@bugzilla.org> Message-ID: On 1/18/2010 9:17 PM, Max Kanat-Alexander wrote: ... Allow me to just say THANK YOU to you and other contributors and core people. I have written a patch or two, at most to bugzilla, but have not done more primarily because of time. (And dislike in general for perl). Anyway, what you guys do is always welcome and thanked on my part, even if I never say it. (There are still some pet peeves of mine, but they almost all are mine alone due to some weird self-configs I did on BMO) - ~Justin Wood (Callek) _______________________________________________ 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 Jan 19 09:33:49 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 19 Jan 2010 10:33:49 +0100 Subject: Results of Community Research In-Reply-To: <4B55155F.3060007@bugzilla.org> References: <4B55155F.3060007@bugzilla.org> Message-ID: <4B557C7D.4060108@gmail.com> Le 19. 01. 10 03:13, Max Kanat-Alexander a ?crit : > So my question was--what happened in 2005 that changed things so > dramatically? After QUITE a bit of searching, I discovered the following: I'm a bit surprised that nobody mentioned that 1) we have much less visible bugs in our code since the QA team exists (July 2005: https://wiki.mozilla.org/Bugzilla:QA), and so it's much less obvious for people to fix bugs they don't see unless they look at the code itself. Also, I heard here and there that 2) Bugzilla pretty much does all what some old contributors needed and so don't need to contribute any more. Why would you contribute for a feature you don't need? My personal opinion is that 2005-2006 also reflects some maturity of the product. I don't try to minimize what you mentioned in 1)-3), don't take me wrong. > Now, #2 and #3 above pretty much cover my recommendations on how we > should behave toward new community members: be really, abnormally, > really, really kind, and don't be mean. I hope this doesn't involve sending flowers to all our contributors with a greeting card. More seriously, "abnormally, really, really" sounds excessive to me and is not something I will fall into. > 1. I personally have started to prioritize review requests from > non-core contributors above anything else, including security work, Wow, security work should have the highest priority, IMO, because they often block releases (same for blockers). And we from time to time delay checkins because we are near a release date and we don't want to mess the code too late in the game. So having releases done faster would help focusing on new contributors once we have security bugs and blockers out of our plate. At least, that's my point of view. To be clear, I'm since early December ignoring *all* requests for review which aren't about blockers, security bugs or targeted 3.6 or older, no matter who the requester is or how cool the new feature is. My remaining free time and motivation are devoted to QA. The sooner 3.6rc1 and 3.6 are released, the sooner I will accept looking at other contributions again. > 2. I think we should say that if you're a reviewer, it's your > responsibility to receive the review-requests emails, and we should > merge review-requests back into review at . Please don't do that! reviewers@ and review-requests@ have different goals. And I recently unsubscribed from review-requests@ for a reason (after being 5 years in this mailing-list). Keep them separate, and just email reviewers@ to subscribe to review-requests@ if they want to. I don't see why you can/should/would be allowed to force them to read all review requests. It's prone to be redirected to the trash bin directly. And if you are the requestee, you already get review requests directly anyway. > everybody would get every review request, and even review from the > "wind" might start to work again. Out of the current 46 pending reviews in the Bugzilla product (4 of which are more than 5 months old!), we have only 4 requests from the wind. That's a pretty weak excuse to spam all reviewers with all review requests. Oh, and thanks for this research! ;) LpSolit From gerv at mozilla.org Tue Jan 19 11:31:29 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 19 Jan 2010 11:31:29 +0000 Subject: sample data In-Reply-To: References: Message-ID: <_YOdnXM5TaePBcjWnZ2dnUVZ_ohi4p2d@mozilla.org> On 18/01/10 00:55, Craig wrote: > Is there some kind of (small-ish) sample data set that I can use? Another way would be to install BzAPI (or use the XML-RPC API) and write a fairly simple script to generate random bugs. BzAPI would give you more control over more fields, but setting it up obviously takes time. 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 Jan 19 11:30:22 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 19 Jan 2010 11:30:22 +0000 Subject: Bugzilla cookies HTTP only In-Reply-To: References: Message-ID: <4B5597CE.7040200@mozilla.org> On 15/01/10 23:49, Daniel Veditz wrote: > Any add-on can get the real cookies through the cookie service. A fair point, indeed. > Isn't it somewhat irritating--and temporary--that the BzAPI doesn't > actually live at bugzilla.mozilla.org ? Once the API is production-ready > it will presumably be hosted at BMO and this won't be a problem. There are currently no plans to host it on the exact same machine. We could do that eventually but, given the understandable concern there would be about installing new software on an important production system, it's a way off. Also, it's useful for people to be able to set up a BzAPI against a legacy Bugzilla, even one they don't control. > The fact that a GreaseMonkey script wants to ship the BMO cookie off to > a 3rd party server is suspicious and alarming and we shouldn't be > training people that this is a perfectly normal and OK behavior. Hmm. Yes. > Wait a minute, aren't bugzilla login cookies scoped to an IP address? If > users are bouncing requests off your server why isn't BMO rejecting the > cookie when it comes in from that different address? I hadn't even got that far. Maybe you're right. OK, I give up :-) We'll just have to say you can't do this easily right now. 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 Jan 19 12:38:07 2010 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 19 Jan 2010 12:38:07 +0000 Subject: Results of Community Research In-Reply-To: References: Message-ID: <4B55A7AF.2040803@mozilla.org> Hi Max, Thanks for doing all this work ;-) I have a few questions and queries, but that shouldn't undermine the fact that this is really useful data gathering. On 19/01/10 02:13, Max Kanat-Alexander wrote: > * Freezes kill the community--every time we had a code freeze, the > number of contributors would dramatically drop and then recover slowly. Is this, at least partially, a statistical artifact of the fact that you are measuring continuity as "contributes every month"? After all, a freeze means fewer patches, so there may be more people who consider themselves part of the community (and may have been attaching patches to bugs to wait for when the tree reopens) but who did not actually check in or provide a patch for the trunk because it was frozen. Would it be worth instead doing some sort of three-month rolling average (if you've contributed in month X, or X+1, or X-1, you get a tick for month X)? Or perhaps look at attached patches in Bugzilla as well as checkin data? Did you find it was common for someone to leave the community and return? If so, it might be an indication that your data isn't smoothed enough in this way. > * Despite this, the size of the community generally increased until the > start of 2005, and then leveled off through 2005, and then started to > slowly decrease after that. No matter how I reorganized the data, or how > I analyzed it, 2005 was the critical year. Is the raw data available to look at? What are the absolute numbers here? Was the peak community size 4, or 40? Is the addition or removal of a single contributor a significant factor in the numbers? > 1) The "review" and "review-requests" mailing lists were split at the > start of 2005. Before, all reviewers had at least seen every single > review request. Now they had to subscribe to review-requests and > actually *request* all that spam, which nobody was going to do. (I > didn't even know about the review-requests list by the time I became a > reviewer, which was after this point.) I think that this particularly > hurt people's ability to get review "from the wind", since only old-time > and very dedicated reviewers would have been on the list where those > requests went. I didn't even realise there was a review-requests mailing list. Or, if I ever knew it, I've forgotten. > I'd like to note here that nobody gave "the review process is too hard" > as a reason for leaving. Some people here and there have banged the drum > for a lowering of quality as an incentive to attract and retain > community members, and there was absolutely no evidence in the survey > that that would improve the situation at all. As someone who might be interpreted as banging this drum, I think your summary of the view (or, at least, my view :-) is not quite correct. Firstly, I am not arguing for "lower quality". As you know, quality is not a single number - "this patch has a quality of 45". And I have no issues with someone being asked to change a patch at a code level or to conform to style guidelines. But on different occasions, I have argued for: - The acceptance of a patch which provides partial, useful, functionality in pursuit of a larger goal, rather than waiting for the submitter to implement the entire feature as envisaged by the team (but not by the submitter) - The acceptance of a patch which provides useful functionality, even if the code would eventually be obsoleted by a rewrite of the feature which is wanted but un-resourced and un-scheduled - Within limits, the acceptance of a patch which solves a problem for an existing user or set of users, even if the Bugzilla team don't particularly like the way it's done, if the team has no plans to solve that problem themselves 'the better way'. (The problem here is that often the problem ends up lingering unsolved for years, to nobody's benefit. This is what is generally known as "stop energy".) Taking any patch is a trade-off between the plus of the problem solved and the contributor encouraged, against the minus that the patch may not be absolutely 100% as it would be if the reviewer had written it. We need to consider whether we are weighing the second of those two factors lightly enough. As I understand it, your research was looking at people who became community members and then stopped. My contention is that people who have their patches rejected for reasons related to one of the above never _become_ community members - and therefore would not have been reached by your survey. (You talk more about initial acceptance below, and that's great.) Therefore, I think your conclusion that the above sorts of thing are not a factor may not actually be supportable by your gathered evidence. > Both of the former documentors who responded mentioned the lack of > kudos from the community as one reason that they weren't motivated to > stay in the community. I'm a "former documenter", in that I used to work on the Bugzilla documentation and now no longer do. My reasons for stopping were: - The documentation build system was byzantine in its complexity, and every time I got a new machine (or even when I didn't) it needed setting up. - The XML markup gave the ability to produce text, HTML and PDF, but it made it very difficult to do things with graphics or layout in order to make the documentation more readable. I had to remember an XML vocabulary not used anywhere else in my online life. - Documentation was treated like code, with patches having to be prepared and reviewed, rather than like a wiki. Getting fixes in, particularly rewrites and reorganizations, was just too much effort. I've got a fairly thick skin, so the fact that a big documentation reorganization was met with process-based obstructions rather than a "wow, thanks for putting in all that work" didn't affect me too much :-) > personal involvements. But nothing could be further from the truth--the > personal interactions that people have with community members, the > amount they feel appreciated, and the amount they feel assaulted, are > actually the MOST IMPORTANT ASPECTS OF RETAINING COMMUNITY MEMBERS. Have you read "The Art of Community" by Jono Bacon, recently published? It's fantastic on this sort of thing - well worth a read. I read it recently, cover to cover. Also, if you are around at OSCON time, he runs the Community Leadership Summit: http://www.facebook.com/event.php?eid=186487039968 Anyone in the Bay Area at the time should consider attending. > 1) Extremely rapid response to review requests. No matter how much > review a contributor has to go through, they usually will go through it > as long as there aren't LONG DELAYS between the request and the response. Definitely. On the main Mozilla side, I've been trying for years to get a system in place which tracks this across the project and nags the appropriate people. The trick, in that case, is defining "appropriate people". > Some people are hopeless programmers, and they're never going to get > better no matter how much you help them or how many reviews you do. For > these people, you don't have to imagine nice things to say about them--I > don't expect anybody to ever make up stuff that isn't true, just to be > nice. If somebody has demonstrated conclusively that they're never going > to get any better, or that they're just going to cause trouble one way > or another no matter what we do, the best thing you can do is simply > personally choose to ignore them, which is a personal decision that you > can make for yourself. I don't actually agree with that. I think the best thing you can do is tell them why their contributions aren't being accepted, and say that unfortunately you will not be able to make time in future to review their contributions. This is possibly (although by no means certainly) more likely to result in hurt feelings than just ignoring them, but it is also much more likely that their life will improve as they go and do something they are actually good at. You certainly don't have to be rude or brusque when telling them, but I think you are doing them greater good by telling them. Also, bad coders might make great support people, or documenters (if your documentation system isn't the functional and process equivalent of writing code ;-). > Look, I understand that sometimes coding and working on a collaborative > project with people who have different viewpoints can get REALLY > frustrating! I've been an offender in this area just as much as anybody > has been! But it's really not OK for us to insult other developers > personally just because we're frustrated with them personally. I agree with all of what you write. Have you noticed any of this? This isn't acceptable in a more broader Mozilla context, as well as in a Bugzilla one, and I take it seriously when I find it. > Well, here's my recommendations for how we handle the review problem: > > 1. I personally have started to prioritize review requests from > non-core contributors above anything else, including security work, > releases, ANYTHING. New contributors are my #1 priority, and I've > already seen this have a big effect on the number of contributions we're > getting from outside developers. Fantastic! :-) > 2. I think we should say that if you're a reviewer, it's your > responsibility to receive the review-requests emails, and we should > merge review-requests back into review at . Sounds absolutely fine to me. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mockodin at gmail.com Tue Jan 19 19:05:27 2010 From: mockodin at gmail.com (Michael Thomas) Date: Tue, 19 Jan 2010 11:05:27 -0800 Subject: Easier Patch Submission? Is it possible? Message-ID: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> Just to throw an idea out. One piece that makes submitting patches difficult is patch file creation. Often patches are generated in-the-line-of-duty as it were and then the change is submitted back to the community. Often the temptation, at least for me, is to submit the raw edited file rather than a cvs patch file. My question is why not? Why can't patch files be automatically derived on submission of a complete file or on-the-fly comparison on request. The advantage of a complete file is context, a patch files shows only a subset of the the file relating to the changes but not necessarily how it relates to the rest of the code. The obvious disadvantage to whole file submission having to submit files 1 to 1 instead of a single patch file incorporating all changes. That however again is not per say a bad thing as individual files could then be approved/denied. The main issue I can really see is that there are no version tags within the files themselves. If those version numbers were added it should be fairly trivial to automatically generate the patch files against the corresponding base file. Just a thought. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Tue Jan 19 19:22:24 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 19 Jan 2010 20:22:24 +0100 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> Message-ID: <4B560670.4060707@gmail.com> Le 19. 01. 10 20:05, Michael Thomas a ?crit : > temptation, at least for me, is to submit the raw edited file rather than a > cvs patch file. My question is why not? Because nobody would review it. Also, you don't need to do a CVS diff. A local diff would work too. Why can't patch files be > automatically derived on submission of a complete file or on-the-fly > comparison on request. Because Bugzilla would have no idea what the file is. When you attach plain text, the name of the file is not included. Bugzilla cannot guess. > The advantage of a complete file is context, a patch files shows only a > subset of the the file relating to the changes but not necessarily how it > relates to the rest of the code. Well, that's inaccurate as Bugzilla lets you view the whole file from a patch with only a few lines of context. That's how I always review patches. No need for the whole file. LpSolit From mockodin at gmail.com Tue Jan 19 19:37:28 2010 From: mockodin at gmail.com (Michael Thomas) Date: Tue, 19 Jan 2010 11:37:28 -0800 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <4B560670.4060707@gmail.com> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> Message-ID: <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> 2010/1/19 Fr?d?ric Buclin > Because nobody would review it. Also, you don't need to do a CVS diff. A > local diff would work too. > > Actually meant that it would be nice if the patch file was created on submission. Rather than client side. So the review process would be no different. Not saying that doing the diff is that hard, more that sometimes the 5 minutes it takes is 5 minutes someone might not have at a given moment in time. The result being that a perfectly good fix or enhancement gets relgated to the back burner and forgotten even though the work is already done. > Because Bugzilla would have no idea what the file is. When you attach > plain text, the name of the file is not included. Bugzilla cannot guess. > > True, I'm not saying as of this second it would work, more that if the appropriate tags were added the base files it would work, eg tag with path/name and tag with version. > > Well, that's inaccurate as Bugzilla lets you view the whole file from a > patch with only a few lines of context. That's how I always review > patches. No need for the whole file. > > Ok figured that out: Click 'View attachment as Diff' then click 'File' in "Context: (Patch / File)" so right in front of me :-) > > LpSolit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Tue Jan 19 19:43:49 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 19 Jan 2010 20:43:49 +0100 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> Message-ID: <4B560B75.60600@gmail.com> Le 19. 01. 10 20:37, Michael Thomas a ?crit : > Not saying that doing the diff is that hard, more that sometimes the 5 > minutes it takes 5 minutes?? It shouldn't take more than 10-20 seconds under normal conditions. LpSolit From mockodin at gmail.com Tue Jan 19 20:13:25 2010 From: mockodin at gmail.com (Michael Thomas) Date: Tue, 19 Jan 2010 12:13:25 -0800 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <4B560B75.60600@gmail.com> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> Message-ID: <6b9407351001191213m2f788329o8b14d4811d083f4b@mail.gmail.com> In my case, set environment to bypass blocked ports so I can connect to CVS @ command prompt: SET CVSROOT=:pserver:anonymous at cvs-mirror.mozilla.org:/cvsroot cvs diff -Nu > patch.diff 30 files changed => edit path.diff and filter which patch diffs I want sent, say only 3 of them => update the BMO bug and attach file 5 Minutes being relative, at times 30 seconds is hard to come by or easily forgotten due a fire. FROM irc://moznet/mozwebtools LpSolit> use patchmaker, it's much easier to create patches LpSolit> it's a script written by gerv LpSolit> very easy to use dwm> http://www.gerv.net/software/patch-maker/index.html I'll take a look... 2010/1/19 Fr?d?ric Buclin > > Le 19. 01. 10 20:37, Michael Thomas a ?crit : > > Not saying that doing the diff is that hard, more that sometimes the 5 > > minutes it takes > > 5 minutes?? It shouldn't take more than 10-20 seconds under normal > conditions. > > LpSolit > - > To view or change your list settings, click here: > From vseerror at lehigh.edu Tue Jan 19 20:18:07 2010 From: vseerror at lehigh.edu (Wayne Mery) Date: Tue, 19 Jan 2010 15:18:07 -0500 Subject: duplicates.cgi Message-ID: Is there a way to make/put the output of duplicates.cgi - eg https://bugzilla.mozilla.org/duplicates.cgi?product=MailNews%20Core&product=Thunderbird&format=simple&sortby=delta&reverse=1&maxrows=100&changedsince=28 - into a real bugzilla query result list of buglist.cgi? reply-to set to mozilla.dev.apps.bugzilla -- http://wiki.mozilla.org/Thunderbird:Testing http://www.spreadthunderbird.com/aff/165/ _______________________________________________ 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 Jan 19 20:23:23 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 19 Jan 2010 21:23:23 +0100 Subject: duplicates.cgi In-Reply-To: References: Message-ID: <4B5614BB.1020902@gmail.com> Le 19. 01. 10 21:18, Wayne Mery a ?crit : > Is there a way to make/put the output of duplicates.cgi into a real bugzilla query result list of buglist.cgi? Not that I know of, but it would be pretty easy to implement. :) LpSolit From michael.j.tosh at lmco.com Tue Jan 19 20:13:09 2010 From: michael.j.tosh at lmco.com (Tosh, Michael J) Date: Tue, 19 Jan 2010 15:13:09 -0500 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <4B560B75.60600@gmail.com> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> Message-ID: <8A06826F0DE9AD4087CEBD52E769C0DC39738000@HVXMSPB.us.lmco.com> Fr?d?ric Buclin wrote: > Le 19. 01. 10 20:37, Michael Thomas a ?crit : >> Not saying that doing the diff is that hard, more that sometimes the 5 >> minutes it takes > > 5 minutes?? It shouldn't take more than 10-20 seconds under normal > conditions. Depends on what you start with. If it is clean (not modified already) then 10-20 seconds, but if you have to manually remove unrelated modifications, it can take a bit longer. From Callek at gmail.com Wed Jan 20 03:51:03 2010 From: Callek at gmail.com (Justin Wood (Callek)) Date: Tue, 19 Jan 2010 22:51:03 -0500 Subject: Easier Patch Submission? Is it possible? In-Reply-To: References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> Message-ID: On 1/19/2010 3:13 PM, Tosh, Michael J wrote: > Fr?d?ric Buclin wrote: >> Le 19. 01. 10 20:37, Michael Thomas a ?crit : >>> Not saying that doing the diff is that hard, more that sometimes the 5 >>> minutes it takes >> >> 5 minutes?? It shouldn't take more than 10-20 seconds under normal >> conditions. > > Depends on what you start with. If it is clean (not modified already) then 10-20 seconds, but if you have to manually remove unrelated modifications, it can take a bit longer. BZR/HG makes this issue a non-issue. - ~Justin Wood (Callek) _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From jochen.wiedmann at gmail.com Wed Jan 20 08:26:42 2010 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Wed, 20 Jan 2010 09:26:42 +0100 Subject: Easier Patch Submission? Is it possible? In-Reply-To: References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> Message-ID: In a similar thread a long time ago, I expressed my uneasiness with the review process. My argument was, that reviewers should not always insist in complete or perfect patches, depending on the issue. I'd rather see the committer understand what I am doing, modify my changes, if he feels the need (for whatever reason) and pulls it in. At least, I'd clearly prefer this, if it could help to reduce the number of iterations: In the end, it could save my time and the committers, who wouldn't need to add another review. At that time, my proposal was refused, mostly with the argument that the contributior "feels better", because the patch is "100% his". However, my impression hasn't changed: Being a long time committer on several Apache projects, where I follow my suggested approach, I feel that it is much easier to get patches in than into Bugzilla. Jochen -- Germanys national anthem is the most boring in the world - how telling! From lpsolit at gmail.com Wed Jan 20 12:24:30 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 20 Jan 2010 13:24:30 +0100 Subject: Easier Patch Submission? Is it possible? In-Reply-To: References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> Message-ID: <4B56F5FE.4000906@gmail.com> Le 20. 01. 10 09:26, Jochen Wiedmann a ?crit : > At that time, my proposal was refused, mostly with the argument that > the contributior "feels better", because the patch is "100% his". I remember this discussion. There were two points in favor of several iterations: the first one is the one you mentioned, i.e. letting the contributor attach a complete and correct patch, so he really has the feeling that he did the whole job himself (and to get all the merit). The second point was to make contributors "better", i.e. they understand the points we would like them to make better so that they do it right the next time they contribute. Now the main disadvantages of this approach are 1) it takes a lot of time from the reviewer, as you said, and 2) there is a risk that the contributor becomes demotivated and leaves (because for him, his patch is working, and doesn't care about your nits or the refactoring you suggest him to do). To avoid these problems, what I do more and more often is either 1) r+ the patch and mention that I will do the numerous "fixes on checkin" myself, to avoid extra loops and to not demotivate the contributor, or 2) I ask the contributor if he agrees that I finalize his patch myself, so that he doesn't think I'm trying to steal his work and get all the credit. I think that's a better choice, but this requires some free time from the reviewer to update and test the patch, and is only doable if the reviewer has a real interest in the fix/feature and/or is able to reproduce the issue. >From what I can see, mkanat is following the same path, i.e. I see him doing a lot of fixes on checkin himself to not demotivate valuable contributors/contributions. But if we have no time and/or interest to do the fixes ourselves, we have no other choices than to r- the patch and to ask for an updated one. LpSolit From gerv at mozilla.org Wed Jan 20 13:34:55 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 20 Jan 2010 13:34:55 +0000 Subject: Easier Patch Submission? Is it possible? In-Reply-To: References: Message-ID: To add to what LpSolit said: On 19/01/10 19:05, Michael Thomas wrote: > The main issue I can really > see is that there are no version tags within the files themselves. If those > version numbers were added it should be fairly trivial to automatically > generate the patch files against the corresponding base file. Very old source code management systems, such as RCS/SCCS if memory serves me correctly, put version tag numbers in the source file. However, all that they did was ensure more frequent merge conflicts. Metadata and data are best kept separate, and every modern SCM, even CVS, does that by default (although CVS has the option of working the RCS way). I agree with LpSolit's conclusion: when we can, we should do "fixed on checkin" and so on for new contributors to prevent lots of frustrating and delay-inducing rounds of tiny tweaks. But asking people to produce a diff isn't the biggest obstacle by any means. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Jan 20 13:37:47 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 20 Jan 2010 13:37:47 +0000 Subject: Results of Community Research In-Reply-To: References: <4B55155F.3060007@bugzilla.org> Message-ID: On 19/01/10 09:33, Fr?d?ric Buclin wrote: > Wow, security work should have the highest priority, IMO, because they > often block releases (same for blockers). And we from time to time delay > checkins because we are near a release date and we don't want to mess > the code too late in the game. So having releases done faster would help > focusing on new contributors once we have security bugs and blockers out > of our plate. At least, that's my point of view. To be clear, I'm since > early December ignoring *all* requests for review which aren't about > blockers, security bugs or targeted 3.6 or older, no matter who the > requester is or how cool the new feature is. My remaining free time and > motivation are devoted to QA. The sooner 3.6rc1 and 3.6 are released, > the sooner I will accept looking at other contributions again. I think that if Max is prioritizing patches from new contributors, then not everyone else needs to. (If you are able to pass on reviews of such patches that get sent to you, so much the better.) If he's doing new people as the highest priority, and you are doing security, then that's teamwork :-) However, you can understand, I hope, that if _everyone_ adopted the prioritization scheme you have, then it would be very hard for anyone new to enter the community. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Jan 20 13:42:59 2010 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 20 Jan 2010 13:42:59 +0000 Subject: Including and excluding fields In-Reply-To: References: Message-ID: On 15/01/10 21:28, Max Kanat-Alexander wrote: > Hmm. Okay, so here's my proposal: "Improve include_fields and exclude_fields to accept _default, _all and _custom keywords" https://bugzilla.mozilla.org/show_bug.cgi?id=540818 "Change include_fields and exclude_fields to recognise sub-fields (e.g. attachments.data)" https://bugzilla.mozilla.org/show_bug.cgi?id=540819 Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From jochen.wiedmann at gmail.com Wed Jan 20 13:47:18 2010 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Wed, 20 Jan 2010 14:47:18 +0100 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <4B56F5FE.4000906@gmail.com> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> <4B56F5FE.4000906@gmail.com> Message-ID: 2010/1/20 Fr?d?ric Buclin : > To avoid these problems, what I do more and more often is either 1) r+ > the patch and mention that I will do the numerous "fixes on checkin" > myself, to avoid extra loops and to not demotivate the contributor, or > 2) I ask the contributor if he agrees that I finalize his patch myself, > so that he doesn't think I'm trying to steal his work and get all the > credit. I think that's a better choice, but this requires some free time > from the reviewer to update and test the patch, and is only doable if > the reviewer has a real interest in the fix/feature and/or is able to > reproduce the issue. Both sound like good compromises to me. > From what I can see, mkanat is following the same path, i.e. I see him > doing a lot of fixes on checkin himself to not demotivate valuable > contributors/contributions. But if we have no time and/or interest to do > the fixes ourselves, we have no other choices than to r- the patch and > to ask for an updated one. Certainly. I'd never suggest the above policy if it adds time to the committer. Jochen -- Germanys national anthem is the most boring in the world - how telling! From eblack at higherone.com Wed Jan 20 14:29:39 2010 From: eblack at higherone.com (Eric Black) Date: Wed, 20 Jan 2010 09:29:39 -0500 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <4B56F5FE.4000906@gmail.com> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> ,<4B56F5FE.4000906@gmail.com> Message-ID: <4F91EB003F5C784084736E717AB5AFCA19FC8EC386@mail02.higherone.com> > Le 20. 01. 10 09:26, Jochen Wiedmann a ?crit : > > At that time, my proposal was refused, mostly with the argument that > > the contributior "feels better", because the patch is "100% his". > > I remember this discussion. There were two points in favor of several > iterations: the first one is the one you mentioned, i.e. letting the > contributor attach a complete and correct patch, so he really has the > feeling that he did the whole job himself (and to get all the merit). > The second point was to make contributors "better", i.e. they understand > the points we would like them to make better so that they do it right > the next time they contribute. As a new contributor, I feel the second point to be of greater importance since the better understanding of the reasons things are done the way they are will make it easier for subsequent patches, *but also* makes a coder better. From lpsolit at gmail.com Wed Jan 20 14:42:14 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 20 Jan 2010 15:42:14 +0100 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <4F91EB003F5C784084736E717AB5AFCA19FC8EC386@mail02.higherone.com> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> ,<4B56F5FE.4000906@gmail.com> <4F91EB003F5C784084736E717AB5AFCA19FC8EC386@mail02.higherone.com> Message-ID: <4B571646.2040601@gmail.com> Le 20. 01. 10 15:29, Eric Black a ?crit : > As a new contributor, I feel the second point to be of greater > importance since the better understanding of the reasons things are > done the way they are will make it easier for subsequent patches, > *but also* makes a coder better. Our problem here is to determine whether a contributor is willing to follow our guidelines and to better understand Bugzilla internals, in which case we can r- his patch without too much worry, or whether he just want to contribute something which fixes his problem and doesn't care too much about our guidelines because he doesn't really plan to contribute anymore, in which case we shouldn't simply r- his patch and hope he will update it to make us happy. We should still r- it, probably, but do something with his patch if it's not too far from what we expected. When it's your first contribution, it's really hard for us to determine to which category you belong. It's easier when new contributors "meet" us on IRC at the same time, because we know they are somewhat interested to belong to our community, or at least to update their patch if needed. LpSolit From emmanuel.seyman at club-internet.fr Wed Jan 20 15:23:18 2010 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 20 Jan 2010 16:23:18 +0100 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <4B571646.2040601@gmail.com> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> <4B56F5FE.4000906@gmail.com> <4F91EB003F5C784084736E717AB5AFCA19FC8EC386@mail02.higherone.com> <4B571646.2040601@gmail.com> Message-ID: <20100120152318.GA17115@orient.maison.lan> * Fr?d?ric Buclin [20/01/2010 15:50] : > > We should still r- it, > probably, but do something with his patch if it's not too far from what > we expected. Actually, I'm convinced that we already have a fair number of patches that are in this situation : they've been reviewed r-, they only need a little work to pass yet they're sitting there waiting to bitrot. Emmanuel _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Wed Jan 20 15:32:07 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 20 Jan 2010 16:32:07 +0100 Subject: Easier Patch Submission? Is it possible? In-Reply-To: <20100120152318.GA17115@orient.maison.lan> References: <6b9407351001191105u6b57c722q88401815d66a8068@mail.gmail.com> <4B560670.4060707@gmail.com> <6b9407351001191137u4cdaffffr8ad8d6dfec4e9493@mail.gmail.com> <4B560B75.60600@gmail.com> <4B56F5FE.4000906@gmail.com> <4F91EB003F5C784084736E717AB5AFCA19FC8EC386@mail02.higherone.com> <4B571646.2040601@gmail.com> <20100120152318.GA17115@orient.maison.lan> Message-ID: <4B5721F7.6060102@gmail.com> Le 20. 01. 10 16:23, Emmanuel Seyman a ?crit : > Actually, I'm convinced that we already have a fair number of patches > that are in this situation : they've been reviewed r-, they only need a > little work to pass yet they're sitting there waiting to bitrot. Feel free to update and repost them! :) More seriously, there are so many bugs/features I want to work on that I'm not even able to do everything I want to do. So each, even small, additional patch takes me away from what I would like to do first. And this also applies to other core developers. So maybe some new contributors could take them as a starting point? Hard to say. LpSolit From lpsolit at gmail.com Wed Jan 20 17:15:27 2010 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 20 Jan 2010 18:15:27 +0100 Subject: Inactive bugs reassigned to nobody Message-ID: <4B573A2F.3020106@gmail.com> Hi all, In case you got a lot of bugspam these last 70 minutes, just know that I reassigned 108 inactive bugs to "nobody" (the default assignee) so that new contributors know they can work on them. Lpsolit From sspeiche at gmail.com Thu Jan 21 14:37:52 2010 From: sspeiche at gmail.com (SteveS) Date: Thu, 21 Jan 2010 06:37:52 -0800 (PST) Subject: Bug Relationships References: Message-ID: On Jan 12, 4:43?am, Olivier Berger wrote: > Hi. > > Le lundi 11 janvier 2010 ? 17:30 +0000, Gervase Markham a ?crit : > > > [I've had this idea kicking around in my head for a while, but I don't > > think I've ever written it up properly for discussion. So here it is. > > It's inspired by a feature on a proprietary bug tracking system I used > > to use. It was generally terrible, but this was good.] > > > I think that we should replace dependencies, See Also, and perhaps > > duplicate marking too with a more generic system of Bug Relationships. > > That'd be great. > > I'd advise you to have a look at what's cooking for OSLC-CM [0] V2 [1] > attributes definition in order to eventually adopt the same wording as > what will be defined for the next version of that standard. > > Of course this would be in prevision of the day when bugzilla becomes > compatible with OSLC-CM :https://bugzilla.mozilla.org/show_bug.cgi?id=519177 > > My 2 cents, > > [0] :http://open-services.net/bin/view/Main/CmHome > [1] :http://open-services.net/bin/view/Main/CmResourceDefinitionsV2 To add onto Olivier's post, I think in order to achieve what you laid out you'd need (at some point) a standard way of expressing and managing these relationships to be able to achieve two of the design goals you have: 1. the reciprocal language for each relationship would also be defined 2. where you would select a relationship, and then enter a bug number or a URL to a bug in another bug system (Bugzilla or otherwise) If you are creating this link in the origin bug tracker, you need a way for the remote bug tracker to be aware of this link and what type it is in order to achieve #1. These are some of the scenarios we are looking at with OSLC-CM [0] that Olivier points out. The common attributes for resource definitions could be useful for import and export, I think there is a bigger role that OSLC-CM could play in the approach that was outlined. Overall the approach laid out by Gerv sounds great. Regards, Steve Speicher _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From kar at cray.com Thu Jan 21 15:05:05 2010 From: kar at cray.com (Kent Rogers) Date: Thu, 21 Jan 2010 09:05:05 -0600 Subject: Self-Introduction: Kent Rogers Message-ID: <20100121150505.GA30134@cray.com> Name: Kent Rogers IRC: mrbball Location: St. Paul, MN, USA I've been unofficially contributing to Bugzilla for a bit and I figured it was time to make it official. I've been working on dev tools (testing, SCM, bug tracking, release mgmt) for most of the last 20 years at Cray Research, Silicon Graphics, and now Cray Inc. At Cray, we decided to switch from an ancient, proprietary bug tracking system to Bugzilla in 2007 (over TeamTrack, thank goodness!) and I've been customizing/maintaining it since. At SGI (early 2000s) we had a proprietary bug tracker that was extremely similar to Bugzilla but had a couple very nice features that Bugzilla doesn't. Some day maybe I'll get around to remembering what they were and filing some bugs ... I'm kind of a jack-of-all-trades, knowing enough different tools & technologies (Apache, Perl, Python, SQL, Subversion, TT, ...) to be dangerous and implement a fair number of features/fixes. Unfortunately I don't quite know enough to always be convinced they are the *best* solutions. I'm working on it. ;-) I've obviously focused on the features that are highest priority in-house (usually UI-related) and will continue to do so, but those features seem to be increasingly applicable to the base. I've added a few patches here and there lately and will continue contributing as often as possible/applicable. Right now I'm working on patches for bugs 286041 & 514618 that I plan on contributing soon. Can someone assign those bugs to me? Thanks. - Kent From Callek at gmail.com Sat Jan 23 05:08:26 2010 From: Callek at gmail.com (Justin Wood (Callek)) Date: Sat, 23 Jan 2010 00:08:26 -0500 Subject: Bazaar for Mercurial Users Message-ID: <-K2dnaxZ7KLRGcfWnZ2dnUVZ_qmdnZ2d@mozilla.org> I just came across a page that might be useful for anyone looking to develop Bugzilla in the future. We all know that Most of Mozilla is using hg (or svn) these days, but bugzilla is going bzr. (To which I do not [yet] know), though if you work in other Mozilla areas you should by now, have a grasp of hg. So: http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-hg-users.html -- ~Justin Wood (Callek) _______________________________________________ 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 Jan 25 11:40:12 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 25 Jan 2010 03:40:12 -0800 Subject: Hold CVS Checkins, Moving to Bzr Message-ID: <4B5D831C.3010200@bugzilla.org> Hey folks. While I was working on the bzr-to-cvs mirroring script, I realized that there had been a longstanding bug in the cvs-to-bzr script--namely, that I had been mirroring the Mozilla CVS to my server via rsync, but I had forgotten to specify --delete on the rsync command line, so when CVS moved files around on the Mozilla CVS Server, they didn't get moved around properly in my mirror. This is why all the current bzr repositories contain files that we deleted in CVS. Naively, I thought that I could just add --delete to the rsync command line and everything would be fine! Unfortunately, this broke the cvs-to-bzr mirror in a way that I can't really recover from now. That means that any further CVS checkins will cause the bzr mirror to go out of sync permanently. Though it's true that we could overcome this for the next few days by manually committing to the bzr mirror, I thought that it might instead be better to simply take this opportunity to switch to bzr, since everything is actually ready except the bzr-to-cvs mirroring script, which is almost done. So if it's OK with everybody, I think that we'll switch to bzr in 24 to 48 hours. I'll post information all about the bzr server once everything is ready. Any objections to that plan? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Mon Jan 25 11:58:35 2010 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Mon, 25 Jan 2010 12:58:35 +0100 Subject: Hold CVS Checkins, Moving to Bzr In-Reply-To: <4B5D831C.3010200@bugzilla.org> References: <4B5D831C.3010200@bugzilla.org> Message-ID: <4B5D876B.8030209@gmail.com> Le 25. 01. 10 12:40, Max Kanat-Alexander a ?crit : > Any objections to that plan? Yes! Now is a bad time to move as we are close to security releases. I don't think it's the right time to play with the bzr or CVS repo. We should move after these releases are out, as discussed at our last meeting earlier this month. LpSolit From mkanat at bugzilla.org Mon Jan 25 12:00:18 2010 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 25 Jan 2010 04:00:18 -0800 Subject: Hold CVS Checkins, Moving to Bzr In-Reply-To: <4B5D876B.8030209@gmail.com> References: <4B5D831C.3010200@bugzilla.org> <4B5D876B.8030209@gmail.com> Message-ID: <4B5D87D2.90801@bugzilla.org> On 01/25/2010 03:58 AM, Fr?d?ric Buclin wrote: > Yes! Now is a bad time to move as we are close to security releases. I > don't think it's the right time to play with the bzr or CVS repo. We > should move after these releases are out, as discussed at our last > meeting earlier this month. Okay, but I'm going to have to manually sync every commit we do to CVS from here on out, until we move. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mockodin at gmail.com Thu Jan 28 00:54:26 2010 From: mockodin at gmail.com (Michael Thomas) Date: Wed, 27 Jan 2010 16:54:26 -0800 Subject: Bugzilla::WebServices::XMLRPC and User.login Message-ID: <6b9407351001271654g63db9463kd94caefe829bae6f@mail.gmail.com> Ran in to a bit of a bug, but I am unsure where the bug lives. Issue: server->call('User.login',... syntax works fine, I have a cookie_jar for storing the cookies and have confirmed 'a' cookie is being created. This however is also the problem, only one cookie is recorded client side, dumping the return header shows that only Bugzilla_logincookie is being returned. I played with commenting out set_cookie in Bugzilla::Auth::Persist::Cookie for 'Bugzilla_logincookie' and ran that code again, low and behold there came Bugzilla_login. Next I added another set_cookie immediately after Bugzilla_login and Bugzilla_logincookie, ran User.login and and only got my new 'test' cookie. For what ever reason only the last defined set_cookie seems to be passing to the client. Any ideas? From nefthy at option-it.de Fri Jan 29 01:07:33 2010 From: nefthy at option-it.de (Niko Efthymiou) Date: Fri, 29 Jan 2010 02:07:33 +0100 Subject: Bugzilla-svn integration Message-ID: <4B6234D5.7050806@option-it.de> Hi all, I hacked a litle script to integrate svn and bugzilla a bit. It parses the svn log messages and post comments to the bugs mentioned therein. # or fixed # at the start of the line and all following lines till the next marker are append to that bug along with some revision information and the changed files. It seems to work quite nicely, but I was wondering if any of you would like to take a look and since I am less than familiar with the bugzilla internals, tell me if I am doing anything stupid. You can find the script at: http://option-it.de/svn_bz_hook.pl A short description in german at: http://option-it.de/software/subversion_bugzilla_integration/ Please not that it is not very well tested yet and I would not recomend using it on mission critical systems. Greeting, Niko _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla