On Mon, Nov 5, 2012 at 7:52 AM, Victor Boctor <victor@...> wrote:
> Here is what I'm getting from Paul's summary, please correct me if my
> understanding is incorrect:
> 1. recommendation is to retire "next" is retired in favor of master-2.x
> 2. master-2.x will need some work to be ready with objects, exception
> handling, localization, and new gen web services.
> 3. master-2.x will support current soap api as legacy for backward
> 4. master-2.x will break backward compatibility for plugins.
> 5. master (or what is designated as v1.3) may be skipped, assuming
> master-2.x is ready in the near future.
Thanks for the tl;dr :-)
> What I'm missing is:
> 1. What is in master-1.2.x that is missing in master? My assumption there
> will be few commits in this category that we can figure out easily.
> 2. What is in master-1.2.x and master that is not in mantis-2.x? I expect a
> lot since development was out of sync, unless someone was actively doing
> these merges. Some may be irrelevant to the new implementation, but I
> expect a lot to be.
> 3. What is in master and not in master-1.2.x? What is the main value add so
> far of master (v1.3)?
This is the big question. AFAIK we have
- some bugfixes targeted only for 1.3.x ( unsure why )
- XHTML strict output ( unsure what the value is here )
- security hardening
- minor refactorings/configuration enhancements
On top of this we would get much cleaner internals with Paul's
master-2.x branch which put us in the position of delivering extra
> 4. What is the current status of master-2.x? The estimate is 2 months for
> completion, but what is working? what is the progress?
> 5. How long do we expect for master-2.x to be stable for release?
> For master-2.x to be our next major version, I would suggest the following:
> 1. Get it to a complete / stable state.
> 2. No take backs compared to 1.2.x as far as users are concerned.
> 3. Make sure all features / fixes in master-1.2.x made it to master-2.x
> 4. Backward compatibility with SOAP.
> 5. Port most popular plugins to be 2.x.
> 6. If we haven't started working on a new feature or refactoring, let's not
> do it. For example let's not worry about REST or new web service
> implementation until we release master 2.0. We can always add this later.
> If we are not on track by end of the year, we may want to consider v1.3 off
> master-1.2.x or master to do the following until master-2.x is ready and
> 1. Unlock features that require a schema change.
> 2. Bundle jQuery to enable mantis and its plugins to re-use it.
+1 No reason to keep requiring the jQuery plugin.
> 3. Drop nusoap and require php soap client.
> 4. Unlock bigger features that may be too big to include in a 1.2.x release.
> On Sun, Nov 4, 2012 at 7:40 AM, Paul Richards <paul@...> wrote:
>> At the moment - next to 2.x.
>> After the 1.2 release, the ideas getting throwing around for example were
>> to rewrite the web services layer e.g. to support soap/xmlrpc etc, to look
>> at objects/exceptions and replace adodb.
>> I know some of those ideas/plans probably pre-date some of the people that
>> have recently worked on things.
>> Personally, I was under the impression that we probably wouldn't release a
>> 1.3 but skip to the 'next' idea, hence I've not put any development effort
>> into their branch. I know dhx/others have kept a rough eye on the branch I
>> was keeping, and I know i've got several lists of what's been done in
>> master/1.2.x/next that need merging.
>> I can't recall why Dhx hasn't been around as much recently - I know in the
>> case of John Reese he's stated that he won't be working on php projects
>> anymore (http://noswap.com/blog/me-php-and-mantisbt/), and we've picked up
>> yourself as an active developer + rombert on the soap api and atrol on the
>> From my point of view, I'm going to work on the branch in master-2.x for
>> another 2 months until December to get it into a state it could be put
>> forward as something we could start to organise a release around (as the
>> current 1.2.x code is not suitable for use on Microsoft SQL Server which I
>> use at work, and the concluded fix for that was to lose adodb), with the
>> fixes in the current master. It was around April 2011 that we first started
>> looking at "next" and I don't there has been any major development on the
>> master branch by myself (or dhx) since.
>> This basically means spending a week getting dhx's locale changes redone
>> (which is ~half way through), setting up an automated build of the phpdoc
>> stuff + demo instance (as it now builds without errors) so would be nice to
>> keep it that way, and then spending 6 weeks tidying up the
>> objects/exceptions/db layer. This would then put us in a position where we
>> can have a proper look at whether the changes would be an improvement on the
>> 1.x version or not.
>> And to come back to dregad's original mail:
>> "At some point I even thought he was going to fork (i.e. the mantisbt2 org
>> on github)" -> the reason for creating this at the time was as the DB layer
>> changes, it would require plugin's to be updated, which whilst trivial I
>> thought could make more sense to manage as a seperate organisation -
>> however, i'm also fairly sure someone said that wouldn't be needed due to
>> how git/github works.
>> "therefore intentionally not included some commits to master, not to
>> mention dumped the soap api entirely" -> a) there's a couple of changes in
>> master that do not make sense. For example, if you look at daryn's original
>> work to re-organise the mantis file layer - that negates about 3 commits to
>> master that deal with out we calculate paths correctly or incorrectly in
>> some cases. In terms of the 'soap api' - I consider that as temporary. The
>> current soap api 're-implements' too much of the mantis code base, only
>> supports soap and was written *before* mantis supported multiple
>> projects/configs etc - and whilst it works, and rombert has done a great job
>> of improving it - It's also fairly high up on the list of things in mantis
>> that needs to be looked at from scratch. For 3 reasons:
>> a) a number of other projects now support multiple webservice layers
>> (rest/soap/xmlrpc). There's a few projects out there, and even the zend
>> framework that allow you to organise things in such a way that you can have
>> a webservice class that can output soap/rest/xmlrpc as required depending on
>> the client. I know dhx has reservations about that sort of approach.
>> Rombert's probably in a better position to see if that sort of approach is
>> likely to work.
>> b) the webservice layer should be a loose wrap-around mantis - when i last
>> looked there were some places it had to do db queries due to how mantis
>> currently works.
>> c) some of the calls I think still need updating to support multiple
>> projects/configs - For example, mc_enum_status - I believe you can't specify
>> a user/project id.
>> Now having said all of that... i'd probably be inclined to sit down and
>> take the latest soap api and make it work with the 2.x codebase. Whilst
>> simultaneously starting the discussion on whether we should implement a new
>> web service layer that supports multiple outputs and treat the existing one
>> as supported but 'legacy'. Or whether if we want a xmlrpc webservice api, we
>> code it from scratch alongside the soap one etc etc. As a reference to the
>> 'multiple outputs' - http://docs.moodle.org/dev/Web_services_API and
>> http://code.google.com/p/php-wsdl-creator/ give two approaches.
>> 'dhxs personal repo':
>> 12:05 paul: what do we do with the next branch at end of this
>> 12:05 paul: leave in place or rename or what
>> 12:07 dhx: I'll move it into my github repo
>> On Sun, Nov 4, 2012 at 11:05 AM, <damien.regad@...> wrote:
>>> Paul Richards <paul@...> wrote on 02.11.2012 23:04:35:
>>> > I sat down with dhx last week and we compared the 2.x and next
>>> > branch - came up with a list of about 10 commits to migrated into
>>> > 2.x so we can move the next branch to dhx's personal repo.
>>> Well that's good to hear.
>>> Can you confirm what is the direction of the cherry-picking
>>> - from next into 2.x or
>>> - from 2.x into next
>>> And the mention of 'dhx's personal repo' confused me... can you clarify
>>> what you mean ?
>>> This message and any attachment are confidential and may be privileged or
>>> otherwise protected from disclosure. If you are not the intended recipient,
>>> you must not copy this message or attachment or disclose the contents to any
>>> other person. If you have received this transmission in error, please notify
>>> the sender immediately and delete the message and any attachment from your
>>> system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not
>>> accept liability for any omissions or errors in this message which may arise
>>> as a result of E-Mail-transmission or for damages resulting from any
>>> unauthorized changes of the content of this message and any attachment
>>> thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not
>>> guarantee that this message is free of viruses and does not accept liability
>>> for any damages caused by any virus transmitted therewith.
>>> Click http://www.merckgroup.com/disclaimer to access the German, French,
>>> Spanish and Portuguese versions of this disclaimer.
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> mantisbt-dev mailing list
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> mantisbt-dev mailing list
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> mantisbt-dev mailing list
Sent from my (old) computer