From gerv at mozilla.org Thu May 1 15:14:19 2014 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 01 May 2014 16:14:19 +0100 Subject: Bugzilla's documentation Message-ID: [I had hoped to talk about this in the meeting, but I had to leave.] Bugzilla's documentation has had the same structure since at least Bugzilla 2.16 in 2006, and probably earlier. Until recently, it was maintained in hard-to-compile XML, which led to strong incentives to either not update the docs, or update them in the most minimal way possible e.g. by adding a paragraph of text in the middle somewhere. Or, people documented things on the wiki instead because it was easier - there are several documents on the wiki which should be part of the manual.[0] The recent move to ReST removed some extraneous bits like the glossary but (by design) did not make any significant change to the content or organization. So the result is still long-winded, full of conflicting "voices" and not very easy to use. Now that we've moved to ReST, we have the capability to rearrange, rethink and rewrite the documentation much more easily. Some possible ideas: * Make a better way of getting a set of install instructions which contain only the parts relevant to you (there are several ways this could be achieved) * Include resources which are currently external but really belong in the manual (we'd need to seek authorial permission for licensing reasons) * Remove obsolete stuff (e.g. some of Troubleshooting, Contrib) I did try and do this once before, many years ago. Even then, there was no shortage of improvements to make! However, IIRC it foundered at the review stage - reviewing documentation changes as a massive patch proved to be very hard work, lots of people felt it had to be absolutely right for them before it was checked in, and one or two controversial issues held it up until it died a sad death by asphyxiation. I don't want this to happen again. So here is my proposal: if I commit to doing the hard work of reorganizing and rewriting the docs on a branch, incorporating external material and generally making them fit for the year 2014, will one or two other Bugzilla devs commit to reviewing them _as_an_entire_document_ (as opposed to as a patch), and will everyone else consent to trust me and that person to the extent that we can check in the branch after it passes their review, and fix up any parts that you don't like later? If you are willing to be the reviewer, say so. And if you _object_ to trusting me and the reviewer to improve the docs together, say so. Gerv [0] E.g. https://wiki.mozilla.org/Bugzilla:Moving_From_CVS_To_Bazaar or some of the stuff in https://wiki.mozilla.org/Bugzilla:FAQ . _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mcote at mozilla.com Sat May 3 16:35:46 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Sat, 03 May 2014 12:35:46 -0400 Subject: Bugzilla's documentation In-Reply-To: References: Message-ID: Sounds like a great idea! In addition to your suggestions, I would vote for a section on WebServices. The associated API docs are confusing at first; a readable section explaining the basic concepts and how to use the API docs would, I think, be really useful. I always feel bad when people ask for docs on the new native REST and I have to point them to http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/Server/REST.html. (That reminds me that I still have to move around the REST docs on the wiki...) Anyway, I am not a dev, but I would be willing to read through your new docs at least for consistency, style, grammar, etc. Mark On 2014-05-01, 11:14 AM, Gervase Markham wrote: > [I had hoped to talk about this in the meeting, but I had to leave.] > > Bugzilla's documentation has had the same structure since at least > Bugzilla 2.16 in 2006, and probably earlier. Until recently, it was > maintained in hard-to-compile XML, which led to strong incentives to > either not update the docs, or update them in the most minimal way > possible e.g. by adding a paragraph of text in the middle somewhere. Or, > people documented things on the wiki instead because it was easier - > there are several documents on the wiki which should be part of the > manual.[0] > > The recent move to ReST removed some extraneous bits like the glossary > but (by design) did not make any significant change to the content or > organization. So the result is still long-winded, full of conflicting > "voices" and not very easy to use. > > Now that we've moved to ReST, we have the capability to rearrange, > rethink and rewrite the documentation much more easily. Some possible ideas: > > * Make a better way of getting a set of install instructions which > contain only the parts relevant to you (there are several ways this > could be achieved) > > * Include resources which are currently external but really belong in > the manual (we'd need to seek authorial permission for licensing reasons) > > * Remove obsolete stuff (e.g. some of Troubleshooting, Contrib) > > I did try and do this once before, many years ago. Even then, there was > no shortage of improvements to make! However, IIRC it foundered at the > review stage - reviewing documentation changes as a massive patch proved > to be very hard work, lots of people felt it had to be absolutely right > for them before it was checked in, and one or two controversial issues > held it up until it died a sad death by asphyxiation. I don't want this > to happen again. > > So here is my proposal: if I commit to doing the hard work of > reorganizing and rewriting the docs on a branch, incorporating external > material and generally making them fit for the year 2014, will one or > two other Bugzilla devs commit to reviewing them _as_an_entire_document_ > (as opposed to as a patch), and will everyone else consent to trust me > and that person to the extent that we can check in the branch after it > passes their review, and fix up any parts that you don't like later? > > If you are willing to be the reviewer, say so. And if you _object_ to > trusting me and the reviewer to improve the docs together, say so. > > Gerv > > [0] E.g. https://wiki.mozilla.org/Bugzilla:Moving_From_CVS_To_Bazaar or > some of the stuff in https://wiki.mozilla.org/Bugzilla:FAQ . > _______________________________________________ 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 May 8 15:02:52 2014 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 08 May 2014 16:02:52 +0100 Subject: Bugzilla's documentation In-Reply-To: References: Message-ID: tl;dr: it wouldn't be too hard to relicense the Bugzilla docs as CC-BY-SA. Should we ask people and get it done? On 01/05/14 16:14, Gervase Markham wrote: > * Include resources which are currently external but really belong in > the manual (we'd need to seek authorial permission for licensing reasons) I was working on this part. The wiki is CC-BY-SA and the manual is GFDL. I was making a list of people who had contributed under CC-BY-SA to get them to say OK to GFDL, but then I thought: why not the other way around? GFDL is barely used these days; CC-BY-SA has eaten its lunch and dinner. It also makes 2-way copying with the wiki and other sources much easier. Is it worth making an effort to list all the people who have patched Bugzilla's docs, and asking them if we can relicense to CC-BY-SA? We can get the info from source control. There are a few key people. Barnboy wrote most of the original doc, many years ago - but his web page says he "gave copyright to the Mozilla Foundation" - see http://barnson.org/resume. Not sure if we got that in writing, but I guess it means he'd say yes. If he says yes, Jake says yes, Max says yes, and all the current devs say yes, I think we'd be most of the way there. The list of significant contributors to the docs is not that long. What do people think? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From glob at mozilla.com Mon May 12 03:40:39 2014 From: glob at mozilla.com (Byron Jones) Date: Mon, 12 May 2014 11:40:39 +0800 Subject: Bugzilla's documentation In-Reply-To: References: Message-ID: <537042B7.50708@mozilla.com> Gervase Markham wrote: > I was working on this part. The wiki is CC-BY-SA and the manual is GFDL. > I was making a list of people who had contributed under CC-BY-SA to get > them to say OK to GFDL, but then I thought: why not the other way around? > .. > If he says yes, Jake says yes, Max says yes, and all the current devs > say yes, I think we'd be most of the way there. The list of significant > contributors to the docs is not that long. > > What do people think? makes sense to me. -- byron jones - :glob - bugzilla.mozilla.org team - -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Fri May 16 15:05:51 2014 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 16 May 2014 17:05:51 +0200 Subject: Bugzilla has a new QA manager Message-ID: <5376294F.9000103@gmail.com> Hi all, A quick note to let you know that David Lawrence (dkl) is the new QA manager for the Bugzilla project. These last few weeks, he did a great job to migrate our testing installations from Tinderbox to Travis: https://travis-ci.org/dklawren/bugzilla QA always needs love. Writing new testcases is not the most funny part of development, but they are needed to make sure that existing and new features work as designed. So if you want to help, do not hesitate! :) https://wiki.mozilla.org/Bugzilla:QA http://git.mozilla.org/?p=bugzilla/qa.git;a=summary LpSolit From mcote at mozilla.com Fri May 16 17:51:19 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Fri, 16 May 2014 13:51:19 -0400 Subject: Triage party follow-up Message-ID: Thanks to all who came out for our triage party! It was very successful. That day, we had changes to 117 bugs, compared to most days where under 10 bugs are changed. 48 bugs were resolved, and 16 more bugs were moved over to the new Extension Ideas component. Great work! Is there anyone interested in doing this again in a week or two at a different time? I'm not sure what the availability is of people who couldn't make it to the last one; would someone like to propose one? Mark _______________________________________________ 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 Fri May 16 20:36:18 2014 From: dkl at mozilla.com (David Lawrence) Date: Fri, 16 May 2014 16:36:18 -0400 Subject: Change from Tinderbox to Travis CI for automated Bugzilla testing Message-ID: <537676C2.2070002@mozilla.com> Greetings For a month or so, I have been working on getting our automated Bugzilla QA test suite up and running with the Travis Continuous Integration system[1] (Travis CI for short). Up until now we have been using Tinderbox[2] for performing our automated testing. Mozilla WebOps have been wanting to decommission Tinderbox for quite some time as the code base is no longer maintained and Bugzilla[3] was the only project still actively using it. Travis CI has a free service option for open source projects which is what we will be using for Bugzilla. It requires the code to be located in github.com and since we now have a read-only mirror of all Bugzilla branches to github.com, Travis CI became a good option. Basically whenever a commit is made, Travis CI fires off workers that will run the automated test suite and record the results. All is required is a configuration file in the root directory of the code. The file contains some basic information such as programming language, how to get the test environment set up, etc. So starting now, Tinderbox will no longer be running our automated test suite and we will instead using Travis CI[3]. Any failures or changes in the testing status will be announced in the IRC channels #bugzilla and #qa-bugzilla. We will be working on improving our test coverage as well as enabling tests for the master Bugzilla branch which we have not done up until now. If you have any questions, feel free to email or ping me on IRC in #bugzilla. Thanks David Lawrence Bugzilla Release Manager [1] https://travis-ci.org [2] http://www-archive.mozilla.org/projects/tinderbox/ [3] https://travis-ci.org/bugzilla/bugzilla -- David Lawrence dkl at mozilla.com From theycallmefish at gmail.com Sat May 17 16:26:31 2014 From: theycallmefish at gmail.com (Ryan Wilson) Date: Sat, 17 May 2014 09:26:31 -0700 (PDT) Subject: Triage party follow-up In-Reply-To: References: Message-ID: On Friday, May 16, 2014 11:51:19 AM UTC-6, Mark C?t? wrote: > Thanks to all who came out for our triage party! It was very > > successful. That day, we had changes to 117 bugs, compared to most days > > where under 10 bugs are changed. 48 bugs were resolved, and 16 more > > bugs were moved over to the new Extension Ideas component. Great work! > > > > Is there anyone interested in doing this again in a week or two at a > > different time? I'm not sure what the availability is of people who > > couldn't make it to the last one; would someone like to propose one? > > > > Mark Count me in on another triage session. _______________________________________________ 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 May 23 16:27:20 2014 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 May 2014 17:27:20 +0100 Subject: Change from Tinderbox to Travis CI for automated Bugzilla testing In-Reply-To: References: Message-ID: (Great news!) On 16/05/14 21:36, David Lawrence wrote: > So starting now, Tinderbox will no longer be running our automated > test suite and we will instead using Travis CI[3]. Is this on all supported branches? 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 May 23 16:27:35 2014 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 May 2014 17:27:35 +0100 Subject: Triage party follow-up In-Reply-To: References: Message-ID: On 16/05/14 18:51, Mark C?t? wrote: > Is there anyone interested in doing this again in a week or two at a > different time? I'm not sure what the availability is of people who > couldn't make it to the last one; would someone like to propose one? I'd happily do it again. 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 Fri May 23 16:40:25 2014 From: dkl at mozilla.com (David Lawrence) Date: Fri, 23 May 2014 12:40:25 -0400 Subject: Change from Tinderbox to Travis CI for automated Bugzilla testing In-Reply-To: References: Message-ID: <537F79F9.701@mozilla.com> Here is the breakdown of the test matrix currently: Trunk - checksetup-mysql (Pg to come later) - documentation (Using Sphinx) - perl 5.10.1 sanity - perl 5.12.3 sanity - perl 5.14.2 sanity - perl 5.16.1 sanity 4.4 - QA MySQL (QA = webservices/selenium) - QA Pg - documentation (old documentation build method for 4.4 and older) - perl 5.10.1 sanity - perl 5.12.3 sanity 4.2 - QA MySQL - QA Pg - documentation - perl 5.10.1 sanity - perl 5.12.3 sanity 4.0 (This branch can get along without CI testing but will leave up for now) - QA MySQL - QA Pg - documentation - perl 5.10.1 sanity - perl 5.12.3 sanity One thing we would like to do soon is to also run the QA test suite on changes to 'master' for each commit. We were not doing that on Tinderbox really and currently the test cases need work to pass properly with 'master' so I have not turned it on yet. Don't want to see all of the red flags before we have the tests fixed. dkl On 05/23/2014 12:27 PM, Gervase Markham wrote: > (Great news!) > > On 16/05/14 21:36, David Lawrence wrote: >> So starting now, Tinderbox will no longer be running our automated >> test suite and we will instead using Travis CI[3]. > > Is this on all supported branches? > > 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 From mcote at mozilla.com Fri May 23 20:12:51 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Fri, 23 May 2014 16:12:51 -0400 Subject: Triage party follow-up In-Reply-To: References: Message-ID: <35GdnXuXqvFeNuLOnZ2dnUVZ_tGdnZ2d@mozilla.org> Haven't heard any suggestions for alternate times, so should we keep the same time as last time (14:00 UTC)? Perhaps the week after the meeting (Wed, May 2)? Mark On 2014-05-23, 12:27 PM, Gervase Markham wrote: > On 16/05/14 18:51, Mark C?t? wrote: >> Is there anyone interested in doing this again in a week or two at a >> different time? I'm not sure what the availability is of people who >> couldn't make it to the last one; would someone like to propose one? > > I'd happily do it again. > > 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 May 26 07:47:16 2014 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 May 2014 08:47:16 +0100 Subject: Triage party follow-up In-Reply-To: <35GdnXuXqvFeNuLOnZ2dnUVZ_tGdnZ2d@mozilla.org> References: <35GdnXuXqvFeNuLOnZ2dnUVZ_tGdnZ2d@mozilla.org> Message-ID: <5382F184.1040101@mozilla.org> On 23/05/14 21:12, Mark C?t? wrote: > Haven't heard any suggestions for alternate times, so should we keep the > same time as last time (14:00 UTC)? Perhaps the week after the meeting > (Wed, May 2)? May 2nd isn't a Wednesday, and it's also in the past. June 2nd is also not a Wednesday. Try again? :-)) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mcote at mozilla.com Mon May 26 15:20:28 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Mon, 26 May 2014 11:20:28 -0400 Subject: Triage party follow-up In-Reply-To: <5382F184.1040101@mozilla.org> References: <35GdnXuXqvFeNuLOnZ2dnUVZ_tGdnZ2d@mozilla.org> <5382F184.1040101@mozilla.org> Message-ID: <-IKdnVdyG6Qhxh7OnZ2dnUVZ_qadnZ2d@mozilla.org> On 2014-05-26, 3:47 AM, Gervase Markham wrote: > On 23/05/14 21:12, Mark C?t? wrote: >> Haven't heard any suggestions for alternate times, so should we keep the >> same time as last time (14:00 UTC)? Perhaps the week after the meeting >> (Wed, May 2)? > > May 2nd isn't a Wednesday, and it's also in the past. June 2nd is also > not a Wednesday. > > Try again? :-)) Ah I think I meant to say "the week after May 28". Anyway, to be precise, I suggest Wednesday, June 4, for the next triage party. Mark _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mcote at mozilla.com Thu May 29 17:17:22 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Thu, 29 May 2014 13:17:22 -0400 Subject: Releasing 5.0 sooner rather than later Message-ID: <-pGdnT2i7JQ_9hrOnZ2dnUVZ_oKdnZ2d@mozilla.org> At the Bugzilla meeting today[1], two important, related items were agreed upon: 1. We should release more often, approximately every six months, with whatever features are ready at that time. 2. We should release version 5.0 as soon as possible. With regards to point 1, rather than creating a list of features that should go into a particular version, we will release whatever we have ready in the master branch every six months or so. This is to avoid having features that are ready and tested languish while other features are implemented. Case in point: the REST API was completed last year but is still available only in the master branch. We will keep semantic versioning, that is, releases with breaking or other major changes will have a major version bump (e.g. 5.0), and smaller changes will have a minor version bump (e.g. 5.2). Critical bug fixes, particularly for security vulnerabilities, will continue to be released to all applicable supported versions at any time, as needed, with patch version numbers (e.g. 5.2.1). This means that we may have major versions released in succession, but with our current policy of supporting three versions at any time, users will have the choice of putting off an upgrade for a year if they don't want to deal with two major upgrades in a row. We will also announce that an upcoming version will have breaking or other major changes as soon as possible in the development cycle. With this in mind, we decided to do a release as soon as possible. Because master currently requires a newer Perl version than 4.4, we are calling this release 5.0. Incomplete features planned for 5.0, including the Sandstone skin, markdown support in comments, inline history, and a few others, will be punted off to the next version. We are waiting for one important bug fix, which should be completed in a week or so, at which point we will create a 5.0 branch and start the QA cycle. Mark [1] https://wiki.mozilla.org/Bugzilla:Meetings:2014-05-28 _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla