Change-Id: I08c2a50cb51e14ace5064ee3835fa862888d2569

It should be https://git.mahara.org/scripts/mahara-scripts/raw/master/mahara-langpacks/language-repos.txt

Change-Id: I89d9401eb07c8d2aa59d956560c10f0522786c67

- Chinese Traditional - zh_CN
- Indonesia - id
- Estonia - et
- Kannada - kn
- Mongola - mn
- Persian - fa
- Polish - pl
- Romanian - ro
- Serbian - sr
- Thai - th
- Turkish - tr
- Ukrainian - uk
- Hungarian - hu

Change-Id: I31d85f9525762d724e8dd426dc4a5ba08e7dd285

It needs to pass on all CLI arguments to release.php

1.7, 1.8, and 1.9

Also updating documentation...

We can still run unit tests and the minaccept, to gain information
about the patch, before we decide to exit because the uploader forgot
to write a Behat test for it.

For security reasons, it's unwise to allow running of arbitrary code
uploaded my members of the general public. This test should limit
automated test running, to code uploaded by users who have been
manually added to the "Mahara Testers" or "Mahara Reviewers" groups.
(And/or code that has a +2 code review)

The check is against the code *uploader*, not the Gerrit change *owner*,
so if a patch is rebased by a trusted user, it will trigger automatic
code execution.

Since they're both PHP now, there's no need to invoke
gerrit_query.php in a separate process.

When backporting patches the different branch info comes thru and the
first item in array is not necessarily the one we want to check so we
need to check the object with right branch information.
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

And alerting user to the problem
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

This might be useful for someone in the
future.

We were *always* getting prompted for the changes & releasenotes
three times on each release. That's because the optional lptools
arguments for change & release notes must be the 5th and 6th.
But, we couldn't provide them, because the lptools 4th optional
argument is "new milestone", and if you try to provide one that
already exists, it errors out.

So, we had to leave "new milestone" empty, and that meant we
also had to leave change & release notes empty.

Rather than getting deep into the logic of the lptools utility,
I just patched is so that it always skips the "new milestone"
argument.

... except I change it to Gerrit changeset numbers.

This reverts commit af3ec01f.

Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

When the first patch being checked is already merged.

We need to reject out before checking gerrit as we don't have a commit
id to check against
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

Change-Id: I7d3a726795e53b5183a1665faec91270a0a8f638

Add bzr launchpad-login command before communicate with Launchpad

Change-Id: I29cacebba13530dead2eb3328e882a580a8442dc