From: Thomas C. <tw...@gm...> - 2009-10-19 19:15:43
|
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. 1) Where to start? As in, what release, or tree? 2) How is development and migration of changes REALLY done amungst all the trees which are in source control? 3) If I attempt this, is it better to do this with a mantis repository, or a private one? 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. -- -- Thomas |
From: John R. <jr...@le...> - 2009-10-19 19:36:33
|
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 |
From: Ryan O'L. <ro...@gm...> - 2009-10-19 19:46:23
|
Thomas, Check out the issue submitted here: http://www.mantisbt.org/bugs/view.php?id=5744 This request has been out for a long time. Patches have been submitted, the issue has been assigned to a Mantis developer, but no action has been taken on the main codebase. I really don't understand the process here. This feature request was made. An independent developer (myself) submitted a patch that implemented the feature. I participated in discussion online with Mantis developers and took their comments into account. Per the Mantis folks' request, a Wiki page was created with full documentation. The patch was updated as requested by the developers... and it was NEVER implemented in Mantis. What does it take? - ryan On Mon, Oct 19, 2009 at 12:36 PM, John Reese <jr...@le...> wrote: > 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 > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Thomas C. <tw...@gm...> - 2009-10-19 20:37:06
|
On Mon, Oct 19, 2009 at 3:46 PM, Ryan O'Leary <ro...@gm...> wrote: > Thomas, > Check out the issue submitted here: > http://www.mantisbt.org/bugs/view.php?id=5744 > This request has been out for a long time. Patches have been submitted, the > issue has been assigned to a Mantis developer, but no action has been taken > on the main codebase. > I really don't understand the process here. This feature request was made. > An independent developer (myself) submitted a patch that implemented the > feature. I participated in discussion online with Mantis developers and took > their comments into account. Per the Mantis folks' request, a Wiki page was > created with full documentation. The patch was updated as requested by the > developers... and it was NEVER implemented in Mantis. What does it take? And THAT is at the core of my intent in asking questions. Even worse, my fear is that it DOES end up in mantis in a completely different manner. -- -- Thomas |
From: John R. <jr...@le...> - 2009-10-19 21:05:17
|
Ryan O'Leary wrote: > Thomas, > > Check out the issue submitted here: > http://www.mantisbt.org/bugs/view.php?id=5744 > > This request has been out for a long time. Patches have been submitted, > the issue has been assigned to a Mantis developer, but no action has > been taken on the main codebase. > > I really don't understand the process here. This feature request was > made. An independent developer (myself) submitted a patch that > implemented the feature. I participated in discussion online with Mantis > developers and took their comments into account. Per the Mantis folks' > request, a Wiki page was created with full documentation. The patch was > updated as requested by the developers... and it was NEVER implemented > in Mantis. What does it take? All I can say is that we have very few core developers, each with a limited amount of spare time in which to work on Mantis. Sometimes things get lost through the cracks, and it takes persistence to get it on a developer's plate when he actually has time to sit down and deal with it. Other times, it takes effort to get it onto the radar of the dev team in general, or at least on the radar of a *different* team member who may either be more interested in the topic, or have more free time. In the case of your issue, it dates from before I was part of the time, so I personally did not even know that this topic existed, let alone know that there were entire discussions and feature submissions. On one hand, I suspect Paul for taking assignment of the issue if he wasn't planning to handle it to cempletion; on the other hand, I think that the sheer volume of bug and feature requests is overwhelming for the limited amount of man hours available to the project. -- John Reese LeetCode.net |
From: Glenn H. <thr...@lo...> - 2009-10-19 21:14:41
|
On 2009-10-19, at 3:46 PM, Ryan O'Leary wrote: > Thomas, > > Check out the issue submitted here: > http://www.mantisbt.org/bugs/view.php?id=5744 > > This request has been out for a long time. Patches have been > submitted, the issue has been assigned to a Mantis developer, but no > action has been taken on the main codebase. > > I really don't understand the process here. This feature request was > made. An independent developer (myself) submitted a patch that > implemented the feature. I participated in discussion online with > Mantis developers and took their comments into account. Per the > Mantis folks' request, a Wiki page was created with full > documentation. The patch was updated as requested by the > developers... and it was NEVER implemented in Mantis. What does it > take? > > - ryan > I'll let Paul apologize for this, if necessary. Taking a user patch is often not as simple as it sounds. A core developer may try to combine it with other patches in the same area, or find even more regressions once the patch is merged. The patch itself may not apply is the underlying base has changed (as most patches older that a few months won't apply since we changed the line spacing and cleaned up code formatting). I, personally, have taken an evening to integrate a 10 line patch for the reasons above. We switched to git as a repository to help with this, but every patch requires time and effort from a developer. All of us have other jobs and priorities, so some things slip through the cracks. I think that the message is "bear with us". Keep submitting / updating the patches. ... Glenn -- Glenn Henshaw Logical Outcome Ltd. e: thr...@lo... w: www.logicaloutcome.ca Mantis Developer and User since 2002 |
From: Robert M. <rob...@gm...> - 2009-10-19 21:23:44
|
On Tue, Oct 20, 2009 at 12:14 AM, Glenn Henshaw <thr...@lo...> wrote: > > Taking a user patch is often not as simple as it sounds. A core developer > may try to combine it with other patches in the same area, or find even more > regressions once the patch is merged. The patch itself may not apply is the > underlying base has changed (as most patches older that a few months won't > apply since we changed the line spacing and cleaned up code formatting). I, > personally, have taken an evening to integrate a 10 line patch for the > reasons above. I couldn't agree more with this. It's tough to take in a patch, and taking in 10 is daunting. Perhaps we can take a leaf out of Git's book and maintain an pu ( aka proposed updates ) branch which is a testing area for new patches. Hm... perhaps unstable is a better name, but all in all getting these patches in git would be a huge step forward. It's clear to me that a patch attached to a bug report gets maybe 1-2 extra testers, but an unstable branch would ideally get all contributors submitting patches. Please note that as of now, there are 55 ack'ed issues with patches, and 36 on new/feedback. WDYT? Robert -- Sent from my (old) computer |
From: Glenn H. <thr...@lo...> - 2009-10-20 00:21:57
|
On 2009-10-19, at 3:15 PM, 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. I think that the primary reason is performance. Custom fields use a large number of joins for searches. From the last time I did any performance measurements, this was a real bottleneck. On the flip side, I have been thinking about this for many of the non-critical fields, but haven't been able to put benchmargs together yet to gauge the performance hit. I'd be more than willing to discuss this and maybe help. ... Glenn -- Glenn Henshaw Logical Outcome Ltd. e: thr...@lo... w: www.logicaloutcome.ca Mantis Developer and User since 2002 |
From: David H. <hic...@op...> - 2009-10-20 00:38:35
|
On Mon, 2009-10-19 at 15:43 -0400, Glenn Henshaw wrote: > I think that the primary reason is performance. Custom fields use a > large number of joins for searches. From the last time I did any > performance measurements, this was a real bottleneck. We can still keep core fields within the same "bug" table... just have saveToDatabase() and readFromDatabase() abstract functions in the Field object. For built-in fields, those functions can be set to read from the "bug" table instead of the custom fields table (or whatever else). I guess the real problem is when you want to read a bug object from the database. We don't want to execute a single SQL query for each field within a bug. Which seems to indicate to me that the Bug object should be responsible for writing fields to the database? Regards, David |
From: David H. <hic...@op...> - 2009-10-20 00:22:42
|
Hi Thomas, Thanks for your interest in Mantis. I was planning to do exactly what you described around January/February next year when I have some time. But please be aware... it's a *HUGE* task that has to cover everything from plugins to SOAP API. I'd be very happy to see someone do this rewrite instead of me... or help out when the time comes. You've made the correct first step - emailing the developer mailing list. So I'll provide some tips/thoughts: * Use git for all development work * Commit early and often * Commit in logical chunks * Ensure that the main development branch works at every commit (don't break stuff in-between commits) * Push branch(es) to git.mantisforge.org to get feedback as you go * Define the proposed OO classes/API and submit it to this ML before writing any code * Develop a new "Field" object (see the "Bug" object Paul implemented earlier this year for an example) * Implement a bunch of new subclasses of Field for different data types such as String, Text, Integer, Float, Date, Enum, User, Version, Project, Status, etc * Extend those classes again to implement the default Mantis fields (to ensure backwards compatibility)... such as reproducibility, target version, etc * Documentation must be written for the new API and the existing documentation updated (see the /docbook folder in the repository) * Make *heavy* use of grep when replacing the existing custom fields functionality in Mantis (and replacing built-in fields)... this ensures you don't miss anything * Ensure that users have a flawless and automatic upgrade path from existing versions to the new version So basically the idea I had was that an OO API is developed in parallel with the existing functionality. Then once the API is complete, we can go through the main codebase field by field and replace them with the new Field API implementation. All along, Mantis is in a working (hopefully) bug free state. Once all the built in fields and custom API code are ported across to the new system, we can then remove the old custom_fields_api, etc. Let me know what you think. Regards, David On Mon, 2009-10-19 at 15:15 -0400, 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. > > 1) Where to start? As in, what release, or tree? > 2) How is development and migration of changes REALLY done amungst > all the trees which are in source control? > 3) If I attempt this, is it better to do this with a mantis > repository, or a private one? > > 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. > |