Re: [mantisbt-dev] Overhauling Mantis Codebase Options

[John R. <jr...@le...>]

Thomas Charron wrote:
>   Hello everyone,
> 
>     I've had some requests from our program managers to customize some
> of mantis to allow it to be used to track NON software related issues
> and/or action items.  In the process, I started to question why there
> are 'predefined fields' at all, and why all attributes couldn't be
> done in a simular manner as custom fields.
> 
>     If I wanted to 'rip the guts' out of some of these, I have a few questions.

My biggest reminder is that for anything you expect or hope for MantisBT to pick 
up from your efforts, above all you must be able to maintain compatibility with, 
or any upgrade path from, existing MantisBT installations.  Any database schema 
or configuration changes should be documented, along with how it will affect 
users upgrading from older versions.

>     1) Where to start?  As in, what release, or tree?

The "master" branch is always the primary feature development branch, and more 
or less represents the next/upcoming feature release.

>     2) How is development and migration of changes REALLY done amungst
> all the trees which are in source control?

All feature development is done in the "master" branch, or on public 
repos/branches on MantisForge where we can look at proposed changes and later 
merge them into master when they are done/ready/approved.  Large or disruptive 
features are greatly encouraged to be done in separate branches so that we don't 
break the current master in the mean time.

Stable branches, such as "master-1.2.x" and "master-1.1.x" are generally open 
only for fixing bugs and security vulnerabilities.  For issues that affect 
master and stable branches, it is generally ideal to develop the fix directly on 
the oldest affected stable branch, and then use `git cherry-pick` to attempt a 
direct port to newer stable branches and master, modifying the patch as 
necessary for newer codebases.

>     3) If I attempt this, is it better to do this with a mantis
> repository, or a private one?

Developers can get free, public repository hosting git.mantisforge.org, allowing 
you to keep a public "fork" of the mantisbt.git repository with any number of 
branches where you maintain your features/improvements.  Opening issues in the 
official tracker for related bugs and feature requests, along with links to the 
appropriate public branches, will allow us to more easily track the efforts and 
allow others to test your fixes/features.

>     I'd really like to do this, but I'm really hestitent to make any
> massive changes without taking into consideration how this is going to
> work in the future revisions.
> 

Cheers, and good luck. :)

-- 
John Reese
LeetCode.net