From gerv at mozilla.org Tue Oct 7 08:06:30 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 07 Oct 2014 09:06:30 +0100 Subject: Change the param() interfac? Message-ID: Hi everyone, As you know, we have just done a security release. The bug is written up here: http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-perl-web-applications/ I have been pointed at this article from 5 years ago: http://bulknews.typepad.com/blog/2009/12/perl-why-parameters-sucks-and-what-we-can-do.html which agrees that the param() interface is not awesome, although it doesn't cover the security concerns we now know it raises. It seems that many frameworks don't like this way of doing things, and have come up with alternatives which are less of a footgun. The article documents several alternatives, of which I think the leading two are: 1) $cgi->param('foo') always returns scalar $cgi->arrayparam('foo') always returns a list 2) $cgi->scalarparam('foo') always returns scalar $cgi->arrayparam('foo) always returns array $cgi->param('foo') throws an error to stop you using it and make you make a specific decision (Let's not bikeshed on the function names before we've chosen an approach.) I strongly think the best way to avoid future security holes is to make the pattern which leads to them impossible. I know we now have a test to detect the particular pattern which caused these bugs, but I'm not willing to bet any money that there aren't other places or ways or contexts this could happen. So I think we should switch the Bugzilla codebase over to one of these two patterns, using the fact that we control the CGI object (Bugzilla/CGI.pm) to alter the behaviour of the functions. I know LpSolit has expressed reservations, and that dveditz (Mozilla security guy) is in favour. Comments? 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 Oct 7 13:37:16 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 07 Oct 2014 14:37:16 +0100 Subject: How do Bugzilla installs use git? Message-ID: Come 5.0, we plan to update our docs to tell installations to use git to get the code. However, I'm not entirely clear on how exactly that works. Maybe I'm the only one; if so, clue me in :-) It seems to me that there are 3 operations a site would need to do: 1) Get the code initially (and perhaps then say which version they wanted to run) 2) Update to a new point release (e.g. a security release), merging in changes they've made 3) Update to a later version, merging in changes they've made It would be good if 2) and 3) had a dry-run option. What git commands do we use for these things? Here's my guesses: 1) git clone https://git.mozilla.org/bugzilla/bugzilla cd git checkout Open questions: a) Will this lead them to have an intermediate version, say if the branch name is "4.4", 4.4.2 is stable and we are in the middle of putting together 4.4.3? Do we need a "4.4-stable" branch and equivalents that people can check out? Or do we do the assembly on a branch and merge back in only at the end? 2) git pull Open questions: b) Do we need git pull instead, or is this OK? 3) git pull git checkout For reference, our list of current branches and tags is here: http://git.mozilla.org/?p=bugzilla/bugzilla.git Is this all correct? Gerv _______________________________________________ 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 Tue Oct 7 17:08:29 2014 From: damien.nozay at gmail.com (Damien) Date: Tue, 7 Oct 2014 10:08:29 -0700 Subject: Change the param() interfac? In-Reply-To: References: Message-ID: Hi folks, isn't there some kind of perl lint tool to tell you these kinds of constructs are bogus & dangerous? On Tue, Oct 7, 2014 at 1:06 AM, Gervase Markham wrote: > Hi everyone, > > As you know, we have just done a security release. The bug is written up > here: > > http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-perl-web-applications/ > > I have been pointed at this article from 5 years ago: > > > http://bulknews.typepad.com/blog/2009/12/perl-why-parameters-sucks-and-what-we-can-do.html > > which agrees that the param() interface is not awesome, although it > doesn't cover the security concerns we now know it raises. It seems that > many frameworks don't like this way of doing things, and have come up > with alternatives which are less of a footgun. The article documents > several alternatives, of which I think the leading two are: > > 1) > > $cgi->param('foo') always returns scalar > $cgi->arrayparam('foo') always returns a list > > 2) > > $cgi->scalarparam('foo') always returns scalar > $cgi->arrayparam('foo) always returns array > $cgi->param('foo') throws an error to stop you using it and make you > make a specific decision > > (Let's not bikeshed on the function names before we've chosen an approach.) > > I strongly think the best way to avoid future security holes is to make > the pattern which leads to them impossible. I know we now have a test to > detect the particular pattern which caused these bugs, but I'm not > willing to bet any money that there aren't other places or ways or > contexts this could happen. So I think we should switch the Bugzilla > codebase over to one of these two patterns, using the fact that we > control the CGI object (Bugzilla/CGI.pm) to alter the behaviour of the > functions. > > I know LpSolit has expressed reservations, and that dveditz (Mozilla > security guy) is in favour. Comments? > > 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: > > _______________________________________________ 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 Tue Oct 7 19:27:22 2014 From: damien.nozay at gmail.com (Damien) Date: Tue, 7 Oct 2014 12:27:22 -0700 Subject: How do Bugzilla installs use git? In-Reply-To: References: Message-ID: comments inline On Tue, Oct 7, 2014 at 6:37 AM, Gervase Markham wrote: > > > 2) Update to a new point release (e.g. a security release), merging in > changes they've made > If you release patches (actual .patch files), you can prepare those with git-format-patch. Then store them online somewhere. People can apply them with git-am in bulk or individually with git-apply. https://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html https://www.kernel.org/pub/software/scm/git/docs/git-apply.html https://www.kernel.org/pub/software/scm/git/docs/git-am.html If people are familiar with git, they can do merge / rebase operations. > > 3) Update to a later version, merging in changes they've made > > It would be good if 2) and 3) had a dry-run option. > git has a reflog, so unless you run destructive operations like git-prune or git-gc, this is your safety net. https://www.kernel.org/pub/software/scm/git/docs/git-reflog.html > > What git commands do we use for these things? > > Here's my guesses: > > 1) > git clone https://git.mozilla.org/bugzilla/bugzilla > cd > git checkout > > Open questions: > a) Will this lead them to have an intermediate version, say if the > branch name is "4.4", 4.4.2 is stable and we are in the middle of > putting together 4.4.3? Do we need a "4.4-stable" branch and equivalents > that people can check out? Or do we do the assembly on a branch and > merge back in only at the end? > > 2) > git pull > NO! NO! NO! git pull is dangerous. git-pull does a git-fetch followed by git-merge. please instruct people to use git-fetch instead. Then ask them to explicitly choose a git-merge or git-rebase operation manually. Please have admins take the driver seat and choose either based on their requirements. https://www.kernel.org/pub/software/scm/git/docs/git-fetch.html https://www.kernel.org/pub/software/scm/git/docs/git-pull.html https://www.kernel.org/pub/software/scm/git/docs/git-merge.html https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html most operations have an --abort. e.g. overwhelming merge conflicts while doing rebase? => git rebase --abort. if you messed up so bad you can't cancel, you still have the reflog. https://www.kernel.org/pub/software/scm/git/docs/git-reflog.html > Open questions: > b) Do we need git pull instead, or is this OK? > no pull please. > > 3) > git pull > git checkout > > For reference, our list of current branches and tags is here: > http://git.mozilla.org/?p=bugzilla/bugzilla.git > > Is this all correct? > > 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: > > _______________________________________________ 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 Oct 8 10:08:30 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 08 Oct 2014 11:08:30 +0100 Subject: How do Bugzilla installs use git? In-Reply-To: References:

Message-ID: On 07/10/14 20:27, Damien wrote: > If you release patches (actual .patch files), you can prepare those with > git-format-patch. We may have to do this, but I would much prefer it if it were not the standard way of upgrading. I'm sure there's a safe git workflow to use. > If people are familiar with git, they can do merge / rebase operations. People may not be all that familiar with git. That's part of the issue. >> 3) Update to a later version, merging in changes they've made >> >> It would be good if 2) and 3) had a dry-run option. > > git has a reflog, so unless you run destructive operations like git-prune > or git-gc, this is your safety net. > > https://www.kernel.org/pub/software/scm/git/docs/git-reflog.html That doesn't sound as easy to use as a --dry-run option... >> 2) >> git pull >> > > NO! NO! NO! git pull is dangerous. git-pull does a git-fetch followed by > git-merge. > > please instruct people to use git-fetch instead. > Then ask them to explicitly choose a git-merge or git-rebase operation > manually. And what do we recommend to people who have no idea of the difference? git pull is surely OK if the user has made no code customizations? > most operations have an --abort. > e.g. overwhelming merge conflicts while doing rebase? => git rebase --abort. That basically restores things to how they were before you started? That sounds good. 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 Oct 9 08:59:49 2014 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 09 Oct 2014 09:59:49 +0100 Subject: Action items from last Bugzilla meeting Message-ID: <_dKdnSQwwuoY06vJnZ2dnUU7-bmdnZ2d@mozilla.org> Given that I, at least, have a tendency to forget my action items until just before the _next_ meeting, I thought it was worth reposting them here: Action items: * everyone: review a bit of the new docs * mcote: write API status doc (could perhaps base it on http://bugzilla-new-docs.readthedocs.org/en/latest/integrating/apis.html) * justdave: look into moving bzr off MoCo infra * someone: handle moving bugzilla.org emails * anyone: schedule a triage party * mcote: post to dev list about looking for an admin for landfill-ng Full minutes: https://wiki.mozilla.org/Bugzilla:Meetings:2014-09-24 Gerv _______________________________________________ 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 Wed Oct 15 20:52:02 2014 From: dylan at mozilla.com (Dylan Hardison) Date: Wed, 15 Oct 2014 13:52:02 -0700 (PDT) Subject: Change the param() interfac? In-Reply-To: References: Message-ID: <1204298938.32972378.1413406322752.JavaMail.zimbra@mozilla.com> There is Perl::Critic, although it may not have caught the param() in list context problem, it may be able to catch other problems. I've had some discussion with LpSolits about this, and I've re-opened Bug 555438[1] to craft a perl-critic configuration that meets the needs of the project. With regards to the specific problem $cgi->param(), there are many solutions we could follow. One typical solution is Hash::MultiValue[2], which was written specifically because of the param() in list-context fault. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=555438 [2] https://metacpan.org/pod/Hash::MultiValue (also available via ActiveState ppm) ----- Original Message ----- From: "Damien" To: developers at bugzilla.org Cc: dev-apps-bugzilla at lists.mozilla.org Sent: Tuesday, October 7, 2014 1:08:29 PM Subject: Re: Change the param() interfac? Hi folks, isn't there some kind of perl lint tool to tell you these kinds of constructs are bogus & dangerous? On Tue, Oct 7, 2014 at 1:06 AM, Gervase Markham wrote: > Hi everyone, > > As you know, we have just done a security release. The bug is written up > here: > > http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-perl-web-applications/ > > I have been pointed at this article from 5 years ago: > > > http://bulknews.typepad.com/blog/2009/12/perl-why-parameters-sucks-and-what-we-can-do.html > > which agrees that the param() interface is not awesome, although it > doesn't cover the security concerns we now know it raises. It seems that > many frameworks don't like this way of doing things, and have come up > with alternatives which are less of a footgun. The article documents > several alternatives, of which I think the leading two are: > > 1) > > $cgi->param('foo') always returns scalar > $cgi->arrayparam('foo') always returns a list > > 2) > > $cgi->scalarparam('foo') always returns scalar > $cgi->arrayparam('foo) always returns array > $cgi->param('foo') throws an error to stop you using it and make you > make a specific decision > > (Let's not bikeshed on the function names before we've chosen an approach.) > > I strongly think the best way to avoid future security holes is to make > the pattern which leads to them impossible. I know we now have a test to > detect the particular pattern which caused these bugs, but I'm not > willing to bet any money that there aren't other places or ways or > contexts this could happen. So I think we should switch the Bugzilla > codebase over to one of these two patterns, using the fact that we > control the CGI object (Bugzilla/CGI.pm) to alter the behaviour of the > functions. > > I know LpSolit has expressed reservations, and that dveditz (Mozilla > security guy) is in favour. Comments? > > 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: > > _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla - To view or change your list settings, click here: From gerv at mozilla.org Thu Oct 16 08:37:29 2014 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 16 Oct 2014 09:37:29 +0100 Subject: Reviewing the new docs Message-ID: Hi everyone, A gentle reminder: I've put upwards of 30 hours of work into the new docs; it would be awesome if you could each take an hour to review one or more sections so all of that work does not go to waste: https://etherpad.mozilla.org/bugzilla-docs-review Thanks :-) 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 Oct 16 08:41:55 2014 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 16 Oct 2014 09:41:55 +0100 Subject: Change the param() interfac? In-Reply-To: References:

Message-ID: On 15/10/14 21:52, Dylan Hardison wrote: > One typical solution is Hash::MultiValue[2], which was written > specifically because of the param() in list-context fault. > > https://metacpan.org/pod/Hash::MultiValue (also available via > ActiveState ppm) How would using Hash::MultiValue be different from changing Bugzilla::CGI in either of the two ways I proposed? It seems very similar, but with the disadvantage of depending on another Perl module. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From shimono at bug-ja.org Fri Oct 17 01:38:13 2014 From: shimono at bug-ja.org (Atsushi Shimono) Date: Fri, 17 Oct 2014 10:38:13 +0900 Subject: [ANN] Release of Bugzilla 4.5.6, 4.4.6, 4.2.11, and 4.0.15 In-Reply-To: <5432D591.7020303@mozilla.com> References: <5432D591.7020303@mozilla.com> Message-ID: <54407305.4030802@bug-ja.org> Hi, Sorry for late, but I've released -ja version for 4.0.15,4.2.11,4.4.6 several days ago. I'll be on trip for two weeks from next Sun (1st week at Princeton, and 2nd at Pasadena), so be offline for next meeting... # localizer at bugzilla gone?? On 2014/10/07 2:46, David Lawrence wrote: > Today we are releasing 4.4.6, 4.2.11, 4.0.15, and the unstable > development snapshot 4.5.6. All releases fix several security issues > found since the last release. > > Bugzilla 4.4.6 is our latest stable release. Bugzilla 4.4.6, > 4.2.11 and 4.0.15 are security updates for the 4.4, 4.2, and the > 4.0 branches, respectively. > > Note that 4.5.6 is an unstable development release and should not > be used in production environments. We are not yet feature-frozen at > this time so the features you see in 4.5.5 might not accurately > represent the behavior that 5.0 will have. > > Note that when Bugzilla 5.0 is released (likely later this year), > the Bugzilla 4.0.x series will reach end of life. If you are using that > series, we encourage you to upgrade to 4.4.6 now. > > > Download > -------- > Bugzilla is available at: > > http://www.bugzilla.org/download/ > > > Release Notes & Changes > ----------------------- > Before installing or upgrading, you should read the Release Notes for > the new version of Bugzilla: > > 4.4.6: http://www.bugzilla.org/releases/4.4.6/release-notes.html > 4.2.11: http://www.bugzilla.org/releases/4.2.11/release-notes.html > 4.0.15: http://www.bugzilla.org/releases/4.0.15/release-notes.html > > To see a list of all changes between your version of Bugzilla and > the current version of Bugzilla, you can use the chart at: > > http://www.bugzilla.org/status/changes.html > > > The Bugzilla Update > ------------------- > You can see the latest updates from the Bugzilla Project and > the status of Bugzilla development on The Bugzilla Update: > > http://bugzillaupdate.wordpress.com/ > > Also, you can follow the Bugzilla Project on Twitter for frequent > updates on new features being developed in Bugzilla, our current > release plans, and much more: > > http://twitter.com/#!/bugzilla > > > Report Bugs > ----------- > If you find a bug in Bugzilla, please report it! Instructions are > at this URL: > > http://www.bugzilla.org/developers/reporting_bugs.html > > > Support > ------- > You can ask questions for free on the mailing lists (or in IRC) > about Bugzilla, or you can hire a paid consultant to help you out: > > Free Support: http://www.bugzilla.org/support/ > Paid Support: http://www.bugzilla.org/support/consulting.html > > > About Bugzilla > -------------- > Bugzilla is a "Defect Tracking System" or "Bug-Tracking System." > Defect Tracking Systems allow individuals or groups of developers > to keep track of outstanding bugs in their product effectively. > Most commercial defect-tracking software vendors charge enormous > licensing fees. Despite being "free", Bugzilla has many features > its expensive counterparts lack. Consequently, Bugzilla has quickly > become a favorite of thousands of organizations across the globe, and > is widely regarded as one of the top defect-tracking systems available. > > See http://www.bugzilla.org/about/ for more details. > > - David Lawrence > Release Manager, Bugzilla Project > _______________________________________________ > support-bugzilla mailing list > support-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/support-bugzilla > PLEASE put support-bugzilla at lists.mozilla.org in the To: field when you reply. > -- Atsushi Shimono - shimono at bug-ja.org - skype shimono_univ, twitter/FB: himorin Tel +81-5055395179, +1-6267204274 / Cell 8084946599(US), 0648407935(FR) / http://blog.himor.in/ Mozilla Evangelist; Mozilla Japanese Translation Group / Bugzilla UG in Japan HTML5-WEST.jp - Co-Founder of HTML5 Evangelism Group in west/Japan _______________________________________________ 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 Sun Oct 19 16:15:38 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Sun, 19 Oct 2014 12:15:38 -0400 Subject: Landfill cleanup Message-ID: During the last Bugzilla meeting[1] we talked about the large number of test Bugzilla installations on landfill. When landfill was originally created, there was no easy way to set up a test Bugzilla installation that several people could use in order to evaluate specific features or Bugzilla as a whole. Nowadays, there are a plethora of Internet services, many quite cheap, that provide people with a simple way to stand up a publicly accessible server; with the new quick-start instructions[2] that Gerv wrote (and which, I believe, will be incorporated into the new Bugzilla manual), setting up a public test Bugzilla installation is vastly easier than it was a decade ago. Thus we will be removing most of the Landfill Bugzilla installations aside from the official demonstrations of supported versions as seen on the Landfill index page[3]. If you object to a particular installation being deleted, please let me know. Mark [1] https://wiki.mozilla.org/Bugzilla:Meetings:2014-09-24 [2] https://etherpad.mozilla.org/bugzilla-quick-start [3] http://landfill.bugzilla.org/ _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mcote at bugzilla.org Wed Oct 22 02:36:15 2014 From: mcote at bugzilla.org (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Tue, 21 Oct 2014 22:36:15 -0400 Subject: Target Milestones, cont'd, and release-process documentation Message-ID: When finally recording the decision regarding Target Milestones from September, I discovered that our release process does not appear to have any documentation, on the wiki at least, so I added a new page[1]. Thinking more about the Target Milestone, in order to logically complete the thought from September, at our meeting in 11.5 hours I will propose that we further restrict usage of Target Milestone on Bugzilla bugs to indicate true blockers, that is, bugs that *must* be fixed before release. The idea is that there should be a very simple, accurate way to see what we're waiting on in order to release a new version (or release candidate). Thus, we should amend the decision from last month to exclude "Bugs that are being actively worked on and are anticipated to be finished before the next release", keeping only "bugs officially designated as blockers" and adding "by the Project Lead or Assistant Project Leads" for further clarity. Mark [1] https://wiki.mozilla.org/Bugzilla:Release_Process -- 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 Oct 22 10:43:21 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 22 Oct 2014 11:43:21 +0100 Subject: Target Milestones, cont'd, and release-process documentation In-Reply-To: References: Message-ID: <54478A49.1030901@mozilla.org> On 22/10/14 03:36, Mark C?t? wrote: > Thinking more about the Target Milestone, in order to logically complete > the thought from September, at our meeting in 11.5 hours I will propose > that we further restrict usage of Target Milestone on Bugzilla bugs to > indicate true blockers, that is, bugs that *must* be fixed before > release. This seems odd to me. Surely severity=blocker is the way of finding blockers? I suggest that Target Milestone should be set if the bug has an actual assignee and the assignee's personal plan means that the work will be finished before the release in question. The release manager would have the authority, when the release approaches, to push out bugs that he thinks are too high risk to land at that point. This means that if anyone looks at a list of bugs with TM=5.0, they will see a list of bugs where either someone is actively trying to fix the bug before 5.0, or the Bugzilla team have decided it's a requirement that the bug is fixed before 5.0. That seems like a useful list. > The idea is that there should be a very simple, accurate way > to see what we're waiting on in order to release a new version (or > release candidate). I agree with this sentiment, but I think the search should be: target_milestone=Bugzilla5.0&severity=blocker rather than target_milestone=Bugzilla5.0 Gerv From lpsolit at gmail.com Wed Oct 22 11:46:26 2014 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 22 Oct 2014 13:46:26 +0200 Subject: Target Milestones, cont'd, and release-process documentation In-Reply-To: <54478A49.1030901@mozilla.org> References: <54478A49.1030901@mozilla.org> Message-ID: <54479912.3050601@gmail.com> Le 22. 10. 14 12:43, Gervase Markham a ?crit : > This seems odd to me. Surely severity=blocker is the way of finding > blockers? Errr.... so you will no longer use the blocking4.x flags? IMO, setting severity=blocker for new features doesn't make sense. To me, severity=blocker means that Bugzilla is severely broken due to that bug. It shouldn't represent bugs which you simply want for the next releases. The only exceptions are release tracking bugs. LpSolit From gerv at mozilla.org Wed Oct 22 12:22:35 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 22 Oct 2014 13:22:35 +0100 Subject: Target Milestones, cont'd, and release-process documentation In-Reply-To: <54479912.3050601@gmail.com> References: <54478A49.1030901@mozilla.org> <54479912.3050601@gmail.com> Message-ID: <5447A18B.3020901@mozilla.org> On 22/10/14 12:46, Fr?d?ric Buclin wrote: > Le 22. 10. 14 12:43, Gervase Markham a ?crit : >> This seems odd to me. Surely severity=blocker is the way of finding >> blockers? > > Errr.... so you will no longer use the blocking4.x flags? > > IMO, setting severity=blocker for new features doesn't make sense. Well, making new features blockers for time-based releases doesn't make sense either :-) But my point is not so much about blocking; it is: Target Milestone should indicate all bugs which are targetted at a particular release. A bug is considered "targetted" at a release for one of two reasons: either, the Bugzilla team will not release unless that bug is fixed, or alternatively a particular developer has expressed intent that they personally are going to fix the bug in time. If someone goes to a bug and wonders "when will this be fixed by?", they should be able to look at the TM field and either see a release number, or "---"/"Future"/whatever, and understand the best estimate for its being fixed. Gerv From lpsolit at gmail.com Wed Oct 22 12:44:37 2014 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 22 Oct 2014 14:44:37 +0200 Subject: Target Milestones, cont'd, and release-process documentation In-Reply-To: <5447A18B.3020901@mozilla.org> References: <54478A49.1030901@mozilla.org> <54479912.3050601@gmail.com> <5447A18B.3020901@mozilla.org> Message-ID: <5447A6B5.6030808@gmail.com> Le 22. 10. 14 14:22, Gervase Markham a ?crit : > Well, making new features blockers for time-based releases doesn't make > sense either :-) Haha, good point. I fully agree with you. :) > But my point is not so much about blocking; it is: Target Milestone > should indicate all bugs which are targetted at a particular release. A > bug is considered "targetted" at a release for one of two reasons: > either, the Bugzilla team will not release unless that bug is fixed, or > alternatively a particular developer has expressed intent that they > personally are going to fix the bug in time. I agree here too. This would also help everyone understand if such or such bug will be backported or not. For instance, if a bug is targetted 4.4, you know it will be backported. If it's targetted 5.0, you know it won't. This would also save the assignee some time: no need to work on a backport if the bug fix is not going to be accepted on stable branches. LpSolit From mcote at mozilla.com Wed Oct 22 13:18:39 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Wed, 22 Oct 2014 09:18:39 -0400 Subject: Target Milestones, cont'd, and release-process documentation In-Reply-To: References: <54478A49.1030901@mozilla.org> Message-ID: <6_Cdnds5d5YzM9rJnZ2dnUU7-X0AAAAA@mozilla.org> On 2014-10-22 7:46 AM, Fr?d?ric Buclin wrote: > Le 22. 10. 14 12:43, Gervase Markham a ?crit : >> This seems odd to me. Surely severity=blocker is the way of finding >> blockers? > > Errr.... so you will no longer use the blocking4.x flags? I fully admit to not even knowing about those flags; we don't seem to use them very often. I'm not sure how useful they are nowadays since we only want to block releases for actual blocker bugs. As I stated in my other post, using severity=blocker seems adequate. 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 Wed Oct 22 13:16:28 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Wed, 22 Oct 2014 09:16:28 -0400 Subject: Target Milestones, cont'd, and release-process documentation In-Reply-To: References: <54478A49.1030901@mozilla.org> <54479912.3050601@gmail.com> <5447A18B.3020901@mozilla.org> Message-ID: <6_Cdndg5d5a3M9rJnZ2dnUU7-X2dnZ2d@mozilla.org> On 2014-10-22 8:44 AM, Fr?d?ric Buclin wrote: > Le 22. 10. 14 14:22, Gervase Markham a ?crit : >> Well, making new features blockers for time-based releases doesn't make >> sense either :-) > > Haha, good point. I fully agree with you. :) As I clarified on the Release Process page, I agree that we should not block releases on new features. I foolishly let myself be talked into delaying 5.0 for the "almost done" markdown, and I regret that now. :) >> But my point is not so much about blocking; it is: Target Milestone >> should indicate all bugs which are targetted at a particular release. A >> bug is considered "targetted" at a release for one of two reasons: >> either, the Bugzilla team will not release unless that bug is fixed, or >> alternatively a particular developer has expressed intent that they >> personally are going to fix the bug in time. > > I agree here too. This would also help everyone understand if such or > such bug will be backported or not. For instance, if a bug is targetted > 4.4, you know it will be backported. If it's targetted 5.0, you know it > won't. This would also save the assignee some time: no need to work on a > backport if the bug fix is not going to be accepted on stable branches. That's fine. I have no problems using severity=blocker for bugs which actually block release. I'll update the 5.0 blockers right now. Mark _______________________________________________ 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 Oct 22 13:27:02 2014 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 22 Oct 2014 15:27:02 +0200 Subject: Target Milestones, cont'd, and release-process documentation In-Reply-To: <6_Cdnds5d5YzM9rJnZ2dnUU7-X0AAAAA@mozilla.org> References: <54478A49.1030901@mozilla.org> <6_Cdnds5d5YzM9rJnZ2dnUU7-X0AAAAA@mozilla.org> Message-ID: <5447B0A6.3010806@gmail.com> Le 22. 10. 14 15:18, Mark C?t? a ?crit : > I fully admit to not even knowing about those flags; we don't seem to > use them very often. I'm not sure how useful they are nowadays since we > only want to block releases for actual blocker bugs. As I stated in my > other post, using severity=blocker seems adequate. We used those flags for years (we were already using them in 2004 when I joined the project). It would make more sense for you to learn about them than breaking well established tracking rules (and making some existing saved searches useless). We use them when there is a point to use them. We don't mark everything as blockers just for fun. If you want a very recent example of using such flags, look at https://bugzilla.mozilla.org/show_bug.cgi?id=1075578 LpSolit From dkl at mozilla.com Wed Oct 22 13:29:23 2014 From: dkl at mozilla.com (David Lawrence) Date: Wed, 22 Oct 2014 09:29:23 -0400 Subject: Target Milestones, cont'd, and release-process documentation In-Reply-To: <6_Cdnds5d5YzM9rJnZ2dnUU7-X0AAAAA@mozilla.org> References: <54478A49.1030901@mozilla.org> <6_Cdnds5d5YzM9rJnZ2dnUU7-X0AAAAA@mozilla.org> Message-ID: <5447B133.90102@mozilla.com> The blocker flags are used mainly for minor point releases such as blocker4.4.6? The target milestone will be set to the lowest major release series we will be releasing for. So if we have a security fix for 4.0, 4.2, 4.4, and devel the target milestone would be set to 4.0 and the blocker flags would be blocker4.0.x?, blocker4.2.x? and blocker4.4.x respectively. dkl On 10/22/2014 09:18 AM, Mark C?t? wrote: > On 2014-10-22 7:46 AM, Fr?d?ric Buclin wrote: >> Le 22. 10. 14 12:43, Gervase Markham a ?crit : >>> This seems odd to me. Surely severity=blocker is the way of finding >>> blockers? >> >> Errr.... so you will no longer use the blocking4.x flags? > > I fully admit to not even knowing about those flags; we don't seem to > use them very often. I'm not sure how useful they are nowadays since we > only want to block releases for actual blocker bugs. As I stated in my > other post, using severity=blocker seems adequate. > > Mark > > > _______________________________________________ > 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 lpsolit at gmail.com Wed Oct 22 13:31:04 2014 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 22 Oct 2014 15:31:04 +0200 Subject: Target Milestones, cont'd, and release-process documentation In-Reply-To: <5447B133.90102@mozilla.com> References: <54478A49.1030901@mozilla.org> <6_Cdnds5d5YzM9rJnZ2dnUU7-X0AAAAA@mozilla.org> <5447B133.90102@mozilla.com> Message-ID: <5447B198.2000100@gmail.com> Le 22. 10. 14 15:29, David Lawrence a ?crit : > The blocker flags are used mainly for minor point releases We also used them for major releases once we branched. For instance, we created the blocking4.4 flag once the 4.4 branch was created. LpSolit From dkl at mozilla.com Wed Oct 22 13:51:43 2014 From: dkl at mozilla.com (David Lawrence) Date: Wed, 22 Oct 2014 09:51:43 -0400 Subject: 5.0 Branch Message-ID: <5447B66F.2080903@mozilla.com> Greetings, This morning I have created the new 5.0 branch in Git so that we can start the process of releasing our next major release. It has been a long time in coming and seems even closer now :) For a list of actual blocker bugs still needing to be committed: https://bugzilla.mozilla.org/buglist.cgi?&resolution=---&target_milestone=Bugzilla%205.0 If you see any that need patches or testing, feel free to jump in and give a hand. Also before the first RC, we are planning to fix the remaining test case in Travis CI that was disabled recently. The checksetup.pl upgrade test. We will be working on that in the next few days. Once that test refactoring is complete and the 5.0 code is passing, we will create the first RC. NOTE: Make sure any issues found in the 5.0 code that are fixed and committed happen in both the 5.0 branch and master. Thanks! Dkl -- David Lawrence dkl at mozilla.com From dylan at mozilla.com Wed Oct 22 14:03:09 2014 From: dylan at mozilla.com (Dylan Hardison) Date: Wed, 22 Oct 2014 07:03:09 -0700 (PDT) Subject: Using a REPL with Bugzilla In-Reply-To: <2133310871.34997413.1413985788456.JavaMail.zimbra@mozilla.com> Message-ID: <914730769.35012430.1413986589677.JavaMail.zimbra@mozilla.com> Not entirely sure if this is topical, but I figure some other people might find this useful. As an alternative to contrib/console.pl, I use Reply[1] which has persistence of lexical variables, tab completion for methods and such, and other nice bits. I've copied a few of the utility functions from console.pl to a config file, which also loads main Bugzilla module & extensions[2]. A good REPL can be really useful at times. [1] https://metacpan.org/release/Reply [2] https://gist.github.com/dylanwh/50499dfd0361ceccb6d0 From gerv at mozilla.org Wed Oct 22 14:49:00 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 22 Oct 2014 15:49:00 +0100 Subject: Using a REPL with Bugzilla In-Reply-To: References: Message-ID: On 22/10/14 15:03, Dylan Hardison wrote: > Not entirely sure if this is topical, but I figure some other people might find this useful. > > As an alternative to contrib/console.pl, How long has that been there? I had no idea... > I use Reply[1] which has persistence of lexical variables, tab completion for methods and Why not throw this stuff into contrib/ as well, with instructions on how to fire it up? Gerv _______________________________________________ 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 Thu Oct 23 17:15:42 2014 From: dylan at mozilla.com (Dylan Hardison) Date: Thu, 23 Oct 2014 10:15:42 -0700 (PDT) Subject: Using a REPL with Bugzilla In-Reply-To: References:

Message-ID: <66341822.35547384.1414084542923.JavaMail.zimbra@mozilla.com> > From: "Gervase Markham" > Sent: Wednesday, October 22, 2014 10:49:00 AM >> As an alternative to contrib/console.pl, > How long has that been there? I had no idea... >> I use Reply[1] which has persistence of lexical variables, tab completion for methods and > Why not throw this stuff into contrib/ as well, with instructions on how > to fire it up? Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1088156 Yeesh, I've really got to reconfigure thunderbird. Zimbra defaults to top-posting.... From gerv at mozilla.org Fri Oct 24 16:16:01 2014 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 24 Oct 2014 17:16:01 +0100 Subject: Extension names: lower case or camel case? Message-ID: We have repos for a number of extensions in git.mozilla.org: http://git.mozilla.org/ Some are lower case: bugzilla/extensions/cannedcomments.git And some are CamelCase: bugzilla/extensions/Browse.git Can we please pick one style and stick to it going forward? If so, which? Separate to that, is there any way of fixing them to be all consistent? (Ideally we'd have done it when we switched SCMs but we didn't.) 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 Fri Oct 24 16:37:20 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Fri, 24 Oct 2014 12:37:20 -0400 Subject: Extension names: lower case or camel case? In-Reply-To: References: Message-ID: On 2014-10-24 12:16 PM, Gervase Markham wrote: > We have repos for a number of extensions in git.mozilla.org: > > http://git.mozilla.org/ > > Some are lower case: > > bugzilla/extensions/cannedcomments.git > > And some are CamelCase: > > bugzilla/extensions/Browse.git > > Can we please pick one style and stick to it going forward? If so, which? > > Separate to that, is there any way of fixing them to be all consistent? > (Ideally we'd have done it when we switched SCMs but we didn't.) >From an SCM perspective, it's trivial, particularly in git, where paths and objects are separate. I have no idea on the ramifications for Bugzilla itself. Mark _______________________________________________ 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 Fri Oct 24 16:56:55 2014 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 24 Oct 2014 18:56:55 +0200 Subject: Extension names: lower case or camel case? In-Reply-To: References: Message-ID: <544A84D7.3060800@gmail.com> Le 24. 10. 14 18:16, Gervase Markham a ?crit : > We have repos for a number of extensions in git.mozilla.org: > Some are lower case: > And some are CamelCase: > > Can we please pick one style and stick to it going forward? If so, which? Our extension code forces extension names to be CamelCase: http://git.mozilla.org/?p=bugzilla/bugzilla.git;a=tree;f=extensions The extensions you mention have been added by random people and are not officially supported by Bugzilla. LpSolit From gerv at mozilla.org Sat Oct 25 06:09:55 2014 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 25 Oct 2014 07:09:55 +0100 Subject: Extension names: lower case or camel case? In-Reply-To: <544A84D7.3060800@gmail.com> References: <544A84D7.3060800@gmail.com> Message-ID: <544B3EB3.8040007@mozilla.org> On 24/10/14 17:56, Fr?d?ric Buclin wrote: > Our extension code forces extension names to be CamelCase: Well, that settles it, then :-) > http://git.mozilla.org/?p=bugzilla/bugzilla.git;a=tree;f=extensions > > The extensions you mention have been added by random people and are not > officially supported by Bugzilla. I don't think we officially support any extensions that don't ship with Bugzilla itself. But what we do do is offer a place for Bugzilla developers to host them, for the convenience of the community. If we have to make this clear somewhere, we should. But I don't think we should stop hosting. Mark: are you or is anyone else able to update the existing repo names? Would it break anyone's checkout? Gerv From benmansour_rafik at yahoo.fr Sat Oct 25 21:33:07 2014 From: benmansour_rafik at yahoo.fr (Rafik Ben Mansour) Date: Sat, 25 Oct 2014 22:33:07 +0100 Subject: Tr : Selenium fail in some tests with bugzilla In-Reply-To: <1414053872.86817.YahooMailNeo@web173206.mail.ir2.yahoo.com> References: <1414053872.86817.YahooMailNeo@web173206.mail.ir2.yahoo.com> Message-ID: <1414272787.42982.YahooMailNeo@web173204.mail.ir2.yahoo.com> Hi everyone, i installed the latest version of bugzilla which is the 4.4.6 and tried to make a selenium test with the test files given by thebugzilla qa team. but the tests fail in some parts ex: - in "test_bug_edit.t" file, selenium can't find the "Master" group. - in other files, login errors, can't access bugs even they have the permissions to do so ! FYI: Idowngraded bugzilla to 4.2.10 and the same error persist! waiting for your response. _______________________________________________ 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 Oct 26 13:07:35 2014 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Sun, 26 Oct 2014 14:07:35 +0100 Subject: Tr : Selenium fail in some tests with bugzilla In-Reply-To: <1414272787.42982.YahooMailNeo@web173204.mail.ir2.yahoo.com> References: <1414053872.86817.YahooMailNeo@web173206.mail.ir2.yahoo.com> <1414272787.42982.YahooMailNeo@web173204.mail.ir2.yahoo.com> Message-ID: <544CF217.8080007@gmail.com> Did you follow steps listed here? https://wiki.mozilla.org/Bugzilla:QA LpSolit From gerv at mozilla.org Thu Oct 30 13:35:46 2014 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 30 Oct 2014 13:35:46 +0000 Subject: Extension names: lower case or camel case? In-Reply-To: References: <544A84D7.3060800@gmail.com> Message-ID: On 25/10/14 07:09, Gervase Markham wrote: > Mark: are you or is anyone else able to update the existing repo names? > Would it break anyone's checkout? https://bugzilla.mozilla.org/show_bug.cgi?id=1091593 filed. 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 Oct 31 11:26:37 2014 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 31 Oct 2014 11:26:37 +0000 Subject: How we use Git Message-ID: A quick quiz: Q1: What git commands would I use to obtain an exact copy of 4.4.6 from our git repo? Q2: Same question for 4.4.4. As far as I can see, the only way of doing this currently is to do: git clone http://git.mozilla.org/bugzilla/bugzilla.git cd bugzilla git log git checkout Am I wrong? If I'm not, then this isn't good. Currently, we have branches for each release, but these contain all fixes checked on on that branch, so even if you want "the latest 4.4 release", if you: git checkout -b 4.4 origin/4.4 (which is already a complex command) then you actually get 4.4.6 plus some more fixes. I believe we need metadata in our git repo such that any (recent) released version can be pulled and run bit-for-bit identical to the release tarball. I think we also need a pointer (tag?) to "latest stable release" on each branch which moves when we do a new release. Does that make sense to people? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From simon at simongreen.net Fri Oct 31 12:33:35 2014 From: simon at simongreen.net (Simon Green) Date: Fri, 31 Oct 2014 22:33:35 +1000 Subject: How we use Git In-Reply-To: References: Message-ID: <5453819F.5070703@simongreen.net> On 31/10/14 21:26, Gervase Markham wrote: > git clone http://git.mozilla.org/bugzilla/bugzilla.git > cd bugzilla > git log > > git checkout > > > Am I wrong? > > If I'm not, then this isn't good. I'm going to leave that to the people that know more than git than I do, but that does seem correct. > I believe we need metadata in our git repo such that any (recent) > released version can be pulled and run bit-for-bit identical to the > release tarball. I think we also need a pointer (tag?) to "latest stable > release" on each branch which moves when we do a new release. Does that > make sense to people? I would turn the question around. If you are using git (or bzr or csv) to get code, what is wrong with getting the latest code for the branch, rather than the latest release of the code? Things in 4.4.6+ are going to be part of 4.4.7 when that is released, and there is a documented policy on what can be backported. -- Simon Green From rsbecker at nexbridge.com Fri Oct 31 12:36:39 2014 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Fri, 31 Oct 2014 08:36:39 -0400 Subject: How we use Git In-Reply-To: References: Message-ID: <002101cff507$51a4ba40$f4ee2ec0$@nexbridge.com> Gerv, I think it might be best to have a separate branch every release, not just the minors. So you would have a branch for 4.4.6 as well as 4.4. If you end up with 4.4.6.1, that too would be a branch - although you could get away with a tag. The decision between branch and tag really comes down to the granularity of fix releases. If there will be a 4.4.6.1.1, then branching at 4.4.6.1 is needed, otherwise not. Numbered releases are arbitrary in Git, unlike in anything derived from the RSC paradigm. Even if you are going to fix 4.4.6 (on some 4_4 branch or 4_4_6) with patches to create 4.4.7, in Git, you would normally create a branch for the pre-approved fixes, check things out, modify, commit, test, and once happy, merge back into your working branch. From there, tag or branch for the release, as named - but that is really just an arbitrary identifier to Git. I hope I didn't confuse things more ;) Cheers, Randall -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: October 31, 2014 7:27 AM To: dev-apps-bugzilla at lists.mozilla.org Subject: How we use Git A quick quiz: Q1: What git commands would I use to obtain an exact copy of 4.4.6 from our git repo? Q2: Same question for 4.4.4. As far as I can see, the only way of doing this currently is to do: git clone http://git.mozilla.org/bugzilla/bugzilla.git cd bugzilla git log git checkout Am I wrong? If I'm not, then this isn't good. Currently, we have branches for each release, but these contain all fixes checked on on that branch, so even if you want "the latest 4.4 release", if you: git checkout -b 4.4 origin/4.4 (which is already a complex command) then you actually get 4.4.6 plus some more fixes. I believe we need metadata in our git repo such that any (recent) released version can be pulled and run bit-for-bit identical to the release tarball. I think we also need a pointer (tag?) to "latest stable release" on each branch which moves when we do a new release. Does that make sense to people? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla - To view or change your list settings, click here: From mcote at mozilla.com Fri Oct 31 18:29:25 2014 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Fri, 31 Oct 2014 14:29:25 -0400 Subject: How we use Git In-Reply-To: References: Message-ID: On 2014-10-31 7:26 AM, Gervase Markham wrote: > A quick quiz: > > Q1: What git commands would I use to obtain an exact copy of 4.4.6 from > our git repo? > > Q2: Same question for 4.4.4. > > As far as I can see, the only way of doing this currently is to do: > > git clone http://git.mozilla.org/bugzilla/bugzilla.git > cd bugzilla > git log > > git checkout > > > Am I wrong? Almost. You would do up to 'cd bugzilla', then git checkout bugzilla-4.4.6 'bugzilla-4.4.6' is a tag on the last commit included in the release. We create similar tags for all releases. Yes, you will then often get a message about a detached head. What that means is that you are no longer on the head (very latest commit) of a particular branch; you've gone back in time. That's fine, but it means you can't push anything up to git.mozilla.org without creating a new branch--which is the correct behaviour, since the detached-head message means there are commits done in that branch after this tag was made, and you don't want to change history. I would imagine you wouldn't be interested in creating new commits if you were looking to go back to 4.4.6's exact last commit anyway. Regarding Randall's message, we could branch for every release; indeed, given git's very light-weight approach to branches, there are many strategies for developing under git. However, given our relatively small change volume, I don't think it's worth the extra overhead, at the moment at least. Let me know if anything is still unclear. Btw, for anyone still confused about git, I *highly* recommend the book Pro Git, which is available for free at http://git-scm.com/book/. It's pretty much essential to understand the model behind git to do anything beyond the basics, and that book will definitely help you (I felt much more knowledgeable after just the first few chapters). Mark _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From michiel.beijen at gmail.com Fri Oct 31 22:10:58 2014 From: michiel.beijen at gmail.com (Michiel Beijen) Date: Fri, 31 Oct 2014 23:10:58 +0100 Subject: How we use Git In-Reply-To: References:

Message-ID: Hi, On Fri, Oct 31, 2014 at 7:29 PM, Mark C?t? wrote: > > On 2014-10-31 7:26 AM, Gervase Markham wrote: > > A quick quiz: > > > > Q1: What git commands would I use to obtain an exact copy of 4.4.6 from > > our git repo? > > > > Q2: Same question for 4.4.4. > Regarding Randall's message, we could branch for every release; indeed, > given git's very light-weight approach to branches, there are many > strategies for developing under git. However, given our relatively > small change volume, I don't think it's worth the extra overhead, at the > moment at least. I don't think there would be any additional benefit for having branches over tags for releases. I think tags are actually beneficial since they are *fixed* i.e. they can not change over time (as with a release, which you create at one given day and then it's out of the door, as with the 4.4.4 release) whereas the branch has the possibility of future releases: you might want to check out the branch of 4.4 to work on it to create 4.4.7 one day. And if you want to go back to 4.4.4 or 3.2.whatever then you can still check out the tag, create a branch from that point with your patch, or perform your test, and it would work. Git also has the notion of signed tags so you can cryptographically guarantee a tag is exact *this* version of the project, and the source has not been messed with. Although I think I don't know many projects that actually use this feature. Usually a sha1 of a tarbal is deemed enough. If you have a reasonably new git (1.8) you can even clone a repo at a given tag. So your question above would be answered with: git clone --branch bugzilla-4.4.6 http://git.mozilla.org/bugzilla/bugzilla BTW the answer of your initial question is also mentioned on this page: https://wiki.mozilla.org/Bugzilla:Git#Getting_A_Specific_Release -- Mike _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla