From gerv at mozilla.org Fri Dec 5 02:01:18 2014 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 04 Dec 2014 18:01:18 -0800 Subject: Docs branch merge fallout Message-ID: It seems my docs branch merge has caused some trouble in the VCS history. Is it enough trouble that we want to back up and fix it, and deal with the fallout of fixing up the BZR and CVS mirrors manually, and deal with the fact that some people's checkouts may break (we'd have to manually fix those on landfill, for example)? We can recruit the help of some of our VCS experts who are here in Portland. Whether we do that or not, I'd also like to understand why merging a branch can be so destructive to the bzr and CVS mirrors. (Separate from the problem of leaving WIP commits in the history, which I agree is ugly.) I would hope that development on feature branches would be something we can do in the future; is that impossible as long as we maintain bzr and CVS mirrors? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Fri Dec 5 02:37:21 2014 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 04 Dec 2014 18:37:21 -0800 Subject: Docs branch merge fallout In-Reply-To: References: Message-ID: On 04/12/14 18:01, Gervase Markham wrote: > Is it enough trouble that we want to back up and fix it, and deal with > the fallout of fixing up the BZR and CVS mirrors manually, and deal with > the fact that some people's checkouts may break (we'd have to manually > fix those on landfill, for example)? We can recruit the help of some of > our VCS experts who are here in Portland. I talked to Mike Hommey. He says we could: * Delete the offending commit and all commits after by moving the head back to the last commit beforehand, and then pushing with git push -f. * We would need to do some sort of manual fixup on any checkout which wanted to push in the future. That's probably just the checkouts of the core devs, at this stage. * In terms of the bzr mirror, it's not clear what happens. How does our bzr mirroring work? Can we delete the repo and start again, or would we end up with new commit IDs? Can we do similar surgery? Mike doesn't know because he's not too familiar with bzr. * The checkouts on landfill are from bzr, and will have updated by now to the version with the bad commits. Now might be a good time to switch them over to using git... Goodness knows how we'd fix the CVS repo... Perhaps it's time to abandon it for trunk? :-) The other option would be to start a new branch from before the merge, and say "OK, trunk is now this new branch", and people would have to switch over manually. We could call it "trunk" instead of "master". This may have annoying fallout if the name "master" is the default in various commands, I don't know. Mike thinks only "clone" does this. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From glob at mozilla.com Fri Dec 5 18:28:47 2014 From: glob at mozilla.com (Byron Jones) Date: Fri, 05 Dec 2014 10:28:47 -0800 Subject: Docs branch merge fallout In-Reply-To: References: Message-ID: <5481F95F.9080601@mozilla.com> yes, this needs to be fixed; the revision history is a complete mess. gerv, can you please file a bug so this can be tracked? i don't think now's the right time to work on updating landfill to pull from git, nor drop cvs. (i don't think that starting a new branch is a good idea btw) -glob Gervase Markham wrote: > On 04/12/14 18:01, Gervase Markham wrote: >> Is it enough trouble that we want to back up and fix it, and deal with >> the fallout of fixing up the BZR and CVS mirrors manually, and deal with >> the fact that some people's checkouts may break (we'd have to manually >> fix those on landfill, for example)? We can recruit the help of some of >> our VCS experts who are here in Portland. > > I talked to Mike Hommey. He says we could: > > * Delete the offending commit and all commits after by moving the head > back to the last commit beforehand, and then pushing with git push -f. > > * We would need to do some sort of manual fixup on any checkout which > wanted to push in the future. That's probably just the checkouts of the > core devs, at this stage. > > * In terms of the bzr mirror, it's not clear what happens. How does our > bzr mirroring work? Can we delete the repo and start again, or would we > end up with new commit IDs? Can we do similar surgery? Mike doesn't know > because he's not too familiar with bzr. > > * The checkouts on landfill are from bzr, and will have updated by now > to the version with the bad commits. Now might be a good time to switch > them over to using git... > > Goodness knows how we'd fix the CVS repo... Perhaps it's time to abandon > it for trunk? :-) > > The other option would be to start a new branch from before the merge, > and say "OK, trunk is now this new branch", and people would have to > switch over manually. We could call it "trunk" instead of "master". This > may have annoying fallout if the name "master" is the default in various > commands, I don't know. Mike thinks only "clone" does this. > > 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: > -- byron jones - :glob - bugzilla.mozilla.org team - -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Dec 5 18:53:04 2014 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 05 Dec 2014 10:53:04 -0800 Subject: Docs branch merge fallout In-Reply-To: <5481F95F.9080601@mozilla.com> References: <5481F95F.9080601@mozilla.com> Message-ID: <5481FF10.2030509@mozilla.org> On 05/12/14 10:28, Byron Jones wrote: > yes, this needs to be fixed; the revision history is a complete mess. > gerv, can you please file a bug so this can be tracked? https://bugzilla.mozilla.org/show_bug.cgi?id=1107988 Gerv From alanoe at linux.vnet.ibm.com Fri Dec 5 21:26:27 2014 From: alanoe at linux.vnet.ibm.com (Alan Evangelista) Date: Fri, 05 Dec 2014 19:26:27 -0200 Subject: New REST API - motivation Message-ID: <54822303.2040704@linux.vnet.ibm.com> Hi. My team maintains a customized Bugzilla version for IBM internal use. I'm curious to know why you guys are developing a REST API for Bugzilla 5.0. The current XML-RPC interface has known downsides? I know that RESTful interfaces using vanilla HTTP have some advantages, such as caching and versioning out of the box, but I wonder if there are additional motivations. Regards, Alan Evangelista From mcote at bugzilla.org Fri Dec 5 21:53:00 2014 From: mcote at bugzilla.org (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Fri, 05 Dec 2014 13:53:00 -0800 Subject: New REST API - motivation In-Reply-To: References: Message-ID: Hi Alan. Good question. There are a few reasons for a REST API. Here are a few: * It's the de facto standard for web interfaces these days. Every web developer knows how to use HTTP APIs, and it's very simple to use in modern browsers and JavaScript frameworks. * Similarly, REST uses JSON, which is now much more popular than XML for new projects, mainly because of its readability and size. * REST is a lot more convenient to use on the command line. Simple tools like curl can easily access REST APIs; there are no common command-line tools for accessing XML-RPC (as far as I know). Technically our REST API isn't very RESTish; it doesn't closely follow the standard REST model. We're working on improving that in a new REST version for a future Bugzilla release. Note that we'll be deprecating XML-RPC and JSON-RPC soon so that we can concentrate on building a great REST API without being encumbered by technologies that are falling out of use. Mark On 2014-12-05 1:26 PM, Alan Evangelista wrote: > Hi. > > My team maintains a customized Bugzilla version for IBM internal use. > > I'm curious to know why you guys are developing a REST API for Bugzilla > 5.0. > The current XML-RPC interface has known downsides? I know that RESTful > interfaces > using vanilla HTTP have some advantages, such as caching and versioning > out of > the box, but I wonder if there are additional motivations. > > > Regards, > Alan Evangelista > > - > To view or change your list settings, click here: > > -- Mark C?t? Assistant Project Lead, Bugzilla _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From dylan at mozilla.com Fri Dec 5 22:56:44 2014 From: dylan at mozilla.com (Dylan Hardison) Date: Fri, 5 Dec 2014 14:56:44 -0800 (PST) Subject: Bugzilla git has stabilized In-Reply-To: <1582067465.16435822.1417819330526.JavaMail.zimbra@mozilla.com> Message-ID: <1894437201.16437613.1417820204282.JavaMail.zimbra@mozilla.com> After some minor git surgery, it is safe to commit to the bugzilla git repo again. There are remaining issues with bzr that are outside the scope of this email. Action is required because this fix necessitated changing history. Do a git fetch to get updated references $ git fetch origin Next, commit any changes you have made. $ git rebase -i origin/master This will open up your editor with all the commits that you have made + the ones Delete all the "pick ..." lines that are not *YOUR* changes. If you have made no changes, replace all the lines you've deleted with one line: noop If you git rebase and the editor contains only "noop", congratulations! You never had the bad commits in your checkout. Finally, save and quit the editor that git-rebase opened. You're good to go. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From glob at mozilla.com Fri Dec 5 22:57:14 2014 From: glob at mozilla.com (Byron Jones) Date: Fri, 05 Dec 2014 14:57:14 -0800 Subject: bzr and cvs mirrors of trunk are currently not updating Message-ID: <5482384A.1060808@mozilla.com> just a quick heads-up that the bzr and cvs mirrors of trunk are currently not updating. we had to perform some heavy maintenance on git, and we're still trying to figure out how these changes can be propagated to bzr/cvs. at this point due to the complexity required to fix these mirrors it's likely that we will not re-enable the mirroring of trunk to bzr and cvs. ** this only applies to trunk ** all other branches will still be mirrored. the tip installation on landfill has been updated to pull from git instead of bzr, so it should continue to be updated. -glob -- byron jones - :glob - bugzilla.mozilla.org team - _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Fri Dec 5 23:01:13 2014 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 05 Dec 2014 15:01:13 -0800 Subject: Bugzilla git has stabilized In-Reply-To: <1894437201.16437613.1417820204282.JavaMail.zimbra@mozilla.com> References: <1894437201.16437613.1417820204282.JavaMail.zimbra@mozilla.com> Message-ID: <54823939.6050009@mozilla.org> On 05/12/14 14:56, Dylan Hardison wrote: > Next, commit any changes you have made. > $ git rebase -i origin/master To be precise, this is two steps. First, commit any changes you have made in your local tree that you want to save, using git commit, Then, do the rebase command as above. (If you rebase with local uncommitted changes, it will complain.) Gerv From mcote at bugzilla.org Sat Dec 6 01:01:13 2014 From: mcote at bugzilla.org (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Fri, 05 Dec 2014 17:01:13 -0800 Subject: New REST API - motivation In-Reply-To: References: Message-ID: <-oGdnabQ15vGyB_JnZ2dnUU7-QednZ2d@mozilla.org> On 2014-12-05 3:36 PM, Damien wrote: > Hey Mark, Alan, > > several things to consider: > - providing a REST API will need to take permissions / auth in the picture. The first version of REST API is actually done; you can see the API documentation at http://bugzilla.readthedocs.org/en/5.0/api/index.html You can provide username and password directly to API calls for authenticated access, and we have support for API keys. > - there are popular solutions to get started quick from an existing DB > (e.g. django + django-rest-framework after running the ./manage.py > inspectdb command to generate models automatically); I've considered this > in the past but the previous point got me stalled (=too much work for me > with not enough free time) Bugzilla's security model is quite complex, so a thin layer on top of the database is not possible, which is why the initial version of the REST API uses the existing API layer that is shared by XML-RPC and JSON-RPC. In other words, we provide RESTish versions of the existing XML-RPC and JSON-RPC interfaces. This is related to what I mentioned about the REST API not actually being very RESTful, since it follows the RPC function model instead of proper resources. We plan to move closer to a real REST model in subsequent versions (and we will have a versioning framework in the API itself for backwards compatibility). > - having REST means you can swap frontends :D (e.g. angular bootstrap > stuff) but also allow external services to integrate better with bugzilla > provided you configure CORS (e.g. django-cors-headers) Yes, at Mozilla we actually have quite a few dashboards and tools that interface with Bugzilla, originally using the separate BzAPI service, but now most integrate directly to the new native API (we've backported it from 5.0 to our installation). I plan to list and categorize them on Mozilla's wiki in case some are of use to other Bugzilla installations. > however the current "contribution" workflow is a pain for folks that > actually want to contribute. I would love to hear more on this. One of my goals as Assistant Project Lead is to increase the number of contributors, which in turn requires that contributing be relatively painless. > I would certainly like to see some kickass REST API, I would be able to > consume that using Angular (see ngResource) and do my own dashboards and > stuff. We will have a 5.0 release candidate coming out very soon! We have four open blockers: one is approved and should be committed soon, one is in the review cycle, and the others won't block us from a RC (bug in docs generation, and one in tests). Thanks for your input, and I would love to continue the conversation about contributing. Mark -- Mark C?t? Assistant Project Lead, Bugzilla _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From damien.nozay at gmail.com Sat Dec 6 04:07:55 2014 From: damien.nozay at gmail.com (Damien) Date: Fri, 5 Dec 2014 20:07:55 -0800 Subject: contributing pain points (was: Re: New REST API - motivation) Message-ID: On Fri, Dec 5, 2014 at 5:01 PM, Mark C?t? wrote: > On 2014-12-05 3:36 PM, Damien wrote: > > however the current "contribution" workflow is a pain for folks that > > actually want to contribute. > > I would love to hear more on this. One of my goals as Assistant Project > Lead is to increase the number of contributors, which in turn requires > that contributing be relatively painless. > > I have had much better user experience with bitbucket and github service. One thing github got right is how continuous integration systems (travis-ci, jenkins and others) can test pull requests and tell you if your changes would pass or break the tests. obsoleting patches is easy as well (updating the pull-request branch). You can also look at gerrit which many communities use. https://www.mediawiki.org/wiki/Gerrit/Tutorial I personally don't like the user interface, but the tooling is nice. _______________________________________________ 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 Sat Dec 6 22:19:06 2014 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 06 Dec 2014 14:19:06 -0800 Subject: Filing bugs on Landfill; upgrading Perl on Landfill Message-ID: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> We don't have a BMO component in the Bugzilla product for Landfill issues: would that be a good idea? I ask because bugzilla-tip is down - not because of any of the recent git-related shenanigans, but because: [Sat Dec 06 14:16:49 2014] [error] [client 204.239.250.1] Perl v5.10.1 required--this is only v5.8.8, stopped at /var/www/html/bugzilla-tip/index.cgi line 9., referer: https://landfill.bugzilla.org/ We need to upgrade the Perl on the box. 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 Sun Dec 7 13:12:57 2014 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Sun, 07 Dec 2014 14:12:57 +0100 Subject: Filing bugs on Landfill; upgrading Perl on Landfill In-Reply-To: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> References: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> Message-ID: <54845259.6040500@gmail.com> Le 06. 12. 14 23:19, Gervase Markham a ?crit : > We don't have a BMO component in the Bugzilla product for Landfill > issues: would that be a good idea? A BMO component under the Bugzilla product would be a great way to see all Mozilla employees incorrectly file bugs about BMO here. So no, that's really not a good idea. Also, I don't see how BMO has something to do with landfill. landfill is at landfill.bugzilla.org, so its domain name is bugzilla.org and we already have a bugzilla.org component. No need for another component. > I ask because bugzilla-tip is down Then just file a bug under the bugzilla.org component, or ask wicked directly. > [Sat Dec 06 14:16:49 2014] [error] [client 204.239.250.1] Perl v5.10.1 > required--this is only v5.8.8, stopped at > /var/www/html/bugzilla-tip/index.cgi line 9., referer: > https://landfill.bugzilla.org/ > > We need to upgrade the Perl on the box. So someone messed landfill again, because bugzilla-tip was already running Perl 5.10.1 for more than 2 years. LpSolit From tm at sci.fi Sun Dec 7 13:45:31 2014 From: tm at sci.fi (Teemu Mannermaa) Date: Sun, 07 Dec 2014 15:45:31 +0200 Subject: Filing bugs on Landfill; upgrading Perl on Landfill In-Reply-To: <54845259.6040500@gmail.com> References: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> <54845259.6040500@gmail.com> Message-ID: <548459FB.9090509@sci.fi> Fr?d?ric Buclin wrote: > landfill is at landfill.bugzilla.org, so its domain name is bugzilla.org > and we already have a bugzilla.org component. No need for another component. Yep, use that and if it's something urgent, ping me over on irc to look at the problem. Justdave can also help but if it's something wrong at hw/vmware/console level, then a Mozilla IT (or whatever their name is these days) is the ones to contact via their own BMO product. >> I ask because bugzilla-tip is down > Then just file a bug under the bugzilla.org component, or ask wicked > directly. Yes, please, gerv, ask me before doing massive infra related changes. There are lot of things going on that unfortunately are only known by me as there has not been anybody else working on these things.. >> [Sat Dec 06 14:16:49 2014] [error] [client 204.239.250.1] Perl v5.10.1 >> required--this is only v5.8.8, stopped at >> We need to upgrade the Perl on the box. > So someone messed landfill again, because bugzilla-tip was already > running Perl 5.10.1 for more than 2 years. Looks like somebody blew away all local changes on the tip installs. It was changed to run a custom Perl 5.10.1 install on the system using the official instructions available on Bugzilla FAQ. Whoever messed with its git checkout is free to learn how to do that and cleanup the mess or ask me to do it for them. Otherwise, landfill is due to get replaced with a CentOS 6 that has Perl 5.10.1 as a system level component so that these shenanigans are not necessary anymore. This is also shows what's the problem with requiring too new stuff.. -- Teemu Mannermaa System Specialist "Anything is possible but probabilities vary." From gerv at mozilla.org Sun Dec 7 13:54:00 2014 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 07 Dec 2014 13:54:00 +0000 Subject: Filing bugs on Landfill; upgrading Perl on Landfill In-Reply-To: <54845259.6040500@gmail.com> References: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> <54845259.6040500@gmail.com> Message-ID: <54845BF8.2020604@mozilla.org> On 07/12/14 13:12, Fr?d?ric Buclin wrote: > Le 06. 12. 14 23:19, Gervase Markham a ?crit : >> We don't have a BMO component in the Bugzilla product for Landfill >> issues: would that be a good idea? > > A BMO component under the Bugzilla product would be a great way to see > all Mozilla employees incorrectly file bugs about BMO here. So no, > that's really not a good idea. Also, I don't see how BMO has something > to do with landfill. I'm sorry, but you've misparsed my statement. Let me try and be more clear: On the instance of Bugzilla at bugzilla.mozilla.org, where we track issues relating to the Bugzilla project and its websites, we do not have a component for Landfill issues in the product called "Bugzilla". I think we should. > landfill is at landfill.bugzilla.org, so its domain name is bugzilla.org > and we already have a bugzilla.org component. No need for another component. If we are agreed that the bugzilla.org component takes Landfill issues, then OK, there's no need for another. >> [Sat Dec 06 14:16:49 2014] [error] [client 204.239.250.1] Perl v5.10.1 >> required--this is only v5.8.8, stopped at >> /var/www/html/bugzilla-tip/index.cgi line 9., referer: >> https://landfill.bugzilla.org/ >> >> We need to upgrade the Perl on the box. > > So someone messed landfill again, because bugzilla-tip was already > running Perl 5.10.1 for more than 2 years. Hmm. That's odd. Gerv From lpsolit at gmail.com Sun Dec 7 13:54:51 2014 From: lpsolit at gmail.com (=?ISO-8859-15?Q?Fr=E9d=E9ric_Buclin?=) Date: Sun, 07 Dec 2014 14:54:51 +0100 Subject: Filing bugs on Landfill; upgrading Perl on Landfill In-Reply-To: <548459FB.9090509@sci.fi> References: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> <54845259.6040500@gmail.com> <548459FB.9090509@sci.fi> Message-ID: <54845C2B.1050506@gmail.com> Le 07. 12. 14 14:45, Teemu Mannermaa a ?crit : > Otherwise, landfill is due to get replaced with a CentOS 6 that has Perl > 5.10.1 as a system level component so that these shenanigans are not > necessary anymore. > > This is also shows what's the problem with requiring too new stuff.. Perl 5.10.1 is not too new stuff. It has been released 5 years ago and already reached EOL. From lpsolit at gmail.com Sun Dec 7 14:03:55 2014 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sun, 07 Dec 2014 15:03:55 +0100 Subject: Filing bugs on Landfill; upgrading Perl on Landfill In-Reply-To: <54845BF8.2020604@mozilla.org> References: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> <54845259.6040500@gmail.com> <54845BF8.2020604@mozilla.org> Message-ID: <54845E4B.5070009@gmail.com> Le 07. 12. 14 14:54, Gervase Markham a ?crit : > If we are agreed that the bugzilla.org component takes Landfill issues, > then OK, there's no need for another. Bugs related to landfill have always been filed into the bugzilla.org component. Just query bmo to see that. FYI, bug 146865 named "landfill.bugzilla.org is down" and reported in 2002 was already filed under the bugzilla.org component. So nothing new here. :) LpSolit From gerv at mozilla.org Sun Dec 7 14:41:04 2014 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 07 Dec 2014 14:41:04 +0000 Subject: Filing bugs on Landfill; upgrading Perl on Landfill In-Reply-To: <54845E4B.5070009@gmail.com> References: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> <54845259.6040500@gmail.com> <54845BF8.2020604@mozilla.org> <54845E4B.5070009@gmail.com> Message-ID: <54846700.5010907@mozilla.org> On 07/12/14 14:03, Fr?d?ric Buclin wrote: > Bugs related to landfill have always been filed into the bugzilla.org > component. Just query bmo to see that. OK - https://bugzilla.mozilla.org/show_bug.cgi?id=1108374 filed. Gerv From mcote at mozilla.com Mon Dec 8 18:58:03 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Mon, 08 Dec 2014 13:58:03 -0500 Subject: contributing pain points (was: Re: New REST API - motivation) In-Reply-To: References: Message-ID: On 2014-12-05 11:07 PM, Damien wrote: > On Fri, Dec 5, 2014 at 5:01 PM, Mark C?t? wrote: > >> On 2014-12-05 3:36 PM, Damien wrote: >>> however the current "contribution" workflow is a pain for folks that >>> actually want to contribute. >> >> I would love to hear more on this. One of my goals as Assistant Project >> Lead is to increase the number of contributors, which in turn requires >> that contributing be relatively painless. > > I have had much better user experience with bitbucket and github service. > One thing github got right is how continuous integration systems > (travis-ci, jenkins and others) can test pull requests and tell you if your > changes would pass or break the tests. obsoleting patches is easy as well > (updating the pull-request branch). > > You can also look at gerrit which many communities use. > https://www.mediawiki.org/wiki/Gerrit/Tutorial > I personally don't like the user interface, but the tooling is nice. I would prefer to discuss specifically where the current process is lacking rather than focussing on other tools; that said, I know our process is a bit dated. Regarding GitHub, we actually have a mirror there (https://github.com/bugzilla/bugzilla) which is hooked up to Travis CI (https://travis-ci.org/bugzilla/bugzilla). There are admittedly some intermittent failures that we need to look into, but the framework is there. It would be easy to test your own fork again Travis in the same way. At the moment we don't accept pull requests because they are hard to integrate with Bugzilla, which is the source of truth for Bugzilla development. But I can see a strong argument for encouraging pull requests just to get the tests run automatically, even if we then move to Bugzilla for the review. I've been thinking about writing a tool to convert a pull request to a Bugzilla patch automatically. Should be pretty easy, although I admit that the review system in Bugzilla is not as nice as GitHub's. Regardless, running the tests should be pretty easy now, and I'll update the contributing pages on the wiki, which I realize I neglected to do after we switched to Travis. Mozilla is slowly migrating to a solution based on Review Board but more powerful, a repository-centric system not entirely unlike GitHub. I hope that, some day, Bugzilla can use this system as well. Mark _______________________________________________ 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 Dec 9 13:57:22 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Dec 2014 13:57:22 +0000 Subject: user.js for Bugzilla Message-ID: <5uKdnW20NP9fYhvJnZ2dnUU7-T-dnZ2d@mozilla.org> Is the following idea dumb or brilliant? :-) What if Bugzilla (perhaps via an extension initially) had a textbox in which users could write JS, and it would be loaded on all page loads? Sort of like a cross-browser, site-specific Greasemonkey. People could then share "recipes" (functions) for useful additions. For example, the Bugzilla team could have a recipe which automatically set the Target Milestone of a bug to the current milestone when resolving a bug as FIXED, thereby saving LpSolit a job ;-) We could even provide a little library help to make common tasks easier, like providing the ability to register callbacks for events like "submitted bug 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 Tue Dec 9 15:32:23 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Dec 2014 15:32:23 +0000 Subject: Filing bugs on Landfill; upgrading Perl on Landfill In-Reply-To: <548459FB.9090509@sci.fi> References: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> <54845259.6040500@gmail.com> <548459FB.9090509@sci.fi> Message-ID: <54871607.6030508@mozilla.org> On 07/12/14 13:45, Teemu Mannermaa wrote: > Yes, please, gerv, ask me before doing massive infra related changes. > There are lot of things going on that unfortunately are only known by me > as there has not been anybody else working on these things.. The last set of changes I did, I did with authority of a deputy project lead. And I made sure not to delete anything permanently so changes could be rolled back if they were wrong (which was true in one case). > Looks like somebody blew away all local changes on the tip installs. It > was changed to run a custom Perl 5.10.1 install on the system using the > official instructions available on Bugzilla FAQ. That would be dkl, replacing the bzr checkout with a git checkout due to the recent VCS issues I caused leading to non-updating of the trunk on the bzr mirror. > Otherwise, landfill is due to get replaced with a CentOS 6 that has Perl > 5.10.1 as a system level component so that these shenanigans are not > necessary anymore. It is? That's news to me, and good news. One reason I did some cleanup a few weeks ago is that in discussion it was thought that no-one had time to stand up a new box. Is there a bug tracking this work? Gerv From jochen.wiedmann at gmail.com Tue Dec 9 16:33:54 2014 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Tue, 9 Dec 2014 17:33:54 +0100 Subject: user.js for Bugzilla In-Reply-To: <5uKdnW20NP9fYhvJnZ2dnUU7-T-dnZ2d@mozilla.org> References: <5uKdnW20NP9fYhvJnZ2dnUU7-T-dnZ2d@mozilla.org> Message-ID: Sounds very much like duplicating both a) Greasemonkey to me, with lots of possibilities for XSS attacks as a bonus and b) superceding the existing extension system. I'd be -1. Sorry, Jochen On Tue, Dec 9, 2014 at 2:57 PM, Gervase Markham wrote: > Is the following idea dumb or brilliant? :-) > > What if Bugzilla (perhaps via an extension initially) had a textbox in > which users could write JS, and it would be loaded on all page loads? > Sort of like a cross-browser, site-specific Greasemonkey. People could > then share "recipes" (functions) for useful additions. For example, the > Bugzilla team could have a recipe which automatically set the Target > Milestone of a bug to the current milestone when resolving a bug as > FIXED, thereby saving LpSolit a job ;-) We could even provide a little > library help to make common tasks easier, like providing the ability to > register callbacks for events like "submitted bug change". > > 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: > -- Our time is just a point along a line that runs forever with no end. (Al Stewart, Lord Grenville) _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From denis.roy at eclipse.org Tue Dec 9 16:37:50 2014 From: denis.roy at eclipse.org (Denis Roy) Date: Tue, 09 Dec 2014 11:37:50 -0500 Subject: user.js for Bugzilla In-Reply-To: References: <5uKdnW20NP9fYhvJnZ2dnUU7-T-dnZ2d@mozilla.org> Message-ID: <5487255E.6070304@eclipse.org> On 12/09/2014 11:33 AM, Jochen Wiedmann wrote: > Sounds very much like duplicating both > > a) Greasemonkey to me, with lots of possibilities for XSS attacks as a bonus and > b) superceding the existing extension system. > > I'd be -1. +1 on that -1 We have dev teams who share GreaseMonkey scripts... perhaps have a way for users of an installation to share those? From gerv at mozilla.org Tue Dec 9 16:45:37 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Dec 2014 16:45:37 +0000 Subject: user.js for Bugzilla In-Reply-To: References: <5uKdnW20NP9fYhvJnZ2dnUU7-T-dnZ2d@mozilla.org> Message-ID: <54872731.2090204@mozilla.org> On 09/12/14 16:33, Jochen Wiedmann wrote: > Sounds very much like duplicating both > > a) Greasemonkey to me, Greasemonkey isn't available for all browsers. > with lots of possibilities for XSS attacks as a bonus and How so? > b) superceding the existing extension system. End users can't install extensions. Gerv From mcote at mozilla.com Tue Dec 9 16:49:16 2014 From: mcote at mozilla.com (=?windows-1252?Q?Mark_C=F4t=E9?=) Date: Tue, 09 Dec 2014 11:49:16 -0500 Subject: user.js for Bugzilla In-Reply-To: References: <5uKdnW20NP9fYhvJnZ2dnUU7-T-dnZ2d@mozilla.org> Message-ID: <-cGdnXmBVNuRtRrJnZ2dnUU7-dudnZ2d@mozilla.org> On 2014-12-09 11:37 AM, Denis Roy wrote: > On 12/09/2014 11:33 AM, Jochen Wiedmann wrote: >> Sounds very much like duplicating both >> >> a) Greasemonkey to me, with lots of possibilities for XSS attacks as a >> bonus and >> b) superceding the existing extension system. >> >> I'd be -1. > > +1 on that -1 > > > We have dev teams who share GreaseMonkey scripts... perhaps have a way > for users of an installation to share those? Not keen about this either. It sounds like a support nightmare if everyone has their own custom JS. It's bad enough right now with only a couple Bugzilla-specific add-ons. Mark _______________________________________________ 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 Dec 9 16:53:23 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Dec 2014 16:53:23 +0000 Subject: user.js for Bugzilla In-Reply-To: <-cGdnXmBVNuRtRrJnZ2dnUU7-dudnZ2d@mozilla.org> References: <5uKdnW20NP9fYhvJnZ2dnUU7-T-dnZ2d@mozilla.org> <-cGdnXmBVNuRtRrJnZ2dnUU7-dudnZ2d@mozilla.org> Message-ID: <54872903.7060706@mozilla.org> On 09/12/14 16:49, Mark C?t? wrote: > Not keen about this either. It sounds like a support nightmare if > everyone has their own custom JS. It's bad enough right now with only a > couple Bugzilla-specific add-ons. If it were built into Bugzilla, we could put a simple "off switch" on each page, to reload the page without it. Then, if anyone had a problem, we could simply say "can you reproduce it with your customizations turned off?". At the moment, there's no control at all. Also, if it were built into Bugzilla, we could offer common libraries to simplify common tasks, like a callback hook for registering "bug submit" events (where I could e.g. check if it was a Bugzilla product bug being RESOLVED FIXED, and set the TM if so). If Greasemonkey scripts are used, stuff like that has to be duplicated in each script, because scripts can't reliably reference one another or guarantee presence. Gerv From mcote at bugzilla.org Tue Dec 9 17:08:22 2014 From: mcote at bugzilla.org (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Tue, 09 Dec 2014 12:08:22 -0500 Subject: Next project meeting Message-ID: At the last project meeting[1] we decided that the next scheduled meeting day, December 24th, would probably be inconvenient, given that many people would either be on or about to embark on holidays. Thus it was proposed that we meet a week earlier, on December 17th, instead, but *only* if we have any agenda items (beyond the usual recap, which we'd move forward to January's meeting if it's the only item). I will send out a note on the 16th indicating if we'll be meeting or not based on the agenda at that time. Mark [1] https://wiki.mozilla.org/Bugzilla:Meetings:2014-11-26 -- Mark C?t? Assistant Project Lead, Bugzilla _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Tue Dec 9 17:45:10 2014 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 09 Dec 2014 18:45:10 +0100 Subject: user.js for Bugzilla In-Reply-To: <-cGdnXmBVNuRtRrJnZ2dnUU7-dudnZ2d@mozilla.org> References: <5uKdnW20NP9fYhvJnZ2dnUU7-T-dnZ2d@mozilla.org> <-cGdnXmBVNuRtRrJnZ2dnUU7-dudnZ2d@mozilla.org> Message-ID: <54873526.8000000@gmail.com> Le 09. 12. 14 17:49, Mark C?t? a ?crit : > Not keen about this either. I'm opposed to this too. Too easy to shoot yourself in the foot. And if someone manages to put evil JS code, you are vulnerable to XSS or worse. And your example about setting the TM automatically is bad. ;) It's too easy to forget to set it and let Bugzilla guess what the TM must be. It's much easier to track bugs with no TM set than to track bugs with the wrong TM set. LpSolit From lpsolit at gmail.com Tue Dec 9 17:47:14 2014 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 09 Dec 2014 18:47:14 +0100 Subject: Filing bugs on Landfill; upgrading Perl on Landfill In-Reply-To: <54871607.6030508@mozilla.org> References: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> <54845259.6040500@gmail.com> <548459FB.9090509@sci.fi> <54871607.6030508@mozilla.org> Message-ID: <548735A2.7070900@gmail.com> Le 09. 12. 14 16:32, Gervase Markham a ?crit : > The last set of changes I did, I did with authority of a deputy project > lead. This doesn't mean they know all the details. :) It doesn't hurt to ask first. There was no hurry to do the cleanup. LpSolit From gerv at mozilla.org Tue Dec 9 18:27:48 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Dec 2014 18:27:48 +0000 Subject: Filing bugs on Landfill; upgrading Perl on Landfill In-Reply-To: <548735A2.7070900@gmail.com> References: <4LCdneTjIKRGHR7JnZ2dnUU7-dmdnZ2d@mozilla.org> <54845259.6040500@gmail.com> <548459FB.9090509@sci.fi> <54871607.6030508@mozilla.org> <548735A2.7070900@gmail.com> Message-ID: <54873F24.7030906@mozilla.org> On 09/12/14 17:47, Fr?d?ric Buclin wrote: > Le 09. 12. 14 16:32, Gervase Markham a ?crit : >> The last set of changes I did, I did with authority of a deputy project >> lead. > > This doesn't mean they know all the details. :) It doesn't hurt to ask > first. There was no hurry to do the cleanup. There was no significant negative impact from the cleanup (some tools went missing for 24 hours), so I still maintain it was fine. When you say "there's no hurry"... this has needed doing for months, and I finally found some time when everyone else was having Thanksgiving. So in one sense there was no hurry, and in another sense it was exactly the right moment. Gerv From mcote at bugzilla.org Tue Dec 16 16:59:30 2014 From: mcote at bugzilla.org (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Tue, 16 Dec 2014 11:59:30 -0500 Subject: Next project meeting In-Reply-To: References: Message-ID: With less than 24 hours until the next scheduled meeting and no extra items on the agenda, I'm going to cancel December's meeting. The next meeting will be on January 28th. Mark On 2014-12-09 12:08 PM, Mark C?t? wrote: > At the last project meeting[1] we decided that the next scheduled > meeting day, December 24th, would probably be inconvenient, given that > many people would either be on or about to embark on holidays. Thus it > was proposed that we meet a week earlier, on December 17th, instead, but > *only* if we have any agenda items (beyond the usual recap, which we'd > move forward to January's meeting if it's the only item). > > I will send out a note on the 16th indicating if we'll be meeting or not > based on the agenda at that time. > > Mark > > > [1] https://wiki.mozilla.org/Bugzilla:Meetings:2014-11-26 > -- Mark C?t? Assistant Project Lead, Bugzilla _______________________________________________ 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 Dec 17 10:49:08 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 17 Dec 2014 10:49:08 +0000 Subject: docs_urlbase Message-ID: We are now encouraging people to get their Bugzilla installs from a stable branch in git. Git does not have the HTML docs checked in - they need to be built. The current default value of docs_urlbase is 'docs/%lang%/html/', which means that by default, when you install Bugzilla, all the Help links will 404. We should make docs_urlbase more intelligent, such that it uses HTML docs on the local filesystem if they exist (i.e. have been built) but otherwise falls back to the appropriate version on ReadTheDocs, based on BUGZILLA_VERSION. (Do we have a way for Bugzilla to tell that the version it's running is the current unreleased trunk? If not, that case might be a bit tricky.) Could we even eliminate the parameter altogether in favour of this scheme, or is there some use case I'm missing? If that seems like too much for the 5.0 branch, we should change the default there to the 5.0 branch docs on ReadTheDocs, and document in the parameter description what value to use for local docs. Comments? 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 Dec 17 11:22:55 2014 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 17 Dec 2014 12:22:55 +0100 Subject: docs_urlbase In-Reply-To: References: Message-ID: <5491678F.4000507@gmail.com> Le 17. 12. 14 11:49, Gervase Markham a ?crit : > We should make docs_urlbase more intelligent, such that it uses HTML > docs on the local filesystem if they exist (i.e. have been built) but > otherwise falls back to the appropriate version on ReadTheDocs You are 7 years and a lot of Bugzilla meetings behind: https://bugzilla.mozilla.org/show_bug.cgi?id=399068 > If that seems like too much for the 5.0 branch Bugzilla never had compiled HTML documentation included, so there is nothing new here. So there is no urge to do it right now for 5.0. LpSolit From gerv at mozilla.org Wed Dec 17 12:52:50 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 17 Dec 2014 12:52:50 +0000 Subject: docs_urlbase In-Reply-To: References: Message-ID: On 17/12/14 11:22, Fr?d?ric Buclin wrote: > You are 7 years and a lot of Bugzilla meetings behind: > > https://bugzilla.mozilla.org/show_bug.cgi?id=399068 OK :-) I guess I thought "broken Help links by default" was a big enough bug that surely it wouldn't be so old... >> If that seems like too much for the 5.0 branch > > Bugzilla never had compiled HTML documentation included, so there is > nothing new here. So there is no urge to do it right now for 5.0. But all the Help links are broken by default! That's a horrible user experience. I think we should definitely either: * Document in the installation instructions that people should compile the docs; or * Document in the installation instructions that everyone needs to change docs_urlbase (then why not change the default?); or * Change the default docs_urlbase to ReadTheDocs and document what to use for local docs. We should surely do one of these things. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From dkl at mozilla.com Wed Dec 17 15:37:42 2014 From: dkl at mozilla.com (David Lawrence) Date: Wed, 17 Dec 2014 10:37:42 -0500 Subject: docs_urlbase In-Reply-To: References: Message-ID: <5491A346.3020309@mozilla.com> Well in any case, we should definitely do #1 anyway as people will want to know how to compile and host their own docs. As for #3, I am not sure how admins feel about Bugzilla redirecting to external hosts by default that they do not control. I agree also that by leaving the docs_urlbase pointing to local paths by default gives a bad out-of-box experience for Bugzilla when they keep getting 404's. What if we make the docs_urlbase one of the "must-set" params that show up when a admin accesses a new Bugzilla instance for the first time? Then we can have the param's description explain the different choices giving the option to just use ReadTheDocs if desired. dkl On 12/17/2014 07:52 AM, Gervase Markham wrote: > On 17/12/14 11:22, Fr?d?ric Buclin wrote: >> You are 7 years and a lot of Bugzilla meetings behind: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=399068 > OK :-) I guess I thought "broken Help links by default" was a big enough > bug that surely it wouldn't be so old... > >>> If that seems like too much for the 5.0 branch >> Bugzilla never had compiled HTML documentation included, so there is >> nothing new here. So there is no urge to do it right now for 5.0. > But all the Help links are broken by default! That's a horrible user > experience. I think we should definitely either: > > * Document in the installation instructions that people should compile > the docs; > or > * Document in the installation instructions that everyone needs to > change docs_urlbase (then why not change the default?); > or > * Change the default docs_urlbase to ReadTheDocs and document what to > use for local docs. > > We should surely do one of these things. > > 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: > -- David Lawrence dkl at mozilla.com bugzilla.mozilla.org _______________________________________________ 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 Dec 17 15:41:59 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 17 Dec 2014 15:41:59 +0000 Subject: docs_urlbase In-Reply-To: <5491A346.3020309@mozilla.com> References: <5491A346.3020309@mozilla.com> Message-ID: <5491A447.8000606@mozilla.org> On 17/12/14 15:37, David Lawrence wrote: > Well in any case, we should definitely do #1 anyway as people will want to know how to > compile and host their own docs. As for #3, I am not sure how admins feel about Bugzilla > redirecting to external hosts by default that they do not control. It's not redirecting, it's linking, which is an important distinction. Many free software packages I've seen have online manuals. I don't think this is a deeply unexpected thing. I just want Bugzilla to work by default with the minimum number of install steps. > What if we make the docs_urlbase one of the "must-set" params that show up when a admin > accesses a new Bugzilla instance for the first time? Then we can have the param's description > explain the different choices giving the option to just use ReadTheDocs if desired. Do we have any reason to believe that more than a tiny proportion of people compile the docs? Can we make it a must-set param so they consider it, but default to RTD so they can just leave it if they want the obvious thing? (We'd ideally need some intelligence so if they ever upgraded, it would move to the newer docs for the version they have. Either we put that intelligence into the 5.0 codebase now, or we have to write a migration path for whatever static URL we set.) Gerv From lpsolit at gmail.com Wed Dec 17 15:52:16 2014 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 17 Dec 2014 16:52:16 +0100 Subject: docs_urlbase In-Reply-To: <5491A447.8000606@mozilla.org> References: <5491A346.3020309@mozilla.com> <5491A447.8000606@mozilla.org> Message-ID: <5491A6B0.6090906@gmail.com> Le 17. 12. 14 16:41, Gervase Markham a ?crit : > Do we have any reason to believe that more than a tiny proportion of > people compile the docs? Can we make it a must-set param so they > consider it, but default to RTD so they can just leave it if they want > the obvious thing? Do not make it a must-set parameter. Really, it's not one of those critical parameters which must be set absolutely when running Bugzilla for the first time. > (We'd ideally need some intelligence so if they ever upgraded, it would > move to the newer docs for the version they have. Either we put that > intelligence into the 5.0 codebase now, or we have to write a migration > path for whatever static URL we set.) All the details are in the bug I mentioned in a previous message. There is really no need to talk about this here (we have a bug-tracker exactly for this purpose). This is not something which suddenly becomes urgent. This problem exists for more than 7 years. LpSolit From gerv at mozilla.org Mon Dec 22 17:41:50 2014 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 22 Dec 2014 17:41:50 +0000 Subject: Documentation help wanted for specific topics Message-ID: <67qdnY6iKdJDygXJnZ2dnUU7-TmdnZ2d@mozilla.org> There are some bits of Bugzilla which are not well documented at the moment, because I (and often other Bugzilla devs) do not have much experience with them. In particular, this includes: * Installing on Windows * Installing on Mac OS * Oracle * email_in.pl (incoming email gateway) * LDAP authentication * RADIUS authentication * Groups If you know something, anything at all, about those bits of Bugzilla, please drop me an email. You won't necessarily have to write the documentation yourself - merely having experience would be very helpful! Thanks, Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Mon Dec 22 17:50:03 2014 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 22 Dec 2014 18:50:03 +0100 Subject: Documentation help wanted for specific topics In-Reply-To: <67qdnY6iKdJDygXJnZ2dnUU7-TmdnZ2d@mozilla.org> References: <67qdnY6iKdJDygXJnZ2dnUU7-TmdnZ2d@mozilla.org> Message-ID: <549859CB.2070300@gmail.com> Le 22. 12. 14 18:41, Gervase Markham a ?crit : > because I (and often other Bugzilla devs) do not have much > experience with them. In particular, this includes: > * Groups Haha, it would be dramatic if Bugzilla devs didn't have much experience or knowledge with groups. All the Bugzilla security relies on groups. :) LpSolit From jochen.wiedmann at gmail.com Mon Dec 22 18:53:02 2014 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Mon, 22 Dec 2014 19:53:02 +0100 Subject: Documentation help wanted for specific topics In-Reply-To: <67qdnY6iKdJDygXJnZ2dnUU7-TmdnZ2d@mozilla.org> References: <67qdnY6iKdJDygXJnZ2dnUU7-TmdnZ2d@mozilla.org> Message-ID: Hi, Gervase, I pride myself to have some experience with installation on Windows. Jochen On Mon, Dec 22, 2014 at 6:41 PM, Gervase Markham wrote: > There are some bits of Bugzilla which are not well documented at the > moment, because I (and often other Bugzilla devs) do not have much > experience with them. In particular, this includes: > > * Installing on Windows > * Installing on Mac OS > * Oracle > * email_in.pl (incoming email gateway) > * LDAP authentication > * RADIUS authentication > * Groups > > If you know something, anything at all, about those bits of Bugzilla, > please drop me an email. You won't necessarily have to write the > documentation yourself - merely having experience would be very helpful! > > Thanks, > > Gerv > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > -- Our time is just a point along a line that runs forever with no end. (Al Stewart, Lord Grenville) From gerv at mozilla.org Mon Dec 22 21:37:25 2014 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 22 Dec 2014 21:37:25 +0000 Subject: Documentation help wanted for specific topics In-Reply-To: <549859CB.2070300@gmail.com> References: <67qdnY6iKdJDygXJnZ2dnUU7-TmdnZ2d@mozilla.org> <549859CB.2070300@gmail.com> Message-ID: <54988F15.2030004@mozilla.org> On 22/12/14 17:50, Fr?d?ric Buclin wrote: >> * Groups > > Haha, it would be dramatic if Bugzilla devs didn't have much experience > or knowledge with groups. All the Bugzilla security relies on groups. :) Well, it's by far the most common topic for questions, and our documentation is sparse and confusing. And I don't feel I understand groups well enough to rewrite it. If you do (and I think you do!) then that would be an awesome Christmas contribution. :-) Gerv From gerv at mozilla.org Tue Dec 23 13:47:39 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 23 Dec 2014 13:47:39 +0000 Subject: Documentation help wanted for specific topics In-Reply-To: References: <67qdnY6iKdJDygXJnZ2dnUU7-TmdnZ2d@mozilla.org> Message-ID: <5499727B.4000904@mozilla.org> On 22/12/14 18:53, Jochen Wiedmann wrote: > I pride myself to have some experience with installation on Windows. Wonderful :-) Might you be able to check over our Windows installation documentation here: http://bugzilla.readthedocs.org/en/latest/installing/windows.html and give us your feedback? (Also the sub-pages about IIS and about Apache on Windows.) You are welcome to submit patches, or file bugs, or email me with suggestions, whatever's easiest for you. I would like to have enough confidence in these Windows docs to take the disclaimer off the top. Gerv From damien.nozay at gmail.com Mon Dec 29 21:17:40 2014 From: damien.nozay at gmail.com (Damien) Date: Mon, 29 Dec 2014 13:17:40 -0800 Subject: bugzilla changelog pointing to BZR instead of GIT? Message-ID: http://www.bugzilla.org/status/changes.html Half the links go to bonsai.mozilla.org while the other half goes to bzr.mozilla.org. If the CVS / BZR imports were all successful, and GIT is the source of truth, maybe someone can spend some cycles on fixing the changelog page. Thanks, damien -------------- next part -------------- An HTML attachment was scrubbed... URL: