From mkanat at bugzilla.org Fri Sep 4 22:28:25 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 04 Sep 2009 15:28:25 -0700 Subject: Moving Away From CVS: A Vote Message-ID: <4AA19489.80708@bugzilla.org> Okay, we've had this discussion before, but this time, we have to actually do it. We've been on CVS for too long--we may be the only remaining major Mozilla project still using CVS for primary development. We're certainly the only major open source project that I know of and interact with regularly that still uses CVS. The only reason that we haven't moved yet is that we have a conflict: * Bzr is known by the Bugzilla developers and is technically superior to Hg in almost every way except scalability (and even that may be fixed as of bzr 1.16). * Hg is supported by the Mozilla Corporation, has an extensive infrastructure at Mozilla, and is already in use by Mozilla localizers. If you doubt that bzr is technically superior, here are a few points: * Compare the standard web interface to Hg (hgweb: http://hg.mozilla.org/ ) to the standard web interface for bzr (loggerhead: http://bzr.bugzilla.org/ ). * bzr has a *major* release nearly every month. (See the release notes: http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html ) Mercurial's major releases are roughly 3 to 4 months apart (and there were 9 months from 1.0 to 1.1). * bzr tracks directory renames as well as file renames, meaning that it doesn't show hundreds of files being renamed if you rename a directory--it only shows the directory name changing. (This also means that bzr can show the existence of empty directories in its changeset history, and Mercurial cannot.) * The commands used in bzr for a CVS-like workflow are *identical* to the commands used in CVS, drastically lessening the learning curve for users migrating from CVS. However, Hg is supported by the Mozilla Corporation and they already have extensive infrastructure around it. Also, as Cedric has pointed out in the past, localizers are already using Hg. To resolve the conflict, I am ***TAKING A VOTE***: * Respond to this email either publicly (if you want to make an argument) or privately with your preference stated AT THE VERY TOP OF THE EMAIL. Anybody who is currently contributing to the Bugzilla Project or interacting with our CVS is eligible to vote. (If you are not a current contributor, please state your interest when voting.) I will count all public and private votes, and we will move to whichever VCS receives a simple majority (51%) of the received votes. HOWEVER, if there is a clear consensus (75% or greater) among the reviewers (and a significant number of reviewers vote--more than just 3 or 4), then there is a possibility we will just go with the reviewer consensus, though the non-reviewer votes will also be taken into account. If you have any questions about the voting or about either VCS, feel free to respond here publicly and I'd be happy to clarify. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Fri Sep 4 22:35:56 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 04 Sep 2009 15:35:56 -0700 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19489.80708@bugzilla.org> References: <4AA19489.80708@bugzilla.org> Message-ID: <4AA1964C.9070502@bugzilla.org> I am voting for bzr, because it would be difficult for me to accept the more limited basic feature set and slightly awkward UI of Hg and hgweb, after using bzr and loggerhead for a long time, and because we are already using bzr for Bugzilla QA. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From wurblzap at gmail.com Fri Sep 4 22:38:53 2009 From: wurblzap at gmail.com (Marc Schumann) Date: Sat, 5 Sep 2009 00:38:53 +0200 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19489.80708@bugzilla.org> References: <4AA19489.80708@bugzilla.org> Message-ID: bzr. - I use bzr for bz de l10n - bzr works really well on Win - I'm told Hg is a pain on Win - I've never used Hg Regards Marc From lpsolit at gmail.com Fri Sep 4 22:39:54 2009 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sat, 05 Sep 2009 00:39:54 +0200 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19489.80708@bugzilla.org> References: <4AA19489.80708@bugzilla.org> Message-ID: <4AA1973A.5000005@gmail.com> Le 05. 09. 09 00:28, Max Kanat-Alexander a ?crit : > The only reason that we haven't moved yet is that we have a conflict: You forgot quite a few other reasons: * PatchReader (even with my patch applied) cannot display patches with context=file. * Neither Bonsai nor Tinderbox support bzr, AFAIK. As a core developer, I cannot write nor review code without these tools. LpSolit From mkanat at bugzilla.org Fri Sep 4 22:44:07 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 04 Sep 2009 15:44:07 -0700 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA1973A.5000005@gmail.com> References: <4AA19489.80708@bugzilla.org> <4AA1973A.5000005@gmail.com> Message-ID: <4AA19837.1010004@bugzilla.org> On 09/04/2009 03:39 PM, Fr?d?ric Buclin wrote: > * Neither Bonsai nor Tinderbox support bzr, AFAIK. Bonsai doesn't need bzr support, because we have loggerhead, which does pretty much everything thing that Bonsai does. We can make the tinderbox clients support bzr really easily, and I think that's all that's really critical for us to move to bzr. As far as the PatchReader stuff goes, we don't have that for Hg either, so I don't think we should hold up on that. In any case, do you have a vote for Hg vs. bzr? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Fri Sep 4 22:54:07 2009 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sat, 05 Sep 2009 00:54:07 +0200 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19837.1010004@bugzilla.org> References: <4AA19489.80708@bugzilla.org> <4AA1973A.5000005@gmail.com> <4AA19837.1010004@bugzilla.org> Message-ID: <4AA19A8F.90105@gmail.com> Le 05. 09. 09 00:44, Max Kanat-Alexander a ?crit : > Bonsai doesn't need bzr support, because we have loggerhead, which > does pretty much everything thing that Bonsai does. Except it doesn't display the bug ID + summary when hovering a commit ID. This would need to be hacked to do that. > As far as the PatchReader stuff goes, we don't have that for Hg > either, so I don't think we should hold up on that. We definitely should. I *always* do reviews in context=file mode. Not being able to do this anymore is a showstopper for me. I don't care we don't have that for Hg either; we do have it for CVS, and that's all which is important to me. > In any case, do you have a vote for Hg vs. bzr? I have one, yes, but my issues mentioned above make my vote irrelevant for now. LpSolit From guy.pyrzak at gmail.com Fri Sep 4 23:04:44 2009 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Fri, 4 Sep 2009 16:04:44 -0700 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19A8F.90105@gmail.com> References: <4AA19489.80708@bugzilla.org> <4AA1973A.5000005@gmail.com> <4AA19837.1010004@bugzilla.org> <4AA19A8F.90105@gmail.com> Message-ID: I don't know anything about patchreader library, but could someone write the equiv for either Hg or bzr? Hg vs Bzr is kinda hard for me since I've never used Hg and I've been using BZR for my "real" job more or less every day... so I'm kinda bias. -Guy 2009/9/4 Fr?d?ric Buclin > Le 05. 09. 09 00:44, Max Kanat-Alexander a ?crit : > > Bonsai doesn't need bzr support, because we have loggerhead, which > > does pretty much everything thing that Bonsai does. > > Except it doesn't display the bug ID + summary when hovering a commit > ID. This would need to be hacked to do that. > > > > As far as the PatchReader stuff goes, we don't have that for Hg > > either, so I don't think we should hold up on that. > > We definitely should. I *always* do reviews in context=file mode. Not > being able to do this anymore is a showstopper for me. I don't care we > don't have that for Hg either; we do have it for CVS, and that's all > which is important to me. > > > > In any case, do you have a vote for Hg vs. bzr? > > I have one, yes, but my issues mentioned above make my vote irrelevant > for now. > > LpSolit > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Fri Sep 4 22:58:05 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 04 Sep 2009 15:58:05 -0700 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19A8F.90105@gmail.com> References: <4AA19489.80708@bugzilla.org> <4AA1973A.5000005@gmail.com> <4AA19837.1010004@bugzilla.org> <4AA19A8F.90105@gmail.com> Message-ID: <4AA19B7D.4070301@bugzilla.org> On 09/04/2009 03:54 PM, Fr?d?ric Buclin wrote: > Le 05. 09. 09 00:44, Max Kanat-Alexander a ?crit : > We definitely should. I *always* do reviews in context=file mode. Not > being able to do this anymore is a showstopper for me. I don't care we > don't have that for Hg either; we do have it for CVS, and that's all > which is important to me. Okay. Well, let's assume that you resolve this (since you are totally capable of doing so, being the module owner) before we move. What would your vote be? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Fri Sep 4 23:09:56 2009 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sat, 05 Sep 2009 01:09:56 +0200 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19B7D.4070301@bugzilla.org> References: <4AA19489.80708@bugzilla.org> <4AA1973A.5000005@gmail.com> <4AA19837.1010004@bugzilla.org> <4AA19A8F.90105@gmail.com> <4AA19B7D.4070301@bugzilla.org> Message-ID: <4AA19E44.2050200@gmail.com> Le 05. 09. 09 00:58, Max Kanat-Alexander a ?crit : > What would your vote be? bzr. I already use it for Selenium, and used it with ES. LpSolit From cedric.corazza at gmail.com Sat Sep 5 11:14:47 2009 From: cedric.corazza at gmail.com (=?UTF-8?B?Q8OpZHJpYyBDb3Jhenph?=) Date: Sat, 05 Sep 2009 13:14:47 +0200 Subject: Moving Away From CVS: A Vote In-Reply-To: References: <4AA19489.80708@bugzilla.org> Message-ID: The embryo of l10n how-to for Bugzilla didn't bring us new locales AFAIK, and I guess the current localizers are tech savvy enough to switch from VCS tool. Thus, the rationale to stick with Mercurial seems to be weaker in that context. Though it will be yet another tool to play with, the mentioned benefits seem this switch is worthwhile. So, I would vote to switch to Bazaar. I would like to have some other localizers' opinion though. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From justdave at bugzilla.org Sat Sep 5 21:23:17 2009 From: justdave at bugzilla.org (David Miller) Date: Sat, 05 Sep 2009 17:23:17 -0400 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19489.80708@bugzilla.org> References: <4AA19489.80708@bugzilla.org> Message-ID: <4AA2D6C5.7010608@bugzilla.org> I also personally prefer Bzr over Hg. We're using it already for bmo's local hacks, and to me the command set just seems more friendly than Hg. The scalability/performance issues that Mozilla ran into don't really affect us because our codebase isn't as huge as theirs. If we end up going with this, I'll see to it that we get "real" support for it on Mozilla's infrastructure (rather than the "nothing more than a bare repo" that we have for bmo currently, that shares a server with one of the staging boxes). Max Kanat-Alexander wrote on 9/4/09 6:28 PM: > Okay, we've had this discussion before, but this time, we have to > actually do it. We've been on CVS for too long--we may be the only > remaining major Mozilla project still using CVS for primary development. > We're certainly the only major open source project that I know of and > interact with regularly that still uses CVS. > > The only reason that we haven't moved yet is that we have a conflict: > > * Bzr is known by the Bugzilla developers and is technically > superior to Hg in almost every way except scalability (and even that may > be fixed as of bzr 1.16). > > * Hg is supported by the Mozilla Corporation, has an extensive > infrastructure at Mozilla, and is already in use by Mozilla localizers. > > If you doubt that bzr is technically superior, here are a few points: > > * Compare the standard web interface to Hg (hgweb: > http://hg.mozilla.org/ ) to the standard web interface for bzr > (loggerhead: http://bzr.bugzilla.org/ ). > > * bzr has a *major* release nearly every month. (See the release > notes: http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html ) > Mercurial's major releases are roughly 3 to 4 months apart (and there > were 9 months from 1.0 to 1.1). > > * bzr tracks directory renames as well as file renames, meaning that > it doesn't show hundreds of files being renamed if you rename a > directory--it only shows the directory name changing. (This also means > that bzr can show the existence of empty directories in its changeset > history, and Mercurial cannot.) > > * The commands used in bzr for a CVS-like workflow are *identical* > to the commands used in CVS, drastically lessening the learning curve > for users migrating from CVS. > > However, Hg is supported by the Mozilla Corporation and they already > have extensive infrastructure around it. Also, as Cedric has pointed out > in the past, localizers are already using Hg. > > To resolve the conflict, I am ***TAKING A VOTE***: > > * Respond to this email either publicly (if you want to make an > argument) or privately with your preference stated AT THE VERY TOP OF > THE EMAIL. Anybody who is currently contributing to the Bugzilla Project > or interacting with our CVS is eligible to vote. (If you are not a > current contributor, please state your interest when voting.) > > I will count all public and private votes, and we will move to > whichever VCS receives a simple majority (51%) of the received votes. > HOWEVER, if there is a clear consensus (75% or greater) among the > reviewers (and a significant number of reviewers vote--more than just 3 > or 4), then there is a possibility we will just go with the reviewer > consensus, though the non-reviewer votes will also be taken into account. > > If you have any questions about the voting or about either VCS, feel > free to respond here publicly and I'd be happy to clarify. > > -Max -- 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 after.fallout at gmail.com Sat Sep 5 22:43:22 2009 From: after.fallout at gmail.com (Bill Barry) Date: Sat, 05 Sep 2009 16:43:22 -0600 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19489.80708@bugzilla.org> References: <4AA19489.80708@bugzilla.org> Message-ID: <4AA2E98A.2040603@gmail.com> Max Kanat-Alexander wrote: > Anybody who is currently contributing to the Bugzilla Project or > interacting with our CVS is eligible to vote. (If you are not a > current contributor, please state your interest when voting.) Not a contributor currently so my vote doesn't really count but I would vote Mercurial. There is significant fear that bazaar will break compatibility in upgrades (it has already done so before). As someone who only rarely updates Bugzilla and even far more rarely updates underlying system infrastructure (at that level bureaucracy is simply to much in the way) what guarantees do I have that "bzr up" will continue to work a year from now the next time I update Bugzilla? Any other reasons I have for wanting Mercurial are not things this community should care about (I have infrastructure and tooling support built up for Mercurial but not Bzr; I am active in the Mercurial dev community; etc.). Your FUD about Bzr being superior is BS: * Comparing the interface is merely subjective. I very much like the Hg interface better for one. * Bzr has a new release every month because it finds major deficiencies every month. It also doesn't have minor releases and every single release has had breaking changes. In a corporate environment there is no reasonable suggestion for bzr to remain in any state of stability if you are interacting with repositories in external environments. * While this is true, it is also pointless. I have yet to see any reason why you might need to track empty directories which couldn't be accomplished by tracking an empty file in a directory. * The mercurial commands are not significantly different than CVS or SVN. As far as superiority: last I checked over 90% of the commits to Bzr were from 2 or 3 people employed by Canonical. There literally was not a developer community. Regardless, all I really want is for our benevolent dictator for the time being to decide and make the move (and to see a testopia repository that keeps up to date with the changes as they happen). From mkanat at bugzilla.org Sun Sep 6 01:22:20 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 05 Sep 2009 18:22:20 -0700 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA2E98A.2040603@gmail.com> References: <4AA19489.80708@bugzilla.org> <4AA2E98A.2040603@gmail.com> Message-ID: <4AA30ECC.7050209@bugzilla.org> On 09/05/2009 03:43 PM, Bill Barry wrote: > There is significant fear that bazaar will break compatibility in > upgrades (it has already done so before). The fear is unfounded. Bazaar has never actually *broken compatibility* in its upgrades--at least not that I recall since 1.0. However, if administrators of bzr servers choose to convert their repositories to a format that older versions of Bazaar don't support, then it's true that older versions of Bazaar can no longer access those repositories. There would probably be a decision made when we switch to bzr what repository format we were going to use, and then we'd stick with it until such a time as all reasonably available versions of bzr supported a newer repository format (most likely several years). Also, it's looking like the 2a format may indeed be the last word in formats--we'll see. At the least, the packs format is good enough for what we do with Bugzilla, so we may not ever have to change. > * Bzr has a new release every month because it finds major deficiencies > every month. Not really. Read the release notes and see. > It also doesn't have minor releases Not true, it's had some minor releases. See the release notes. There was a 1.6.1, as an example. > * The mercurial commands are not significantly different than CVS or SVN. Except that last time I checked, Mercurial lacks built-in support for bound branches--the fundamental CVS/SVN workflow (that you commit back to the branch you checked out from with a "commit" command). > As far as superiority: last I checked over 90% of the commits to Bzr > were from 2 or 3 people employed by Canonical. There literally was not a > developer community. Here's the current list of top contributors to bzr: https://launchpad.net/bazaar/+topcontributors (Looking at the "Bazaar Branches" section will limit it to just code contributors.) > see a testopia repository > that keeps up to date with the changes as they happen). That would depend more upon somebody committing development resources to Testopia than a VCS switch, although switching to a DVCS would certainly have some advantages. I agree it would be nice, though. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From after.fallout at gmail.com Sun Sep 6 05:01:25 2009 From: after.fallout at gmail.com (Bill Barry) Date: Sat, 05 Sep 2009 23:01:25 -0600 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA30ECC.7050209@bugzilla.org> References: <4AA19489.80708@bugzilla.org> <4AA2E98A.2040603@gmail.com> <4AA30ECC.7050209@bugzilla.org> Message-ID: <4AA34225.7070002@gmail.com> Max Kanat-Alexander wrote: > On 09/05/2009 03:43 PM, Bill Barry wrote: >> There is significant fear that bazaar will break compatibility in >> upgrades (it has already done so before). > > The fear is unfounded. Bazaar has never actually *broken > compatibility* in its upgrades--at least not that I recall since 1.0. > However, if administrators of bzr servers choose to convert their > repositories to a format that older versions of Bazaar don't support, > then it's true that older versions of Bazaar can no longer access > those repositories. I seem to recall some dirstate problem that we had to change how our server was working because we couldn't push to it. A new version came out about a week after we started evaluating bazaar and we decided to upgrade and found that we couldn't push to it. I think it was 1.13 or something like that. We gave up pretty quickly after that. > > There would probably be a decision made when we switch to bzr what > repository format we were going to use, and then we'd stick with it > until such a time as all reasonably available versions of bzr > supported a newer repository format (most likely several years). Also, > it's looking like the 2a format may indeed be the last word in > formats--we'll see. At the least, the packs format is good enough for > what we do with Bugzilla, so we may not ever have to change. > >> * Bzr has a new release every month because it finds major deficiencies >> every month. > > Not really. Read the release notes and see. Every release (and there has been almost 1 a month for the past 2 years) seems to fix at least a dozen bugs. How exactly does there happen to be a new bug fixed every other day on average? How do that many bugs get in the code in the first place? The only ways I can think of are either poor coding or hastily done work (which then gets fixed in some subsequent release; as paid developers on a project from a company with an agenda). Wasn't it you that wrote the post about sucking less every release? > > > It also doesn't have minor releases > > Not true, it's had some minor releases. See the release notes. > There was a 1.6.1, as an example. I am sorry, I was wrong there. > >> * The mercurial commands are not significantly different than CVS or >> SVN. > > Except that last time I checked, Mercurial lacks built-in support > for bound branches--the fundamental CVS/SVN workflow (that you commit > back to the branch you checked out from with a "commit" command). No it doesn't have bound branches; I'll give you that too. I don't think it would be that difficult to write as an extension. I did write an auto-push extension which would function just like bound mode in all cases except for when pushing would first require a merge, but the repository shouldn't be deciding when to merge. That should be a user decision (in Mercurial you may instead want to rebase for instance). My bound mode extension can be found here: https://bitbucket.org/Bill_Barry/boundmode/ In bound mode the centralized workflow would be: setup: 1. hg clone path 2. hg bind path daily use: 3. hg pull --update 4. do work 5. hg ci if ci fails to push (push may be aborted if there already exists a head on the central which you don't have) 3. hg pull --update 4. do work 5. hg ci (fails to push) 6. hg pull --rebase 7. hg push or 6. hg pull 7. hg merge 8. hg ci or 6. hg fetch 7. hg push or 6. hg push --force or any number of other options. The point being that Mercurial shouldn't do any magic like automatic merges (which is why fetch is in an extension and not in the core by default). But there isn't anything that says I couldn't write an extension that does this just like Bazaar does (and in fact it would be a fairly simple extension come to think of it; simply a push/pull/merge/commit loop until it succeeds). > >> As far as superiority: last I checked over 90% of the commits to Bzr >> were from 2 or 3 people employed by Canonical. There literally was not a >> developer community. > > Here's the current list of top contributors to bzr: > > https://launchpad.net/bazaar/+topcontributors > > (Looking at the "Bazaar Branches" section will limit it to just > code contributors.) That has changed considerably since we last looked at it over in the Mercurial list: http://www.selenic.com/pipermail/mercurial/2009-January/023261.html > >> see a testopia repository >> that keeps up to date with the changes as they happen). > > That would depend more upon somebody committing development > resources to Testopia than a VCS switch, although switching to a DVCS > would certainly have some advantages. I agree it would be nice, > though. :-) It will be much easier to maintain a fork than it currently is to maintain a single giant patch. I pity what Greg has to go through each time he attempts to upgrade Testopia. That is a lot of work (which wouldn't be nearly so difficult if it was easier to keep up with the changes). His latest news was a bit unsettling as far as the future for Testopia goes. From mkanat at bugzilla.org Sun Sep 6 08:45:58 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 06 Sep 2009 01:45:58 -0700 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA34225.7070002@gmail.com> References: <4AA19489.80708@bugzilla.org> <4AA2E98A.2040603@gmail.com> <4AA30ECC.7050209@bugzilla.org> <4AA34225.7070002@gmail.com> Message-ID: <4AA376C6.5090502@bugzilla.org> On 09/05/2009 10:01 PM, Bill Barry wrote: > I seem to recall some dirstate problem that we had to change how our > server was working because we couldn't push to it. A new version came > out about a week after we started evaluating bazaar and we decided to > upgrade and found that we couldn't push to it. I think it was 1.13 or > something like that. We gave up pretty quickly after that. Hmm. It's possible there was a problem with dirstate that I never ran into. At this point most repos are in the packs format (same as git uses) and it seems to be working totally fine. > Every release (and there has been almost 1 a month for the past 2 years) > seems to fix at least a dozen bugs. How exactly does there happen to be > a new bug fixed every other day on average? I'd say that probably a lot of what's showing up there is just issues found in Release Candidates. Not sure, though. I haven't encountered a serious issue in bzr in a while. > Wasn't it you that wrote the post about sucking less every release? Hahaha, it was. :-) > No it doesn't have bound branches; I'll give you that too. I don't think > it would be that difficult to write as an extension. [snip] Fair enough. I think bound branches is how we'd recommend users check out Bugzilla code, though, so that they could do "bzr up" and it would "just work" pretty nicely. As a result of having bound branches, bzr also has "lightweight checkouts", which are just a copy of the working tree without the entire history, and a pointer back to the main repo for operations that require the history. Of course, I've never used lightweight checkouts, and I don't know anybody who does. :-) > My bound mode extension can be found here: > https://bitbucket.org/Bill_Barry/boundmode/ Cool. I will look into that if we go with Hg (though the way the voting is going bzr seems pretty likely). > It will be much easier to maintain a fork than it currently is to > maintain a single giant patch. I pity what Greg has to go through each > time he attempts to upgrade Testopia. That is a lot of work (which > wouldn't be nearly so difficult if it was easier to keep up with the > changes). Yeah, I wouldn't want to maintain Testopia without bzr, myself, if I were a maintainer. Of course, I think the "Testopia For Bugzilla 3.4" may not involve a patch to Bugzilla at all. We'll see. :-) > His latest news was a bit unsettling as far as the future for > Testopia goes. Yeah, agreed, but it's possible we'll see some community member come and pick it up. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From powellc at powelltechs.com Mon Sep 7 06:33:19 2009 From: powellc at powelltechs.com (Charlie Powell) Date: Mon, 7 Sep 2009 02:33:19 -0400 (EDT) Subject: Moving Away From CVS: A Vote In-Reply-To: <974081948.761252305097502.JavaMail.root@zimbra> Message-ID: <2089988841.781252305199278.JavaMail.root@zimbra> Although I don't have much experience with either Hg or Bzr, it appears to me that bzr has more support backing its development and use; Hg just has Mozilla corp. In addition, pending what you said about the commands for bzr being almost exact in comparison to cvs, I'd have to vote for bzr. That said however, I am neither an active contributor nor a user of either bzr or hg, so this vote can count for half :p ----- Original Message ----- From: "Max Kanat-Alexander" To: developers at bugzilla.org Sent: Sunday, September 6, 2009 4:45:58 AM GMT -05:00 US/Canada Eastern Subject: Re: Moving Away From CVS: A Vote On 09/05/2009 10:01 PM, Bill Barry wrote: > I seem to recall some dirstate problem that we had to change how our > server was working because we couldn't push to it. A new version came > out about a week after we started evaluating bazaar and we decided to > upgrade and found that we couldn't push to it. I think it was 1.13 or > something like that. We gave up pretty quickly after that. Hmm. It's possible there was a problem with dirstate that I never ran into. At this point most repos are in the packs format (same as git uses) and it seems to be working totally fine. > Every release (and there has been almost 1 a month for the past 2 years) > seems to fix at least a dozen bugs. How exactly does there happen to be > a new bug fixed every other day on average? I'd say that probably a lot of what's showing up there is just issues found in Release Candidates. Not sure, though. I haven't encountered a serious issue in bzr in a while. > Wasn't it you that wrote the post about sucking less every release? Hahaha, it was. :-) > No it doesn't have bound branches; I'll give you that too. I don't think > it would be that difficult to write as an extension. [snip] Fair enough. I think bound branches is how we'd recommend users check out Bugzilla code, though, so that they could do "bzr up" and it would "just work" pretty nicely. As a result of having bound branches, bzr also has "lightweight checkouts", which are just a copy of the working tree without the entire history, and a pointer back to the main repo for operations that require the history. Of course, I've never used lightweight checkouts, and I don't know anybody who does. :-) > My bound mode extension can be found here: > https://bitbucket.org/Bill_Barry/boundmode/ Cool. I will look into that if we go with Hg (though the way the voting is going bzr seems pretty likely). > It will be much easier to maintain a fork than it currently is to > maintain a single giant patch. I pity what Greg has to go through each > time he attempts to upgrade Testopia. That is a lot of work (which > wouldn't be nearly so difficult if it was easier to keep up with the > changes). Yeah, I wouldn't want to maintain Testopia without bzr, myself, if I were a maintainer. Of course, I think the "Testopia For Bugzilla 3.4" may not involve a patch to Bugzilla at all. We'll see. :-) > His latest news was a bit unsettling as far as the future for > Testopia goes. Yeah, agreed, but it's possible we'll see some community member come and pick it up. -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 Mon Sep 7 09:49:39 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 Sep 2009 10:49:39 +0100 Subject: Moving Away From CVS: A Vote In-Reply-To: References: Message-ID: On 07/09/09 07:33, Charlie Powell wrote: > Although I don't have much experience with either Hg or Bzr, it > appears to me that bzr has more support backing its development and > use; Hg just has Mozilla corp. I'm not sure what you mean by that. Mercurial (Hg) is not a Mozilla Project project, but an independent project, used by many free and open source projects, as listed at the bottom of this page: http://en.wikipedia.org/wiki/Mercurial_%28software%29 Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Mon Sep 7 09:54:58 2009 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 Sep 2009 10:54:58 +0100 Subject: Moving Away From CVS: A Vote In-Reply-To: References: Message-ID: Current vote: undecided. On 04/09/09 23:28, Max Kanat-Alexander wrote: > If you doubt that bzr is technically superior, here are a few points: > > * Compare the standard web interface to Hg (hgweb: > http://hg.mozilla.org/ ) to the standard web interface for bzr > (loggerhead: http://bzr.bugzilla.org/ ). Here's a test for function I've needed from the 3 major Mozilla SCMs recently: can it give me an XML or RSS feed of all changes in the entire repository (or, perhaps, a separate feed for each branch) from a particular date, say, six months ago? > * bzr has a *major* release nearly every month. (See the release notes: > http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html ) > Mercurial's major releases are roughly 3 to 4 months apart (and there > were 9 months from 1.0 to 1.1). I really don't think release frequency is a good metric of software quality. > However, Hg is supported by the Mozilla Corporation and they already > have extensive infrastructure around it. I personally use an abstraction library (Patch Maker - http://www.gerv.net/software/patch-maker/) to work with multiple SCMs, so in one sense it doesn't matter too much. And I've certainly found Hg difficult to use. But my one big concern would be the level of support we would get from Mozilla IT if we asked them to support Yet Another SCM system. If justdave is telling us he can guarantee that Mozilla IT will properly support bzr, then I'll abstain. Otherwise, I vote for Hg. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From sharmaanjali70 at gmail.com Mon Sep 7 09:56:07 2009 From: sharmaanjali70 at gmail.com (Anjali Sharma) Date: Mon, 7 Sep 2009 15:26:07 +0530 Subject: Moving Away From CVS: A Vote In-Reply-To: References: Message-ID: <7a7871850909070256p75314454ydc818a7dd54b2a04@mail.gmail.com> Hi I installed Bugzilla on windows. Now i want to customize the existing template of it according to my requirement. Please let me know how can i do it asap. Thanks Anjali Sharma On Mon, Sep 7, 2009 at 3:19 PM, Gervase Markham wrote: > On 07/09/09 07:33, Charlie Powell wrote: > >> Although I don't have much experience with either Hg or Bzr, it >> appears to me that bzr has more support backing its development and >> use; Hg just has Mozilla corp. >> > > I'm not sure what you mean by that. Mercurial (Hg) is not a Mozilla Project > project, but an independent project, used by many free and open source > projects, as listed at the bottom of this page: > http://en.wikipedia.org/wiki/Mercurial_%28software%29 > > 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 lpsolit at gmail.com Mon Sep 7 10:00:06 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 07 Sep 2009 12:00:06 +0200 Subject: Moving Away From CVS: A Vote In-Reply-To: <7a7871850909070256p75314454ydc818a7dd54b2a04@mail.gmail.com> References: <7a7871850909070256p75314454ydc818a7dd54b2a04@mail.gmail.com> Message-ID: <4AA4D9A6.2020607@gmail.com> Le 07. 09. 09 11:56, Anjali Sharma a ?crit : > I installed Bugzilla on windows. Now i want to customize the existing > template of it according to my requirement. Please let me know how can i do > it asap. You are completely out of topic, and this is not the right place to ask for help, see http://www.bugzilla.org/support/. LpSolit From mkanat at bugzilla.org Mon Sep 7 10:22:06 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 07 Sep 2009 03:22:06 -0700 Subject: Moving Away From CVS: A Vote In-Reply-To: References: Message-ID: <4AA4DECE.10105@bugzilla.org> On 09/07/2009 02:54 AM, Gervase Markham wrote: > Here's a test for function I've needed from the 3 major Mozilla SCMs > recently: can it give me an XML or RSS feed of all changes in the entire > repository (or, perhaps, a separate feed for each branch) from a > particular date, say, six months ago? Yeah, I'm pretty sure you can get Atom limited by date. It's not something that's directly in the UI, but you can just add a few URL parameters that are probably documented somewhere that I could look up for you some time, if you'd like. (Or you could ask in #bzr on FreeNode if the loggerhead devs are around when you ask--beuno is the main one, I think.) > I personally use an abstraction library (Patch Maker - > http://www.gerv.net/software/patch-maker/) to work with multiple SCMs, > so in one sense it doesn't matter too much. I note you added bzr support recently--perhaps basing it on the bzr-loom plugin would make things easier in that department. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Tue Sep 8 17:09:00 2009 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 08 Sep 2009 18:09:00 +0100 Subject: HTTP RESTful API for Bugzilla Message-ID: Hi everyone, To try and help Mozilla Project community members (in particular) innovate on top of Bugzilla, I'm going to be creating an HTTP RESTful API for it. As you know, the Mozilla Project has some rather diverse requirements for its bug-tracking tool; hopefully letting people more easily build new tools and task-specific UIs will ease their pain that the default web interface is not all they'd like it to be. Initially, I'm going to be implementing this as a proxy, which has the advantage that its development can be decoupled from the Bugzilla development cycle and b.m.o. upgrade patterns. On the back end, the proxy will talk to the existing XML-RPC API, or just scrape web pages - whatever it takes. (I've found BZ::Client and WWW::Bugzilla already.) Hopefully, as people start to use the API it'll get refined and become better, and once it's stable, it can be reimplemented on top of Bugzilla itself. The timescales I'm working in are somewhat short, but I would highly value design input from the Bugzilla community. Here is a very rough draft of what such an API might look like. https://wiki.mozilla.org/User:Gerv/BugzillaAPIDesign Please comment! :-) Gerv _______________________________________________ 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 Tue Sep 8 17:05:50 2009 From: ghendricks at novell.com (Gregary Hendricks) Date: Tue, 08 Sep 2009 11:05:50 -0600 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA34225.7070002@gmail.com> References: <4AA19489.80708@bugzilla.org> <4AA2E98A.2040603@gmail.com> <4AA30ECC.7050209@bugzilla.org> <4AA34225.7070002@gmail.com> Message-ID: <4AA63A8E020000D200055094@novprvlin0050.provo.novell.com> >>> On 9/5/2009 at 11:01 PM, in message <4AA34225.7070002 at gmail.com>, Bill Barry wrote: > Max Kanat-Alexander wrote: > > On 09/05/2009 03:43 PM, Bill Barry wrote: > >> see a testopia repository > >> that keeps up to date with the changes as they happen). > > > > That would depend more upon somebody committing development > > resources to Testopia than a VCS switch, although switching to a DVCS > > would certainly have some advantages. I agree it would be nice, > > though. :-) > It will be much easier to maintain a fork than it currently is to > maintain a single giant patch. I pity what Greg has to go through each > time he attempts to upgrade Testopia. That is a lot of work (which > wouldn't be nearly so difficult if it was easier to keep up with the > changes). His latest news was a bit unsettling as far as the future for > Testopia goes. Thanks for the thought. :) I will admit, keeping abreast of what is going on in Bugzilla via CVS even with tools like Bonsai could keep me occupied full time. What I usually end up doing is using a 3 way diff tool like kdiff3 to view the changes to the entire Bugzilla release at once. I then keep a subversion branch that I use to create the patches that I apply to the CVS repository before checking in each change. It certainly isn't ideal and I hope that whatever we come up with is a better solution. And Testopia isn't dead... just hobbled a bit. ;) Greg From ghendricks at novell.com Tue Sep 8 16:54:17 2009 From: ghendricks at novell.com (Gregary Hendricks) Date: Tue, 08 Sep 2009 10:54:17 -0600 Subject: Moving Away From CVS: A Vote In-Reply-To: <4AA19489.80708@bugzilla.org> References: <4AA19489.80708@bugzilla.org> Message-ID: <4AA637D9020000D200055089@novprvlin0050.provo.novell.com> >>> On 9/4/2009 at 04:28 PM, in message <4AA19489.80708 at bugzilla.org>, Max Kanat-Alexander wrote: > Okay, we've had this discussion before, but this time, we have to > actually do it. We've been on CVS for too long--we may be the only > remaining major Mozilla project still using CVS for primary development. > We're certainly the only major open source project that I know of and > interact with regularly that still uses CVS. > I guess I will weigh in. I personally have no experience with either Hg or bzr and much prefer svn to anything else I have used. My biggest concerns are having IDE support, especially Eclipse since that is my preferred development environment. A quick google search shows that there are clients for both. Either way, I am going to have to learn a new VCS, but I trust Max's judgement and I like the fact that a company like Canonical is behind it. I know something of the complexity of managing a distribution and if they can apply that understanding to source control, it must have been pretty well thought out. As for Testopia, I will switch to use whatever Bugzilla goes with as I am rather tied to that platform as it is anyway. Greg From gerv at mozilla.org Tue Sep 8 09:57:25 2009 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 08 Sep 2009 10:57:25 +0100 Subject: Moving Away From CVS: A Vote In-Reply-To: References: Message-ID: On 07/09/09 11:22, Max Kanat-Alexander wrote: > I note you added bzr support recently--perhaps basing it on the bzr-loom > plugin would make things easier in that department. The bzr support is almost entirely untested; I use no bzr repositories apart from the one containing b.m.o., and I haven't used that for some time. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From aliustek at gmail.com Thu Sep 10 10:56:52 2009 From: aliustek at gmail.com (rojanu) Date: Thu, 10 Sep 2009 03:56:52 -0700 (PDT) Subject: Bug 359251: Ability to put a group in any field that accepts a user Message-ID: Is any one working on https://bugzilla.mozilla.org/show_bug.cgi?id=359251. These a feature that we require. If no one is working on it. However, my perl knowledge is not that great. _______________________________________________ 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 Sep 11 03:55:24 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 10 Sep 2009 20:55:24 -0700 Subject: landfill test install cleanup Message-ID: <4AA9CA2C.6090602@bugzilla.org> Hi there. If you have a test install on landfill.bugzilla.org and you aren't using it, please delete it: http://landfill.bugzilla.org/tools/installs.cgi I have currently cleared every installation listed on the front page from the "Patches" list except for the QA and L10N installations. (The installations still exist, just don't appear on the front page of landfill.bugzilla.org.) I'm trying to reduce the number of installations that I have to keep secure on landfill. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Fri Sep 11 04:18:33 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 10 Sep 2009 21:18:33 -0700 Subject: landfill.bugzilla.org/ppm/ is now gone Message-ID: <4AA9CF99.7030908@bugzilla.org> There are no currently-supported versions of Bugzilla that recommend using landfill.bugzilla.org/ppm/ as a repository for Windows packages. Instead, users should be using one of the various publicly-available PPM servers, such as http://theoryx5.uwinnipeg.ca/ppms, as recommended by checksetup.pl. landfill.bugzilla.org/ppm/ has been removed, and all attempts to access it will now return an error. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From leon.kukovec at gmail.com Fri Sep 11 16:04:07 2009 From: leon.kukovec at gmail.com (Leon KUKOVEC) Date: Fri, 11 Sep 2009 18:04:07 +0200 Subject: Bug 359251: Ability to put a group in any field that accepts a user In-Reply-To: References: Message-ID: <6d093fa10909110904h7621551fgd52efe2592c9d5eb@mail.gmail.com> Hi rojanu, On Thu, Sep 10, 2009 at 12:56 PM, rojanu wrote: > Is any one working on https://bugzilla.mozilla.org/show_bug.cgi?id=359251. > These a feature that we require. ?If no one is working on it. However, > my perl knowledge is not that great. I started working on it and have done it up to a certain level - having an extra "CC group" field, etc. Unfortunately this was not accepted and my time at the moment is very limited :-(. There is however a feature that could be used to get the job done - it's called 'user watching'. See if that works for you. -- Best Regards, Leon From mkanat at bugzilla.org Fri Sep 11 18:13:01 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 11 Sep 2009 11:13:01 -0700 Subject: [ANN] Security Advisory for Bugzilla 3.4.1, 3.2.4, and 3.0.8 Message-ID: <4AAA932D.9010700@bugzilla.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Summary ======= Bugzilla is a Web-based bug-tracking system, used by a large number of software projects. * Two SQL injection attacks have been discovered in Bugzilla. One only affects the 3.4 series, while the other affects the 3.0, 3.2, and 3.4 series. These are extremely serious vulnerabilities that must be patched immediately. * When a user would change his password, his new password would be exposed in the URL field of the browser if he logged in right after changing his password. All affected installations are encouraged to upgrade immediately. Vulnerability Details ===================== Class: SQL Injection Versions: 3.3.2 to 3.4.1, 3.5 Fixed In: 3.4.2 Description: It is possible to inject raw SQL into the Bugzilla database via the Bug.search WebService function. This could be used to expose any data stored in the Bugzilla database, including confidential bugs. It is also possible that an attacker could modify or delete any data stored in the Bugzilla database (though we haven't discovered a working exploit that modifies or deletes data). The danger of this exploit is slightly lessened by the fact that Bugzilla's backend does not accept multiple statements separated by a semicolon, so you cannot add additional SQL statements (such as a DELETE or INSERT) using the exploit. However, this is still an extremely critical issue which administrators should patch immediately. References: https://bugzilla.mozilla.org/show_bug.cgi?id=515191 CVE Number: CVE-2009-3125 Class: SQL Injection Versions: 2.23.4 to 3.0.8, 3.1.1 to 3.2.4, 3.3.1 to 3.4.1 Fixed In: 3.0.9, 3.2.5, 3.4.2 Description: It is possible to inject raw SQL into the Bugzilla database via the Bug.create WebService function. This could be used to expose any data stored in the Bugzilla database, including confidential bugs. It is also possible that an attacker could modify or delete any data stored in the Bugzilla database (though we haven't discovered a working exploit that modifies or deletes existing data). The danger of this exploit is slightly lessened by the fact that Bugzilla's backend does not accept multiple statements separated by a semicolon, so you cannot add additional SQL statements (such as a DELETE or UPDATE) using the exploit. This particular hole is much more difficult to exploit than the Bug.search one, due to the fact that the SQL around the insertion point is highly random, making it difficult for an attacker to craft a successful attack. However, even considering these factors, this is still an extremely critical issue which administrators should patch immediately. References: https://bugzilla.mozilla.org/show_bug.cgi?id=515191 CVE Number: CVE-2009-3165 Class: Sensitive Data Exposure Versions: 3.4rc1 to 3.4.1 Fixed In: 3.4.2 Description: When a user reset their password and then logged in immediately afterward, their password would appear in the URL of their browser, which also possibly means that that password would appear in the Bugzilla webserver's logs and in the Referer header of any page whose link was clicked immediately after logging in (although by default Bugzilla only links to itself, on that page). References: https://bugzilla.mozilla.org/show_bug.cgi?id=508189 CVE Number: CVE-2009-3166 Vulnerability Solutions ======================= The fixes for these issues are included in the 3.4.2, 3.2.5, and 3.0.9 releases. Upgrading to a release with the relevant fixes will protect your installation from possible exploits of these issues. If you are unable to upgrade but would like to patch just the individual security vulnerabilities, there are patches available for the individual issues in the Reference URLs of each advisory. Note that if you are running the (unreleased) 3.5 series, it is also affected by all these vulnerabilities and you should update from CVS to get the fixes. Full release downloads, patches to upgrade Bugzilla from previous versions, and CVS upgrade instructions are available at: http://www.bugzilla.org/download/ Credits ======= The Bugzilla team wish to thank the following people/organizations for their assistance in locating, advising us of, and assisting us to fix these issues: Max Kanat-Alexander Bradley Baetz Fr?d?ric Buclin General information about the Bugzilla bug-tracking system can be found at: http://www.bugzilla.org/ Comments and follow-ups can be directed to the mozilla.support.bugzilla newsgroup or the support-bugzilla mailing list. http://www.bugzilla.org/support/ has directions for accessing these forums. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqqky0ACgkQaL2D/aEJPK6wDgCg4bdHsN3jv55/AX3quCO9CSbt dzAAn3udAkmIYSJhK435tVJF3fQXZKxn =Ag67 -----END PGP SIGNATURE----- From aliustek at gmail.com Fri Sep 11 18:53:48 2009 From: aliustek at gmail.com (Ali Irfan Ustek) Date: Fri, 11 Sep 2009 19:53:48 +0100 Subject: Bug 359251: Ability to put a group in any field that accepts a user In-Reply-To: <6d093fa10909110904h7621551fgd52efe2592c9d5eb@mail.gmail.com> References: <6d093fa10909110904h7621551fgd52efe2592c9d5eb@mail.gmail.com> Message-ID: <4AAA9CBC.3000504@gmail.com> Leon KUKOVEC wrote: > Hi rojanu, > > On Thu, Sep 10, 2009 at 12:56 PM, rojanu wrote: >> Is any one working on https://bugzilla.mozilla.org/show_bug.cgi?id=359251. >> These a feature that we require. If no one is working on it. However, >> my perl knowledge is not that great. > > I started working on it and have done it up to a certain > level - having an extra "CC group" field, etc. > > Unfortunately this was not accepted and my time > at the moment is very limited :-(. > > There is however a feature that could be used to get the job done - > it's called 'user watching'. > > See if that works for you. > What is expected. I will have a go at it with my poor perl knowledge. From gerv at mozilla.org Wed Sep 16 16:21:45 2009 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 16 Sep 2009 17:21:45 +0100 Subject: Bug XML output questions Message-ID: I know Bugzilla's XML output has evolved over time; I'm not holding anyone here responsible for its shortcomings :-) Which of these are bugs, which are things we'd have loved to fix but it's too late now, and which are intended? * cclist_accessible and reporter_accessible are not in the XML at all if their value is 0. * keywords is a comma-separated list, unlike other multi-valued fields, which get one tag pair per value. * It doesn't tell you if custom fields are single-valued, or are multiple-valued fields which happen to just contain a single value. You have to call the legal_values API for each field. * There's no way of finding out what possible flags can be set, only the ones which are set. * Same as the question above, but for groups. (Can legal_values help in either of these cases?) Thanks for any light anyone can shed :-) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From fedrushkov at users.sourceforge.net Wed Sep 16 17:18:14 2009 From: fedrushkov at users.sourceforge.net (Vitaly Fedrushkov) Date: Wed, 16 Sep 2009 23:18:14 +0600 Subject: Moving Away From CVS: A Vote In-Reply-To: References: Message-ID: <4AB11DD6.8070209@users.sourceforge.net> My vote is: bzr 1. TortoiseHg is still inferior to TortoiseBzr. TortoiseBzr in turn sucks when compared to TortoiseSVN (for instance, it depends on ugly daemon), but hey, Subversion is so old and mature... 2. TortoiseHg is still broken in handling of cyrillic file names. Probably other UTF-8 languages too. I like Linux and prefer Linux. I just cannot afford to leave Windows. l10n standpoint: 1. Transifex supports both bzr and hg. Had UTF-8 problems at hg backend, current status unknown. 2. Pootle and Translate Toolkit support bzr. Hg is being actively worked on, due to Mozilla's move. 3. Launchpad Rosetta implies bzr. CVS, Subversion and git are import only, with Mercurial 'coming soon'... None the less: if not Bazaar, I will appreciate move to Mercurial: at least because we are _moving_ out of CVS! Regards, Vitaly. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From bugreport at peshkin.net Wed Sep 16 17:37:25 2009 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 16 Sep 2009 10:37:25 -0700 (PDT) Subject: Bug XML output questions Message-ID: <25470.70.167.158.162.1253122645.squirrel@peshkin.net> Wouldn't it help a lot if the interface also permitted retrieving an XSD output? The XSD could be generated with an awareness of flag types, custom fields, etc. Since the XSD itself is an xml format, it could either be treated by the client as an xsd or, more likely, parsed as an xml document that answers many of the questions Gerv points out. > > * It doesn't tell you if custom fields are single-valued, or are multiple-valued fields which happen to just contain a single value. You have to call the legal_values API for each field. > > * There's no way of finding out what possible flags can be set, only the ones which are set. > > * Same as the question above, but for groups. (Can legal_values help in either of these cases?) > From mkanat at bugzilla.org Thu Sep 17 00:37:09 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 16 Sep 2009 17:37:09 -0700 Subject: Bug XML output questions In-Reply-To: <25470.70.167.158.162.1253122645.squirrel@peshkin.net> References: <25470.70.167.158.162.1253122645.squirrel@peshkin.net> Message-ID: <4AB184B5.2010701@bugzilla.org> On 09/16/2009 10:37 AM, Joel Peshkin wrote: > Wouldn't it help a lot if the interface also permitted retrieving an XSD > output? The XSD could be generated with an awareness of flag types, > custom fields, etc. Since the XSD itself is an xml format, it could > either be treated by the client as an xsd or, more likely, parsed as an > xml document that answers many of the questions Gerv points out. The XML interface (which never really had an interface specification) is essentially deprecated in favor of the XML-RPC interface (where we guarantee stability), so I'm not sure we want to add too many new features to it. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Sep 17 00:39:23 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 16 Sep 2009 17:39:23 -0700 Subject: Bug XML output questions In-Reply-To: References: Message-ID: <4AB1853B.10408@bugzilla.org> On 09/16/2009 09:21 AM, Gervase Markham wrote: > * cclist_accessible and reporter_accessible are not in the XML at all if > their value is 0. That sounds like a bug to me. > * keywords is a comma-separated list, unlike other multi-valued fields, > which get one tag pair per value. This is certainly a deficiency, but I suspect we'd be breaking stuff if we changed it now. Keywords guarantee that they won't themselves contain commas, so this is still parseable. > * It doesn't tell you if custom fields are single-valued, or are > multiple-valued fields which happen to just contain a single value. You > have to call the legal_values API for each field. config.cgi's RDF format should tell you the type of each field, I believe. > * There's no way of finding out what possible flags can be set, only the > ones which are set. config.cgi should give you this information. You might want to look at the implementation of Mylyn, if you can read Java, since it handles all these things. > * Same as the question above, but for groups. (Can legal_values help in > either of these cases?) That one might be trickier, since we usually consider group names to be themselves confidential unless you are an admin or a member of the group. The data *might* be in config.cgi. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Thu Sep 17 09:19:16 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Sep 2009 10:19:16 +0100 Subject: Bug XML output questions In-Reply-To: References: <25470.70.167.158.162.1253122645.squirrel@peshkin.net> Message-ID: On 17/09/09 01:37, Max Kanat-Alexander wrote: > The XML interface (which never really had an interface specification) > is essentially deprecated in favor of the XML-RPC interface (where we > guarantee stability), so I'm not sure we want to add too many new > features to it. The XML-RPC interface produces different (and better) XML to the XML interface? Cool! Gerv _______________________________________________ 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 Thu Sep 17 18:15:41 2009 From: ghendricks at novell.com (Gregary Hendricks) Date: Thu, 17 Sep 2009 12:15:41 -0600 Subject: Bug XML output questions In-Reply-To: <4AB184B5.2010701@bugzilla.org> References: <25470.70.167.158.162.1253122645.squirrel@peshkin.net> <4AB184B5.2010701@bugzilla.org> Message-ID: <4AB2286D020000D200056227@novprvlin0050.provo.novell.com> >>> On 9/16/2009 at 06:37 PM, in message <4AB184B5.2010701 at bugzilla.org>, Max Kanat-Alexander wrote: > On 09/16/2009 10:37 AM, Joel Peshkin wrote: > > Wouldn't it help a lot if the interface also permitted retrieving an XSD > > output? The XSD could be generated with an awareness of flag types, > > custom fields, etc. Since the XSD itself is an xml format, it could > > either be treated by the client as an xsd or, more likely, parsed as an > > xml document that answers many of the questions Gerv points out. > > The XML interface (which never really had an interface specification) > is essentially deprecated in favor of the XML-RPC interface (where we > guarantee stability), so I'm not sure we want to add too many new > features to it. Actually, I think there is still value in having an XML specification, and I have intended to submit an XSD to that effect soon. The XML-RPC is still too limited to allow mass update or import of bugs, and I think having an XML representation can be useful in other ways as well. Greg From mkanat at bugzilla.org Thu Sep 17 22:18:23 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 17 Sep 2009 15:18:23 -0700 Subject: Bug XML output questions In-Reply-To: References: <25470.70.167.158.162.1253122645.squirrel@peshkin.net> Message-ID: <4AB2B5AF.2090903@bugzilla.org> On 09/17/2009 02:19 AM, Gervase Markham wrote: > The XML-RPC interface produces different (and better) XML to the XML > interface? Cool! It certainly produces more consistent output. However, it's not as complete yet. You're welcome to file bugs for additional information you'd like to see out of it, and we definitely plan to expand it as time goes on. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From zerhash at gmail.com Fri Sep 18 21:23:03 2009 From: zerhash at gmail.com (j r) Date: Fri, 18 Sep 2009 14:23:03 -0700 Subject: Self-Introduction: Jason Richmond Message-ID: <3fe19be60909181423g572729c3h66f4643f043f384c@mail.gmail.com> - Jason Richmond - zerhash - Toronto, Canada - In School - Seneca College - Looking to help with testing and fixing bugs. Eventually new features. - Historical qualifications - I am relatively new to large systems with large teams. I have done private consulting in the past. - I am getting a degree with Seneca, however I have been coding perl since... maybe 10 years ago. - On the side I work with the military, so i have obtained a level of teamwork and leadership to go with it. - I am excited to take part in this project and hope to meet all of you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitaly.fedrushkov at gmail.com Wed Sep 23 07:51:51 2009 From: vitaly.fedrushkov at gmail.com (Vitaly Fedrushkov) Date: Wed, 23 Sep 2009 13:51:51 +0600 Subject: ANN: Bugzilla-ru 3.4.2 and 3.2.5 released Message-ID: <71ae86a70909230051q12f8ee5fv651513b9df386e6c@mail.gmail.com> Good $daytime, Bugzilla-3.4.2-ru and Bugzilla-3.2.5-ru releases are available at https://sourceforge.net/projects/bugzilla-ru/files/ No translation specific enhancements were made. 3.0.9 will not be released because it did not touch templates beyond release-notes. Regards, Vitaly. _______________________________________________ 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 Sep 23 11:14:13 2009 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 Sep 2009 12:14:13 +0100 Subject: API Design Questions Message-ID: Here are some things I've run into when designing the RESTful API. Perhaps people could tell me what they think the best option is. Attachments ----------- The current design uses URLs of the form: /bug//attachment/ However, attachids are globally unique, not per-bug unique. And this URL form means you need to know the bug number before you can access the attachment, which seems unnecessary (or it would mean the API just ignored the bug number, which seems somewhat dumb too). If all you have is e.g. a standard attachment URL, you don't have the bug number. So should I change it to use URLs simply of the form /attachment/ ? Comments -------- A similar question arises with comments, where the comment IDs used on the interface are globally unique. Do you think people would prefer to access individual comments using URIs like: /bug//comment/0 /bug//comment/3 (i.e. indexed by count in the bug, as you might get from "show_bug.cgi?id=123456#45") or like /comment/13535 /comment/43487 ? I think the former (i.e. different from the attachments case), but I'd be interested in the opinions of others. But if we do use the former, what do we do with the globally-unique comment IDs? Suppress them because they'd cause confusion? 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 Sep 23 11:55:10 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 23 Sep 2009 13:55:10 +0200 Subject: API Design Questions In-Reply-To: References: Message-ID: <4ABA0C9E.90703@gmail.com> Le 23. 09. 09 13:14, Gervase Markham a ?crit : > So should I change it to use URLs simply of the form > /attachment/ That's what we currently use when accessing attachments from a web browser. We don't need the bug ID. > /bug//comment/0 This makes more sense to me. LpSolit From zerhash at gmail.com Wed Sep 23 14:28:01 2009 From: zerhash at gmail.com (j r) Date: Wed, 23 Sep 2009 07:28:01 -0700 Subject: API Design Questions In-Reply-To: References: Message-ID: <3fe19be60909230728h69437175q3222872209497c3e@mail.gmail.com> I like this method > > /comment/13535 > /comment/43487 > of each bug it can referance all of the comments and the comments can back reference the bug. These ID's are independant from the bug ID. This method opens up the possibility of having a comment as part of multiple bugs. This could be a good or bad thing. J Richmond -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Wed Sep 23 16:31:27 2009 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 Sep 2009 17:31:27 +0100 Subject: API Design Questions In-Reply-To: References: Message-ID: <7dCdnd8H6_H90CfXnZ2dnUVZ_sadnZ2d@mozilla.org> On 23/09/09 15:28, j r wrote: > I like this method >> >> /comment/13535 >> /comment/43487 >> > > of each bug it can referance all of the comments and the comments can back > reference the bug. That will happen anyway. :-) > These ID's are independant from the bug ID. This method > opens up the possibility of having a comment as part of multiple bugs. This > could be a good or bad thing. I don't think that's a particularly good thing. And anyway, the other scheme has that possibility; the above one would just let you tell when two comments are, in fact, the same comment. Which doesn't sound all that useful. 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 Sep 23 17:03:51 2009 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 Sep 2009 18:03:51 +0100 Subject: API Design Questions (2) In-Reply-To: References: Message-ID: On 23/09/09 12:14, Gervase Markham wrote: > Here are some things I've run into when designing the RESTful API. > Perhaps people could tell me what they think the best option is. And another one :-) We update bugs with a PUT of a JSON representation: { bug: { priority: P1, assigned_to: { name: gerv at mozilla.org, real_name: "Gervase Markham" }, ... } } (At the moment, users are always represented by "user objects" - hashes in the JSON interface - which can have a number of keys and values. This makes the API more understandable; it would be odd if assigned_to was a hash for data coming out, but a scalar for data going in. But obviously, when PUTting a new value, we only look at the "name" key.) What is the best way of issuing meta-instructions, like "set assigned_to to default"? Do you: 1) Not provide that feature? 2) have a magic value for the "assigned_to" in the bug hash: { bug: { priority: P1, assigned_to: { default: 1 }, ... } } 3) Support an extra bug hash key "set_default_assignee: { bug: { priority: P1, set_default_assignee: 1, ... } } 4) Have an additional "instructions" hash: { bug: { priority: P1, ... } instructions: { set_default_assignee: 1 } } 5) Something else? 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 Wed Sep 23 21:57:59 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 23 Sep 2009 14:57:59 -0700 Subject: API Design Questions In-Reply-To: References: Message-ID: <4ABA99E7.70303@bugzilla.org> On 09/23/2009 04:14 AM, Gervase Markham wrote: > So should I change it to use URLs simply of the form > /attachment/ Yeah, probably. > [snip] > or like > > /comment/13535 > /comment/43487 Probably both, but I definitely plan to start using comment ids in as many places in the future instead of comment numbers. Also, theoretically comment numbers can change, but comment ids can't. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Sep 23 21:59:07 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 23 Sep 2009 14:59:07 -0700 Subject: API Design Questions (2) In-Reply-To: References: Message-ID: <4ABA9A2B.6040607@bugzilla.org> On 09/23/2009 10:03 AM, Gervase Markham wrote: > What is the best way of issuing meta-instructions, like "set assigned_to > to default"? Just don't specify assigned_to. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Sep 23 22:00:24 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 23 Sep 2009 15:00:24 -0700 Subject: API Design Questions In-Reply-To: <4ABA99E7.70303@bugzilla.org> References: <4ABA99E7.70303@bugzilla.org> Message-ID: <4ABA9A78.5000202@bugzilla.org> On 09/23/2009 02:57 PM, Max Kanat-Alexander wrote: >> /comment/13535 >> /comment/43487 > > Probably both, but I definitely plan to start using comment ids in as > many places in the future instead of comment numbers. Also, > theoretically comment numbers can change, but comment ids can't. However, I'd also ask why you'd ever need to have a URL for just one comment. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Thu Sep 24 10:14:28 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Sep 2009 11:14:28 +0100 Subject: API Design Questions (2) In-Reply-To: References: Message-ID: On 23/09/09 22:59, Max Kanat-Alexander wrote: > Just don't specify assigned_to. Hmm. I guess for simplicity of API use I wanted people to be able to send stuff like: { "priority": "P5" } and have that do the obvious, simple thing. But if absence of a field means something, then that breaks. This would mean you'd always have to GET every bug before PUTting it, even if you had most of a representation of that bug from the call which lists bugs. But then, maybe the RESTful way is that you have to PUT an entire representation? But you might say that you are doing that in the case above, you are just saying "everything else is assumed not to change"... 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 Sep 24 10:15:34 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Sep 2009 11:15:34 +0100 Subject: API Design Questions In-Reply-To: References: Message-ID: On 23/09/09 22:57, Max Kanat-Alexander wrote: > On 09/23/2009 04:14 AM, Gervase Markham wrote: >> So should I change it to use URLs simply of the form >> /attachment/ > > Yeah, probably. OK. >> /comment/13535 >> /comment/43487 > > Probably both, but I definitely plan to start using comment ids in as > many places in the future instead of comment numbers. Also, > theoretically comment numbers can change, but comment ids can't. "Theoretically" meaning that in the future we may introduce a feature which inserts comments into the middle of the stream, but we haven't yet? Or meaning that Bugzilla already does this in some circumstances? I know we don't renumber when some comments are made private. And if we did do this, people's URLs would break... 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 Sep 24 10:16:21 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Sep 2009 11:16:21 +0100 Subject: API Design Questions In-Reply-To: References: <4ABA99E7.70303@bugzilla.org> Message-ID: On 23/09/09 23:00, Max Kanat-Alexander wrote: > However, I'd also ask why you'd ever need to have a URL for just one > comment. Good question, I guess. Maybe I was going overboard on the REST "every object must be identified and have a URL reference" thing. 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 Thu Sep 24 10:31:54 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 24 Sep 2009 03:31:54 -0700 Subject: API Design Questions (2) In-Reply-To: References: Message-ID: <4ABB4A9A.3070201@bugzilla.org> On 09/24/2009 03:14 AM, Gervase Markham wrote: > and have that do the obvious, simple thing. But if absence of a field > means something, then that breaks. This would mean you'd always have to > GET every bug before PUTting it, even if you had most of a > representation of that bug from the call which lists bugs. Oh, you mean that you want some way to reset things to the default when updating bugs! Just set them null as opposed to an empty string. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Thu Sep 24 10:37:22 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Sep 2009 11:37:22 +0100 Subject: API Design Questions (2) In-Reply-To: References: Message-ID: On 24/09/09 11:31, Max Kanat-Alexander wrote: > Oh, you mean that you want some way to reset things to the default when > updating bugs! Just set them null as opposed to an empty string. So you are saying, for qa_contact: missing => no change null => reset to default empty string => no QA contact user object => that user ? I guess that's unambiguous. Is it also intuitive? :-) 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 Sep 24 10:44:19 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Sep 2009 11:44:19 +0100 Subject: API Design Questions (3) In-Reply-To: References: Message-ID: On 23/09/09 12:14, Gervase Markham wrote: > Here are some things I've run into when designing the RESTful API. > Perhaps people could tell me what they think the best option is. Question 3: Fields in Bugzilla bugs have varying levels of optionalness, from custom fields, which of course are never guaranteed to be present because they are product-specific, via those fields such as qa_contact which can be disabled in the Admin, through to assigned_to or status, which must always be present and set. Question: when returning a representation of a bug, what do we do for fields which do not have a value set? Examples include an empty list of CCs or See Alsos, or resolution for open bugs, or a blank status whiteboard. You could either: A) omit them from the hash B) provide them, but with a "" or [] value B) has the advantage that people processing the JSON don't have to handle the non-existence case with an extra "if" test or "defined" test for each field. However, obviously, custom fields have to be in class A. And you could argue there's a simplicity to just putting everything in class A. Do we do A) for everything, or do we try and divide the fields Bugzilla supports into "always supported" and "sometimes supported" and deal with the always ones (e.g. resolution, keywords) using method B)? 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 Thu Sep 24 10:51:43 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 24 Sep 2009 03:51:43 -0700 Subject: API Design Questions (2) In-Reply-To: References: Message-ID: <4ABB4F3F.9090602@bugzilla.org> On 09/24/2009 03:37 AM, Gervase Markham wrote: > ? I guess that's unambiguous. Is it also intuitive? :-) I think so--an empty string is a literal "empty", where a null is instead a special "empty". And if it's not intuitive for some people, it can be documented somewhere. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Sep 24 10:55:05 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 24 Sep 2009 03:55:05 -0700 Subject: API Design Questions (3) In-Reply-To: References: Message-ID: <4ABB5009.9030408@bugzilla.org> On 09/24/2009 03:44 AM, Gervase Markham wrote: > Fields in Bugzilla bugs have varying levels of optionalness, from custom > fields, which of course are never guaranteed to be present because they > are product-specific, No, actually, custom fields are always present. The product-specific bit (which exists only in 3.4) is all done via JS in the UI. > B) provide them, but with a "" or [] value I'm in favor of this since it makes it easier for clients. In fact, I'm in favor of returning fields even if they're disabled (like status_whiteboard when the usestatuswhiteboard parameter is turned off), unless they are marked as obsolete in the fielddefs table (for example, you wouldn't return qacontact_accessible). It's best if parameters just control the UI, and the underlying structure is always the same. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Thu Sep 24 10:57:44 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Sep 2009 11:57:44 +0100 Subject: API Implementation Questions (1) Message-ID: How do I test mid-air collisions? What do I have to do to force one to happen? My guess is: - Get a bug with one login, token A - Get a bug with another login, token B - Submit a change with token A - Submit a change with token B Is that right? Do the logins have to be different? 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 Sep 24 11:01:45 2009 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Sep 2009 12:01:45 +0100 Subject: API Design Questions (3) In-Reply-To: References: Message-ID: <9cudnXhWL6wHzCbXnZ2dnUVZ_v-dnZ2d@mozilla.org> On 24/09/09 11:55, Max Kanat-Alexander wrote: > On 09/24/2009 03:44 AM, Gervase Markham wrote: >> Fields in Bugzilla bugs have varying levels of optionalness, from custom >> fields, which of course are never guaranteed to be present because they >> are product-specific, > > No, actually, custom fields are always present. The product-specific > bit (which exists only in 3.4) is all done via JS in the UI. So what happens if someone tries to set a custom field on a bug which is in a product which it's not enabled for, a) via the UI and b) via the Web Services interface? >> B) provide them, but with a "" or [] value > > I'm in favor of this since it makes it easier for clients. This is hard to implement right now for custom fields, because the legacy XML interface, which I am using under the covers because it returns more data than the XML-RPC one, doesn't return them unless they are set. We could fix that, of course. But in general, I will try and go with principle B. 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 Thu Sep 24 17:23:27 2009 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 24 Sep 2009 19:23:27 +0200 Subject: API Implementation Questions (1) In-Reply-To: References: Message-ID: <4ABBAB0F.40703@gmail.com> Le 24. 09. 09 12:57, Gervase Markham a ?crit : > Is that right? Do the logins have to be different? No need to have different logins. What matters is what the delta_ts field is set to. If it doesn't match the current timestamp of the bug, you get a midair collision. LpSolit From mkanat at bugzilla.org Thu Sep 24 21:54:38 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 24 Sep 2009 14:54:38 -0700 Subject: API Design Questions (3) In-Reply-To: <9cudnXhWL6wHzCbXnZ2dnUVZ_v-dnZ2d@mozilla.org> References: <9cudnXhWL6wHzCbXnZ2dnUVZ_v-dnZ2d@mozilla.org> Message-ID: <4ABBEA9E.2010204@bugzilla.org> On 09/24/2009 04:01 AM, Gervase Markham wrote: > So what happens if someone tries to set a custom field on a bug which is > in a product which it's not enabled for, a) via the UI and b) via the > Web Services interface? It gets set. > This is hard to implement right now for custom fields, because the > legacy XML interface, which I am using under the covers because it > returns more data than the XML-RPC one, doesn't return them unless they > are set. We could fix that, of course. That may be an artifact of the custom code being used on bugzilla.mozilla.org, and not the result of our actual custom field code. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Tue Sep 29 11:56:17 2009 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 29 Sep 2009 12:56:17 +0100 Subject: API Design Questions (4) In-Reply-To: References: Message-ID: On 23/09/09 12:14, Gervase Markham wrote: > Here are some things I've run into when designing the RESTful API. > Perhaps people could tell me what they think the best option is. Lots more today :-) * When returning an array as the value of a hash, is the key singular or plural? Remember, the array could have one member. { "bugs? or bug?": [ { "id": 1, "comment?": [ { ... }, { ... }, ... ], ... }, { "id": 2, ... }, { "id": 3, ... } ] } * Time formats. The XML-RPC API returns e.g. 20090923T11:02:34. Other APIs return "2009-09-23 11:02:34". Both are valid ISO 8601 (the former is basic, the latter extended). Should we go with the latter as more human-readable? * Various REST evangelists say that APIs are only properly restful if all links between objects use their API URLs. That would suggest that we want e.g.: { blocks: [ "http://bzapi.example.com/bug/23", "http://bzapi.example.com/bug/76" ] } rather than { blocks: [ 23, 76 ] } Would the former be overdoing it? * Similarly, I am currently "upgrading" all user references (assigned_to, reporter, attacher, setter etc.) to User objects, which contain a "name" (email address or short form), "ref" for the full user object and (on the /user interface) a real_name: "assigned_to": { "name": "gerv at mozilla.org", "ref": "http://localhost:3000/user/gerv at mozilla.org" } Is this also overdoing it? * The XML-RPC API tidies up quite a few field names, which is great. Here are some more candidates - what do you think? - cclist_accessible => cc_accessible (to match 'reporter' => 'reporter_accessible' and 'cc') - dependson => depends_on (we are adding underscores, it seems) - everconfirmed => ever_confirmed (of course, this is read only) * (It's OK if no-one knows this.) We don't provide product IDs or component IDs on the legacy XML interface. Why do we provide classification IDs? Should I remove them from the returned data? * There's no longer a qacontact_accessible, right? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Tue Sep 29 13:37:43 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 29 Sep 2009 06:37:43 -0700 Subject: API Design Questions (4) In-Reply-To: References: Message-ID: <4AC20DA7.3000400@bugzilla.org> On 09/29/2009 04:56 AM, Gervase Markham wrote: > * When returning an array as the value of a hash, is the key singular or > plural? Remember, the array could have one member. I'd stick as close as possible to the current XML-RPC return values as possible. So it's "bugs". > * Time formats. The XML-RPC API returns e.g. 20090923T11:02:34. Other > APIs return "2009-09-23 11:02:34". Both are valid ISO 8601 (the former > is basic, the latter extended). Should we go with the latter as more > human-readable? The most important thing is that you return time zones. The current JSON-RPC API is going to be modified to return some other time format than it currently returns in HEAD, although at the moment I'm actually forgetting what the format will be--it's something that the YUI JSON stuff understands and uses correctly, though.... > Would the former be overdoing it? I think so. > Is this also overdoing it? I think so. For parsing, it's probably just easiest to include just the username. But maybe it'd be better to always include a full user object with username and fullname, because otherwise people will have to make one call per user to get their full name. (With XML-RPC it's easy to specify lots of users in one call, so this isn't a problem, but with REST I'm not sure it's as easy, and there's a limit on URL lengths.) > - cclist_accessible => cc_accessible > (to match 'reporter' => 'reporter_accessible' and 'cc') Sounds good. > - dependson => depends_on (we are adding underscores, it seems) Sounds good. > - everconfirmed => ever_confirmed (of course, this is read only) Sure. > * (It's OK if no-one knows this.) We don't provide product IDs or > component IDs on the legacy XML interface. Why do we provide > classification IDs? Should I remove them from the returned data? I think we provide all those IDs in config.cgi--I have no idea why we'd provide them in bug XML, though.... > * There's no longer a qacontact_accessible, right? Right. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Tue Sep 29 15:04:29 2009 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 29 Sep 2009 16:04:29 +0100 Subject: API Design Questions (4) In-Reply-To: References: Message-ID: <7tedneedkK9jvF_XnZ2dnUVZ_jmdnZ2d@mozilla.org> On 29/09/09 14:37, Max Kanat-Alexander wrote: > I'd stick as close as possible to the current XML-RPC return values as > possible. So it's "bugs". On that point, attachments and bugs have a "creation_time" but comments just have a "time". Is that intentional? Should I fix it on this API? 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 Sep 29 15:44:28 2009 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 29 Sep 2009 16:44:28 +0100 Subject: API Design Questions (4) In-Reply-To: References: Message-ID: On 29/09/09 14:37, Max Kanat-Alexander wrote: > The most important thing is that you return time zones. Well, the current XML-RPC interface returns all times in the timezone of the server and makes you get timezone information via another call. I was planning to emulate that pattern. Have you changed your mind - are you now thinking it's better to return the timezone with each timestamp? > I think so. For parsing, it's probably just easiest to include just the > username. But maybe it'd be better to always include a full user object > with username and fullname, because otherwise people will have to make > one call per user to get their full name. Right. So which shall we do? :-) I'm going to stick with full user object everywhere unless you say otherwise. > (With XML-RPC it's easy to > specify lots of users in one call, so this isn't a problem, but with > REST I'm not sure it's as easy, and there's a limit on URL lengths.) But we are talking about output here, not input. So there's no URL length issue. >> * (It's OK if no-one knows this.) We don't provide product IDs or >> component IDs on the legacy XML interface. Why do we provide >> classification IDs? Should I remove them from the returned data? > > I think we provide all those IDs in config.cgi--I have no idea why we'd > provide them in bug XML, though.... OK, I'll cut classification_id out of the returned data. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Tue Sep 29 21:51:39 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 29 Sep 2009 14:51:39 -0700 Subject: API Design Questions (4) In-Reply-To: <7tedneedkK9jvF_XnZ2dnUVZ_jmdnZ2d@mozilla.org> References: <7tedneedkK9jvF_XnZ2dnUVZ_jmdnZ2d@mozilla.org> Message-ID: <4AC2816B.2060006@bugzilla.org> On 09/29/2009 08:04 AM, Gervase Markham wrote: > On that point, attachments and bugs have a "creation_time" but comments > just have a "time". Is that intentional? Should I fix it on this API? Hmm. Yes, you should probably fix that in your API. And maybe file a bug for the XML-RPC API. (We'll have to maintain backwards-compatibility, though.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Tue Sep 29 21:52:57 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 29 Sep 2009 14:52:57 -0700 Subject: API Design Questions (4) In-Reply-To: References: Message-ID: <4AC281B9.2070301@bugzilla.org> On 09/29/2009 08:44 AM, Gervase Markham wrote: > Well, the current XML-RPC interface returns all times in the timezone of > the server and makes you get timezone information via another call. I > was planning to emulate that pattern. Have you changed your mind - are > you now thinking it's better to return the timezone with each timestamp? It's not an issue of what I'm thinking, but an issue of what the XML-RPC standard requires. If I could have returned timestamps with time zones always, I would have. > Right. So which shall we do? :-) I'm going to stick with full user > object everywhere unless you say otherwise. Full object seems reasonable. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From justdave at bugzilla.org Wed Sep 30 05:48:50 2009 From: justdave at bugzilla.org (David Miller) Date: Wed, 30 Sep 2009 01:48:50 -0400 Subject: API Design Questions (4) In-Reply-To: <4AC281B9.2070301@bugzilla.org> References: <4AC281B9.2070301@bugzilla.org> Message-ID: <4AC2F142.3030403@bugzilla.org> Max Kanat-Alexander wrote on 9/29/09 5:52 PM: > On 09/29/2009 08:44 AM, Gervase Markham wrote: >> Well, the current XML-RPC interface returns all times in the timezone of >> the server and makes you get timezone information via another call. I >> was planning to emulate that pattern. Have you changed your mind - are >> you now thinking it's better to return the timezone with each timestamp? > > It's not an issue of what I'm thinking, but an issue of what the > XML-RPC standard requires. If I could have returned timestamps with time > zones always, I would have. Does the spec say it has to be in the server's timezone, or only that it doesn't contain timezone information? If the latter, it would probably make more sense to always return it in UTC. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Wed Sep 30 05:54:41 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 29 Sep 2009 22:54:41 -0700 Subject: API Design Questions (4) In-Reply-To: <4AC2F142.3030403@bugzilla.org> References: <4AC281B9.2070301@bugzilla.org> <4AC2F142.3030403@bugzilla.org> Message-ID: <4AC2F2A1.7010200@bugzilla.org> On 09/29/2009 10:48 PM, David Miller wrote: > Does the spec say it has to be in the server's timezone, or only that it > doesn't contain timezone information? It just specifies an exact format and a clarification says that the API docs should clarify what timezone it's sending. (This is one of XML-RPC's major flaws.) > If the latter, it would probably > make more sense to always return it in UTC. Yeah, I plan to adjust the system to always return UTC in the future. Or somebody can do that themselves and submit a patch, if they'd like. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From gerv at mozilla.org Wed Sep 30 10:16:56 2009 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Sep 2009 11:16:56 +0100 Subject: API Design Questions (4) In-Reply-To: References: <4AC281B9.2070301@bugzilla.org> <4AC2F142.3030403@bugzilla.org> Message-ID: On 30/09/09 06:54, Max Kanat-Alexander wrote: > It just specifies an exact format and a clarification says that the API > docs should clarify what timezone it's sending. (This is one of > XML-RPC's major flaws.) OK. So what am I doing on the REST API? 1) Send timestamps in local timezone, make extra call for timezone information 2) Send timestamps in UTC (I can cheat because I know Bugzilla's timezone) 3) Send timestamps with timezone information embedded in ISO 8601 style 2) and 3) are a bit more complicated because of summer time. But I'm sure there are Perl modules to help me :-) 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 Wed Sep 30 10:33:05 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 30 Sep 2009 03:33:05 -0700 Subject: API Design Questions (4) In-Reply-To: References: <4AC281B9.2070301@bugzilla.org> <4AC2F142.3030403@bugzilla.org> Message-ID: <4AC333E1.9030009@bugzilla.org> On 09/30/2009 03:16 AM, Gervase Markham wrote: > 3) Send timestamps with timezone information embedded in ISO 8601 style I'd suggest doing this, or include the actual timezone like "America/Los Angeles" (which avoids the DST problem). -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From roman at pszonka.org Wed Sep 30 10:42:11 2009 From: roman at pszonka.org (Roman Pszonka) Date: Wed, 30 Sep 2009 11:42:11 +0100 Subject: API Design Questions (4) In-Reply-To: References: Message-ID: <54cb6ff0909300342v32511ff0ie68a85511d81e60@mail.gmail.com> On Tue, Sep 29, 2009 at 12:56, Gervase Markham wrote: > * Various REST evangelists say that APIs are only properly restful if all > links between objects use their API URLs. That would suggest that we want > e.g.: > > { > ?blocks: [ "http://bzapi.example.com/bug/23", > ? ? ? ? ? ?"http://bzapi.example.com/bug/76" ] > } That would allow linking between different databases, right? If you later decide to support this by bugzilla, there won't be a need to change API. -- Roman Pszonka From gerv at mozilla.org Wed Sep 30 13:28:35 2009 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Sep 2009 14:28:35 +0100 Subject: API Design Questions (5) In-Reply-To: References: Message-ID: On 23/09/09 12:14, Gervase Markham wrote: > Here are some things I've run into when designing the RESTful API. > Perhaps people could tell me what they think the best option is. The current list of objects, fields and types for the REST API is here: https://wiki.mozilla.org/Bugzilla:REST_API:Objects Please let me know if anything looks wrong to you. We have a part-convention of having boolean field names start "is_". But it's only part at the moment. So how about the following changes? * ever_confirmed => is_confirmed ("confirmed", not CONFIRMED :-) * cc_accessible => is_cc_accessible * reporter_accessible => is_reporter_accessible (or perhaps is_accessible_by_cc/reporter, or is_visible_to_cc/reporter?) 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 Wed Sep 30 22:22:26 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 30 Sep 2009 15:22:26 -0700 Subject: API Design Questions (5) In-Reply-To: References: Message-ID: <4AC3DA22.60002@bugzilla.org> On 09/30/2009 06:28 AM, Gervase Markham wrote: > * ever_confirmed => is_confirmed ("confirmed", not CONFIRMED :-) Yeah, I like it. > * cc_accessible => is_cc_accessible Sure. > * reporter_accessible => is_reporter_accessible Sure. I think is_accessible_by_* would be too long. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Sep 30 22:25:58 2009 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 30 Sep 2009 15:25:58 -0700 Subject: API Design Questions (5) In-Reply-To: References: Message-ID: <4AC3DAF6.2020005@bugzilla.org> On 09/30/2009 06:28 AM, Gervase Markham wrote: > https://wiki.mozilla.org/Bugzilla:REST_API:Objects Maybe instead of having a separate attachmentdata object, you should allow people to specify ?include= or ?exclude= to include or exclude certain fields from every object. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.