@Salman We will start implementing this fairly soon, as I mentioned on Skype. However there's no rush, so let's keep implementing/finishing issues until we're ready.
This one was a big one, and a big improvement that will make many people happy.
Everything is implemented, although some of the details differ to what the issue says.
A lot of improvement was made to the Push Bugfix minimodule that is available to help developers and improve how issues are fixed by generating automatic hot fixes, and also changes (simplification) to the Mantis bug reporting options. You can now set the bug severity in the minimodule. You can now use it from any admin username & password, you don't need a master password.
GitLab has indeed been integrated with Mantis. To do this, commits need to contain MANTIS-<issue-ID>. GitLab will link through to Mantis (which is awesome). Mantis will only link to GitLab by virtue of the posts made by the Push Bugfix minimodule, Mantis itself has no direct integration back to GitLab, but that does not matter.
I cannot disable comments on the commits as they show on GitLab. However, I think as the Mantis issue is clearly linked people will generally comment on that issue. If they comment on GitLab, no huge deal - we can just live with it, or educate the user.
People may question why we don't dump Mantis and just use GitLab. Apart from that being extra work to migrate, I think it is good that we have a more powerful customisable system that is integrated well with GitLab and the compo.sr site.
I've allowed commit messages with "Implementing" as well as "Implemented", as often a developer may have to come back to tweak changes previously made and there needs to be a way of saying that.
If you use a commit message that doesn't match the standard, it'll tell you what the standard is. It isn't annoying to deal with.
Developers do need to make sure +x is set on all the git-hooks/* files for git to enforce the commit message standard.
When it comes to the automatic changelogs for new Composr releases, it doesn't say fixed/implemented/etc, it just shows the issue titles from Mantis and links to Mantis. If multiple commits refer to any particular issue then only one changelog line will be present for them. I have also allowed commits to provide additional text, as I realise more explanation may be desired for followup commits than just linking to a tracker issue can provide. The changelogs are also fully autogenerated, no need for a 'search link' or anything.
The next patch release will have a mixture of the changelog style that launched for the last patch release (which is just linking direct to git commits), and the behaviour described in the previous paragraph. This is due to it existing over the transition period. In the further future changelogs will only link to git commits if it cannot match it against a Mantis issue, which should not happen.
I haven't implemented version maintenance policy declaration via an XML file, as the potential of having different versions of that file across different branches would be chaos. Instead I've made a block that can scan all git branches that have a version-branch naming convention, identifying the maintenance status of that branch. This works by an extension to what already was in version.php. i.e. the version.php file of any git branch defines whether that branch is still being maintained, and what kind of branch it is (alpha, beta, etc). The tradeoff is we need to maintain API compatibility on version.php, but I think that'll be fine, or workaroundable at least.
Rather than a dev-mode check to ensure the web server is running as the owner of the Composr files, I've just put that check in the Push Bugfix module. It doesn't need to be everywhere.
I would note that it is good that we finally got Git policy into our coding standards document. Somehow this fell through the cracks. Most of that document was done when we still used Subversion.
Rewriting the security policy was important, and something we should have done ages ago. Frankly, we haven't been properly following everything it said as it was seriously outdated for the modern world and context of the project. I've done this unilaterally, but of course people can review what I've wrote and chip in -- it's at the bottom of https://compo.sr/docs/tut-software-feedback.htm
Automated response: Many small issues in push_bugfix script
This fixes many small issues in the push_bugfix script: - No git add for new files - Problems in filesystem search - Needs control of whether to post hotfixes - Needs control of whether to close issues - Better git command debugging (HTML comment for git output)
Everything is implemented, although some of the details differ to what the issue says.
A lot of improvement was made to the Push Bugfix minimodule that is available to help developers and improve how issues are fixed by generating automatic hot fixes, and also changes (simplification) to the Mantis bug reporting options. You can now set the bug severity in the minimodule. You can now use it from any admin username & password, you don't need a master password.
GitLab has indeed been integrated with Mantis. To do this, commits need to contain MANTIS-<issue-ID>. GitLab will link through to Mantis (which is awesome). Mantis will only link to GitLab by virtue of the posts made by the Push Bugfix minimodule, Mantis itself has no direct integration back to GitLab, but that does not matter.
I cannot disable comments on the commits as they show on GitLab. However, I think as the Mantis issue is clearly linked people will generally comment on that issue. If they comment on GitLab, no huge deal - we can just live with it, or educate the user.
People may question why we don't dump Mantis and just use GitLab. Apart from that being extra work to migrate, I think it is good that we have a more powerful customisable system that is integrated well with GitLab and the compo.sr site.
I've allowed commit messages with "Implementing" as well as "Implemented", as often a developer may have to come back to tweak changes previously made and there needs to be a way of saying that.
If you use a commit message that doesn't match the standard, it'll tell you what the standard is. It isn't annoying to deal with.
Developers do need to make sure +x is set on all the git-hooks/* files for git to enforce the commit message standard.
When it comes to the automatic changelogs for new Composr releases, it doesn't say fixed/implemented/etc, it just shows the issue titles from Mantis and links to Mantis. If multiple commits refer to any particular issue then only one changelog line will be present for them. I have also allowed commits to provide additional text, as I realise more explanation may be desired for followup commits than just linking to a tracker issue can provide. The changelogs are also fully autogenerated, no need for a 'search link' or anything.
The next patch release will have a mixture of the changelog style that launched for the last patch release (which is just linking direct to git commits), and the behaviour described in the previous paragraph. This is due to it existing over the transition period. In the further future changelogs will only link to git commits if it cannot match it against a Mantis issue, which should not happen.
I haven't implemented version maintenance policy declaration via an XML file, as the potential of having different versions of that file across different branches would be chaos. Instead I've made a block that can scan all git branches that have a version-branch naming convention, identifying the maintenance status of that branch. This works by an extension to what already was in version.php. i.e. the version.php file of any git branch defines whether that branch is still being maintained, and what kind of branch it is (alpha, beta, etc). The tradeoff is we need to maintain API compatibility on version.php, but I think that'll be fine, or workaroundable at least.
Rather than a dev-mode check to ensure the web server is running as the owner of the Composr files, I've just put that check in the Push Bugfix module. It doesn't need to be everywhere.
I would note that it is good that we finally got Git policy into our coding standards document. Somehow this fell through the cracks. Most of that document was done when we still used Subversion.
Rewriting the security policy was important, and something we should have done ages ago. Frankly, we haven't been properly following everything it said as it was seriously outdated for the modern world and context of the project. I've done this unilaterally, but of course people can review what I've wrote and chip in -- it's at the bottom of https://compo.sr/docs/tut-software-feedback.htm
This fixes many small issues in the push_bugfix script:
- No git add for new files
- Problems in filesystem search
- Needs control of whether to post hotfixes
- Needs control of whether to close issues
- Better git command debugging (HTML comment for git output)