mantisbt-dev — MantisBT development discussions

Re: [mantisbt-dev] MantisBT Logo

[Robert M. <rob...@gm...>]

On Wed, Oct 1, 2014 at 8:09 PM, P Richards <pa...@ma...> wrote:
> Victor: could you send a copy of the logo in Vector Format to the mailing
> list, as per the original intention ?


Or rather please check it in the git repository.

Robert

-- 
http://robert.muntea.nu/

Re: [mantisbt-dev] Build System

[Roland B. <ro...@at...>]

> Damien Regad <dr...@ma...> hat am 1. Oktober 2014 um 15:00
> geschrieben:
>

> I've been totally swamped by your recent series of pull requests (and a few
> other things) and have not had the time to even start looking at this just
> yet.
>

Same for me.

My MantisBT time will be very limited at least until mid of december :-(

[mantisbt-dev] MantisBT Logo

[P R. <pa...@ma...>]

When we originally changed the logo for Mantis in 2012, my understanding was
that we would be putting a copy of the logo in VECTOR format for people to
use in the source repository.

 

Following damien's comment @
https://github.com/mantisbt/mantisbt/pull/328#issuecomment-57475687 , I'm
concerned whether as a team we now own and have royalty-free access to our
current logo.

 

As an open source project that can be developed by different people and
other time the team has and I'm sure will continue to change, we should
ensure that our logo is in the public domain.

 

When we originally discussed the logo before @
http://www.mantisbt.org/bugs/view.php?id=7994 - we had a number of offers
from users to design for free a logo in the public domain and to give it to
us in vector format.

 

So given damien's comment back to me, and roland's request back in February
2012 below about having the logo available so we can freely modify it.

 

I have a simple question:

 

Is the current logo a free logo that can be made available in Vector format?
If not, I suggest we reopen issue 7994 and look into designing a logo that
is completely free for our use.

 

I work in a school and have some students and work colleagues that would
happily design a logo in vector format that would be royalty free and in the
public domain for our use if for some reason the existing logo cannot be
made available. In an ideal world, I'd hope that it is the case that the
logo we picked in 2012 was indeed a publicly available logo that was free
for our use for any purposes. At least, indeed this was what I was led to
believe when Victor originally emailed about the new logo and stated: "In
the issue you will find the old proposals, the new proposals, the guidelines
that I wrote about what we want," referring to the guidelines that stated:

 

"- The logo should be available in image and vector formats (e.g. PNG, Adobe
Photoshop and Adobe Illustrator)"

 

Victor: could you send a copy of the logo in Vector Format to the mailing
list, as per the original intention ?

 

Thanks

Paul

 

 

From: Roland Becker [mailto:ro...@at...] 
Sent: 09 February 2012 09:32
To: developer discussions
Subject: Re: [mantisbt-dev] Misleading descriptions of MantisBT forks at
github

 

> 1. Logo in Vector Format - I'll have the logo in Adobe Illustrator format
as well as PNG format.

Please also SVG , so we could use open source solutions like Inkscape to
modify whatever we want.
At least it will show us whether Illustrator SVG export and Inkscape's PNG
rendering will produce the same result.
If the Inkscape output is different (I don't expect a 100% bit identical
output), but what you can see is ok, we should use this one.

Re: [mantisbt-dev] Build System

[Damien R. <dr...@ma...>]

Paul Richards <grangeway@...> writes:
> I was just wondering whether anyone had had any problems with executing 
> the code in the new build system from the instructions issued previously, 
> or whether so far, it seems to work on people’s systems?

I've been totally swamped by your recent series of pull requests (and a few
other things) and have not had the time to even start looking at this just yet.

Re: [mantisbt-dev] Build System

[Paul R. <gra...@bl...>]

Hi All,

 

I was just wondering whether anyone had had any problems with executing the
code in the new build system from the instructions issued previously, or
whether so far, it seems to work on people's systems?

 

Paul

 

From: P Richards [mailto:pa...@ma...] 
Sent: 21 September 2014 23:20
To: 'developer discussions'
Subject: [mantisbt-dev] Build System

 

Hi All,

 

I'd like to draw people's attention to
https://github.com/mantisbt/mantisbt/pull/332 - as it's start of work to
implement a common build system that both travis and mantis developers can
use. As we add unit tests allowing mantis developers to easily create a
build locally and also show up code style issues should hopefully lead to
less churn in the source code (and make supporting different releases of
mantis easier). 

 

I think the summary I put on the github PR hopefully covers most things so
far, so going to just paste it here rather than writing another wall of
text:

 

For a long while now, the build a developer can do,
and the build one can automate on travis-ci are too different things.

This is the start of a process to unify the build system, such that a
developer can run a local build before/without having to wait for
travis-ci or some other automation system to kick in.

The requirements for this to run at the moment is an installation of
either phing or composer.

Phing route:

Phing can be installed, if not already installed by running:

pear channel-discover pear.phing.info
pear install [--alldeps] phing/phing

going to the Mantis directory, and running phing then starts a build.

This build will download composer, download a standard version of
phpcodesniffer/phpunit, and it's own copy of phing and run a build based
on these versions. This ensures that local + travis etc versions are the
same

Composer Route:

php -r "readfile(' <https://getcomposer.org/installer');>
https://getcomposer.org/installer');" | php
composer install

A build can be run at this point by calling:

php vendor/bin/phing build

Note: at the moment, I've specified 'build' as a target here, as the
default option is to run a target called "buildsystem" at the moment,
which downloads all the dependencies

travis-ci.org build has been modified to include the process described
above so that a developers build and the build system build converge
towards being identical.

At the moment a 'build' consists of the following:

a) doing a quick lint check on PHP files for parse errors
b) Running some popular code metrics type utilities: phploc,pdepend
c) running phpcs with a custom ruleset which tries to follow mantis's rules
d) running phpunit tests
e) generating some api documentation
(atm, via phpdox, although should also generated via phpdoc2)
f) spit our a zip/tarball package of the build

Full build time is with codesniffer rules etc is around 2.5-3 minutes
locally

however, individual steps can be run:

For example:

phing phpcs will run codesniffer rules against code base.

phing phpunit will run php unit tests.

This is very much a first step - I suspect we will alter the tools,
add tools and commands etc, as we work out whats useful and what isn't.

For example, I've seen some phing build scripts that deal with creating
and merging between local branches/github PR's etc.

 

 

[mantisbt-dev] FW: [mantisbt-commits] [mantisbt/mantisbt]

[P R. <pa...@ma...>]

As we've been working through merging patches, and to prepare us for working on future versions, I've removed the next/master-2.0.x branches - which should provide less confusion to end users.

To ensure that history can be looked up, before doing this, there's a copy of the branches @ https://github.com/mantisbtarchive/mantisbt

Paul


-----Original Message-----
From: GitHub [mailto:no...@gi...] 
Sent: 30 September 2014 21:04
To: man...@li...
Subject: [mantisbt-commits] [mantisbt/mantisbt]

  Branch: refs/heads/master-2.0.x
  Home:   https://github.com/mantisbt/mantisbt

[mantisbt-dev] FW: [mantisbt-commits] [mantisbt/mantisbt]

[P R. <pa...@ma...>]

As we've been working through merging patches, and to prepare us for working on future versions, I've removed the next/master-2.0.x branches - which should provide less confusion to end users.

To ensure that history can be looked up, before doing this, there's a copy of the branches @ https://github.com/mantisbtarchive/mantisbt

Paul

-----Original Message-----
From: GitHub [mailto:no...@gi...] 
Sent: 30 September 2014 21:04
To: man...@li...
Subject: [mantisbt-commits] [mantisbt/mantisbt]

  Branch: refs/heads/next
  Home:   https://github.com/mantisbt/mantisbt

Re: [mantisbt-dev] No updates from translatewiki

[Damien R. <dr...@ma...>]

Roland Becker <roland@...> writes:
> Is there a problem with translatewiki and/or siebrand?

Did you try e-mailing him directly or catching him on IRC or Skype ? He does
not usually respond to notifications from the tracker. Also note that he
changed e-mail address sometime last year (the xs4all.nl one is not
used/valid anymore)

Re: [mantisbt-dev] No updates from translatewiki

[P R. <pa...@ma...>]

Just so you don't worry, I asked on IRC - He's still around -
https://gerrit.wikimedia.org/r/#/c/163187/ - code reviews today


-----Original Message-----
From: Roland Becker [mailto:ro...@at...] 
Sent: 29 September 2014 21:13
To: man...@li...
Subject: [mantisbt-dev] No updates from translatewiki

Is there a problem with translatewiki and/or siebrand?

No feedback since 5 Seo
https://www.mantisbt.org/bugs/view.php?id=17628#c41176
Last activity on 26 Aug
https://github.com/siebrand?tab=activity
Last commit for mantisBT on 6 Aug
https://github.com/mantisbt/mantisbt/commit/97605c542e0c6df631b0880c6052fb13
510e2cee

----------------------------------------------------------------------------
--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
mantisbt-dev mailing list
man...@li...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

[mantisbt-dev] No updates from translatewiki

[Roland B. <ro...@at...>]

Is there a problem with translatewiki and/or siebrand?

No feedback since 5 Seo
https://www.mantisbt.org/bugs/view.php?id=17628#c41176
Last activity on 26 Aug
https://github.com/siebrand?tab=activity
Last commit for mantisBT on 6 Aug
https://github.com/mantisbt/mantisbt/commit/97605c542e0c6df631b0880c6052fb13510e2cee

Re: [mantisbt-dev] PHP Unit Tests

[Robert M. <rob...@gm...>]

On Mon, Sep 22, 2014 at 9:50 AM, Paul Richards <pa...@ma...> wrote:
> Thanks - that's the one I think
>
> Paul
>
> On Mon, Sep 22, 2014 at 7:47 AM, Damien Regad <dr...@ma...> wrote:
>>
>> P Richards <paul@...> writes:
>>
>> > I vaguely recall a few months ago that either Rombert or Roland had a
>> > couple of new unit tests they were planning to add on a mantis bug / PR
>> > somewhere? Is that still the case?
>>
>> https://github.com/mantisbt/mantisbt/pull/133 ?

Well, the PR is there but I don't have the time right now to look into
reworking it as discussed.

>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> mantisbt-dev mailing list
>> man...@li...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>



-- 
http://robert.muntea.nu/

Re: [mantisbt-dev] Github milestones

[Damien R. <dr...@ma...>]

Roland Becker <roland@...> writes:

> Maybe the easiest and a pragmatic way to be able to focus on 1.3 when 
> viewing again and again at open PR's.

That's the goal - something quick and easy...

> But this will generate some additional work to syncronize the milestone
> information in Github with target versions in our bug tracker where we 
> have existing issues.

I really did not intend to use this to as a replacement or even complement
of the roadmap we maintain in the tracker through the target version - just
something to remind ourselves of the outcome of a discussion

> I fear also that we will get even more PR's without related issues.

That's a risk indeed, although it is a separate discussion. I agree that
ideally we should have an issue on the tracker for every feature and bug fix.

> We might see a quite poor roadmap / change log if we work this way.
> 
> The cleaner? way would be:
> 
> - Enter issue if there is no existing one for a PR (at least after the PR got
> +1)
> - Add note with link to the PR
> - Set target version

A better approach indeed, although it generates more overhead. 

Now who can convince Paul to adhere to that ;-)

Re: [mantisbt-dev] plugin announcement

[Damien R. <dr...@ma...>]

Schmitz, Jean <J.Schmitz@...> writes:

> I don't have write access to the wiki yet, altough I am a registered 
> MantisBT user.

The wiki authenticates you using the same cookie as the bugtracker on
mantisbt.org. You need to login there, and then when you go to the wiki you
should see your name at bottom left (Logged in as: ...)

Re: [mantisbt-dev] Github milestones

[Roland B. <ro...@at...>]

Maybe the easiest and a pragmatic way to be able to focus on 1.3 when viewing
again and again at open PR's.

But this will generate some additional work to syncronize the milestone
information in Github with target versions in our bug tracker where we have
existing issues.

I fear also that we will get even more PR's without related issues.
We might see a quite poor roadmap / change log if we work this way.

The cleaner? way would be:

- Enter issue if there is no existing one for a PR (at least after the PR got
+1)
- Add note with link to the PR
- Set target version

> Damien Regad <dr...@ma...> hat am 23. September 2014 um 13:28
> geschrieben:
>
>
> In light of the recent discussion started by vboctor on the next release,
> and grangeway's intent of continuing to submit pull requests, I think it
> would be good to be able to categorize those PRs that should make it in 1.3,
> and the ones to be postponed to 2.x
>
> Therefore I propose to create Milestones in our repository.
>
> Thoughts ? Objections ?
>
> D
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

[mantisbt-dev] Scrum for MantisBT with agileMantis

[Schmitz, J. <J.S...@ga...>]

'Go Scrum' with agileMantis and MantisBT!



We are happy to tell you, that the Scrum tool 'agileMantis' from gadiv is now integrated into the official list of MantisBT plugins.

agileMantis is Open Source and freely available from Source Forge or GitHub.

Having MantisBT extended by agileMantis you can now easily perform full featured Scrum, directly setting up on your already existing data.



agileMantis implements Scrum this way:

Assign agileMantis rights to MantisBT users

Group these users into Scrum Teams and give them Scrum Roles

Create Product Backlogs and assign Teams to them

Create User Stories by assigning issues to Product Backlogs

Create Sprints and assign them to the Product Backlogs

Assign User Stories to the Sprints

Assign Tasks to the User Stories

Use agileMantis' integrated availability- and capacity manager for proper Sprint Planning

Run Sprints by maintaining the states of the Tasks and the work done with them

Use the integrated taskboard and important charts (burndown, velocity, ...) included in agileMantisExpert.



More information:

Visit the GitHub plugin page: https://github.com/mantisbt-plugins/agileMantis

Visit our web site: http://www.gadiv.de/de/opensource/agilemantis/agilemantisen.html

Visit agileMantis on Source Forge: http://sourceforge.net/projects/agilemantis/

Visit our live demo: http://agilemantis.sourceforge.net



You have questions? Write a mail to agi...@ga...<mailto:agi...@ga...>

Best regards
Jean

[mantisbt-dev] Github milestones

[Damien R. <dr...@ma...>]

In light of the recent discussion started by vboctor on the next release,
and grangeway's intent of continuing to submit pull requests, I think it
would be good to be able to categorize those PRs that should make it in 1.3,
and the ones to be postponed to 2.x

Therefore I propose to create Milestones in our repository.

Thoughts ? Objections ?

D

Re: [mantisbt-dev] plugin announcement

[Schmitz, J. <J.S...@ga...>]

Ok, thanks.

I don't have write access to the wiki yet, altough I am a registered MantisBT user.



Jean Schmitz
Managing Software Engineer 

gadiv GmbH 
Bövingen 148 
53804 Much 
Germany
Tel.:
+49 (0)2245 / 9160-34
Fax:
+49 (0)2245 / 9160-21
E-Mail:
j.s...@ga...
Web:
www.gadiv.de

Vertreten durch die Geschäftsführer:
Walter Jenauer, Axel Heuchmer, Werner Mauelshagen

Gesellschaftssitz: Much
Amtsgericht Siegburg HRB 2487
USt-ID DE123109137


-----Ursprüngliche Nachricht-----
Von: Damien Regad [mailto:dr...@ma...] 
Gesendet: Dienstag, 23. September 2014 11:05
An: Man...@li...
Betreff: Re: [mantisbt-dev] plugin announcement

Schmitz, Jean <J.Schmitz@...> writes:
> What’s the best place to put that?

I think this is it. You may want to send a message to the mantisbt-help mailing list [1] as well, as it has a wider audience.

Also, as mentioned previously, you should reference your plugin on our wiki [2].


[1] https://lists.sourceforge.net/lists/listinfo/mantisbt-help
[2] http://www.mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
mantisbt-dev mailing list
man...@li...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Re: [mantisbt-dev] Staging 1.3 for release

[Damien R. <dr...@ma...>]

Paul Richards <grangeway@...> writes:

> In any case, I'm going to be doing several pull requests a day until end 
> of October and at that point will be stopping and focusing on bug-fixing 
> and testing for a good quality 1.3 release.

For the record, your current activity and the effort required to read your
prose, respond when needed and review your code is eating up 100% of my
MantisTime (tm).

Re: [mantisbt-dev] plugin announcement

[Damien R. <dr...@ma...>]

Schmitz, Jean <J.Schmitz@...> writes:
> What’s the best place to put that?

I think this is it. You may want to send a message to the mantisbt-help
mailing list [1] as well, as it has a wider audience.

Also, as mentioned previously, you should reference your plugin on our wiki [2].


[1] https://lists.sourceforge.net/lists/listinfo/mantisbt-help
[2] http://www.mantisbt.org/wiki/doku.php/mantisbt:mantis_plugins

[mantisbt-dev] plugin announcement

[Schmitz, J. <J.S...@ga...>]

Hello,

we would like to make an announcement of our agileMantis plugin to the MantisBT community.

What's the best place to put that?

Thanks!


Jean Schmitz
Managing Software Engineer
________________________________
gadiv GmbH
Bövingen 148
53804 Much
Germany
Tel.:

+49 (0)2245 / 9160-34

Fax:

+49 (0)2245 / 9160-21

E-Mail:

j.s...@ga...<mailto:j.s...@ga...>

Web:

www.gadiv.de<http://www.gadiv.de/>


Vertreten durch die Geschäftsführer:
Walter Jenauer, Axel Heuchmer, Werner Mauelshagen

Gesellschaftssitz: Much
Amtsgericht Siegburg HRB 2487
USt-ID DE123109137
________________________________

[mantisbt-dev] agileMantis is transfered

[Schmitz, J. <J.S...@ga...>]

Hello,

the agileMantis github repository is now transfered to mantisbt-plugins/agileMantis.

Best regards.


Jean Schmitz
Managing Software Engineer
________________________________
gadiv GmbH
Bövingen 148
53804 Much
Germany
Tel.:

+49 (0)2245 / 9160-34

Fax:

+49 (0)2245 / 9160-21

E-Mail:

j.s...@ga...<mailto:j.s...@ga...>

Web:

www.gadiv.de<http://www.gadiv.de/>


Vertreten durch die Geschäftsführer:
Walter Jenauer, Axel Heuchmer, Werner Mauelshagen

Gesellschaftssitz: Much
Amtsgericht Siegburg HRB 2487
USt-ID DE123109137
________________________________

Re: [mantisbt-dev] PHP Unit Tests

[Paul R. <pa...@ma...>]

Thanks - that's the one I think

Paul

On Mon, Sep 22, 2014 at 7:47 AM, Damien Regad <dr...@ma...> wrote:

> P Richards <paul@...> writes:
>
> > I vaguely recall a few months ago that either Rombert or Roland had a
> > couple of new unit tests they were planning to add on a mantis bug / PR
> > somewhere? Is that still the case?
>
> https://github.com/mantisbt/mantisbt/pull/133 ?
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>

Re: [mantisbt-dev] PHP Unit Tests

[Damien R. <dr...@ma...>]

P Richards <paul@...> writes:

> I vaguely recall a few months ago that either Rombert or Roland had a 
> couple of new unit tests they were planning to add on a mantis bug / PR 
> somewhere? Is that still the case?

https://github.com/mantisbt/mantisbt/pull/133 ?

Re: [mantisbt-dev] Staging 1.3 for release

[Victor B. <vb...@gm...>]

I don’t think you are hearing what the team is saying… I know what are you saying, but I don’t think the team is on board with it.  I wanted to branch, the team wasn’t on board.  I decide to compromise and re-discuss after 1.3.0a1 is out.

We need to have a criteria to accept / reject these pull requests, and my feel based on the thread so far, is that if you just keep porting stuff, there will be good portion that won’t make sense to pass the pull request phase.

Reviewing these pull requests also takes time, so lets make sure that we are making good use of everyone’s time.

If we decide to accept all your pull requests, then we might as well open it for all to get in whatever they have time to get in.

I disagree with the statement about 1.3 not about to quality bar yet, and your checkins are making it better.  A lot of the changes are good changes but are not fixing issues that affect our ability to ship 1.3.  Or even fixing a bug that an end user would benefit from.

Now if I’m wrong about that, then feel free to present your case in each of the pull requests.

On Sep 21, 2014, at 3:51 PM, Paul Richards <gra...@bl...> wrote:

> Hi Victor,
> 
> Indeed - there's a number of changes from 2.0/next branches that I'm not
> pulling across at this stage. For example 'bug objects' and "MantisContext"
> work ( the 2nd at least, I think roland quite liked)
> 
> As I said to roland's reply, I'd like to see us ensure a good quality 1.3
> release. At the moment, I don't think we are ready to achieve that.
> 
> I've already said the timescale I think we should work too in terms of new
> code and fixing stuff - end of October.
> 
> In any case, I'm going to be doing several pull requests a day until end of
> October and at that point will be stopping and focusing on bug-fixing and
> testing for a good quality 1.3 release.
> 
> Hopefully by that point we'll have a new build system in place, and enhanced
> phpunit tests which should aid the testing process.
> 
> Paul
> 
> -----Original Message-----
> From: Victor Boctor [mailto:vb...@gm...] 
> Sent: 21 September 2014 23:33
> To: Paul Richards
> Cc: MantisBT Dev Mailing List
> Subject: Re: [mantisbt-dev] Staging 1.3 for release
> 
> Paul, the goal is not to pull all the changes in 2.0/next.  We avoided these
> branches to reduce the churn to enable 1.3 going out and to be able to
> review the changes.  You porting these changes fixed the latter, but not the
> churn problem.
> 
> @dregad's suggestion:
> 
> - (Paul) stop submitting 5-10 pull requests per day for now,
> - focus on testing and fixing issues and stabilization instead, then
> - get alpha out the door ASAP, and
> - resume the new features fest after 1.3.0a1 is out. 
> 
> @vboctor's suggestion:
> 
> - blocking bug fixes
> - functional bug fixes
> - security bugs
> 
> Branching to be discussed after 1.3a1 is out.
> 
> Let's focus on stablization, upgrading our tracker and getting 1.3.0a1/b1
> out.
> 
> I've started doing some testing on master and adding some 1.3 support to
> plugins that I authored or contributed to.
> 
> I'll also start responding to pull requests based on the above criteria
> since at least 3 of us seem to be on board with it.
> 
> On Sep 19, 2014, at 2:04 PM, P Richards <pa...@ma...> wrote:
> 
>> Roland,
>> 
>> I think the initial with the 1.2 and historical fixes was that we didn't
> have plan post 1.2.
>> 
>> In terms of 1.3, I'd like to see us support this longer term, so I think
> it would be good to see us bug port more bug fixes.
>> 
>> I've not had much time so far in September to spend on Mantis Development,
> as I work in a school and the first few weeks are really busy. 
>> 
>> Now that the first few weeks are done, I should be able to dedicate more
> time towards mantis. At the moment, I'm going through existing patches that
> people offered to help get committed from next/master-2.x before we look at
> 1.3.
>> 
>> You'll probably see the pace of that development accelerate over the next
> month as I'll have some free time to work on Mantis, coupled with some free
> work time to throw in.
>> 
>> Hopefully we can get as much merged as possible to reduce both the work in
> keeping the patches sync'd up to the current master, and to avoid having
> what we've had before of doing a release and then having massive churn on
> master.
>> 
>> I will have pull requests for every patch against master-2 / next in
> github within the next 7-10 days.
>> 
>> This will allow us to delete the historical next/master-2.x branches.
>> 
>> I've then got 2-3 new features that I'd like to put forward in October,
> and plan to spend some time trying to stabilise master for a release at that
> point.
>> 
>> I suggested two weeks ago that we set a date of end of October for new
> development - when I said " to branch 1.3 for release" - I meant for an
> alpha release, and not for a final release.
>> 
>> In terms of 'when to branch' - we should branch master into 1.3 before the
> first alpha release. But equally, that should be done at the point
> everyone's had a chance to get any changes in before the branch. Whilst I
> know that I've not had much time to dedicate to Mantis for the last month,
> and I know I'm about to get a chunk of time to spend on mantis for the next
> month, others may have different schedules. The rational for saying we
> should set an "end of October" or even "end of November" date or similar
> timescale was to give everyone a chance to finalise any patches before we
> move to a period of stabilisation. 
>> 
>> Paul
>> 
>> 
>> -----Original Message-----
>> From: Roland Becker [mailto:ro...@at...]
>> Sent: 19 September 2014 10:51
>> To: developer discussions; Victor Boctor
>> Subject: Re: [mantisbt-dev] Staging 1.3 for release
>> 
>> Victor,
>> 
>> I mentioned some time before that I would like to see the branch _after_
> 1.3.0 or even better 1.3.1 This is to avoid the additional work that is
> needed to implement fixes for two branches.
>> It seems that you don't consider this approach.
>> 
>> Ok, at least we shouldn't branch before the fixes for let's say the second
> official beta version are implemented and at least the following issues [1]
> are fixed.
>> 
>> I fear that we will see quite soon some commits from Victor and Paul in
> master after the branch has been created that will complicate porting
> changes from 1.3 to 2.0.
>> I fear also, that Victor and Paul will not invest that much time in fixing
> bugs in 1.3 and port them to 2.0.
>> 
>> From my 1.2.x experience:
>> Some developers had certainly some pleasure to add new stuff to master 
>> / next /
>> 2.0 whereas other developers had not that much pleasure to fix hundreds of
> bugs in 1.2.x and to port the fixes to master.
>> To get a rough impression of what I mean, check "Assigned To" from [2]
>> 
>> dregad 264
>> rombert 102
>> atrol 45
>> vboctor 31 (even less if you don't count the issues driven by 
>> MantisTouch) grangeway 5
>> 
>> I hope we will not see the same story for 1.3.
>> 
>> Concerning "Upgrade our bug tracker to 1.3 branch":
>> 
>> Did someone test that all plugins running on mantisbt.org/bugs are running
> fine with current master?
>> Maybe some of them can/should be deactivated.
>> At least "Source control integration" and "Snippets" should work.
>> 
>> Roland
>> 
>> [1]
>> http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off
>> &sortby=last_updated&dir=DESC&hide_status_id=-2&match_type=0
>> [2]
>> http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off
>> &fixed_in_version[]=1.2.x&fixed_in_version[]=1.2.17&fixed_in_version[]
>> =1.2.16&fixed_in_version[]=1.2.15&fixed_in_version[]=1.2.14&fixed_in_v
>> ersion[]=1.2.13&fixed_in_version[]=1.2.12&fixed_in_version[]=1.2.11&fi
>> xed_in_version[]=1.2.10&fixed_in_version[]=1.2.9&fixed_in_version[]=1.
>> 2.8&fixed_in_version[]=1.2.7&fixed_in_version[]=1.2.6&fixed_in_version
>> []=1.2.5&fixed_in_version[]=1.2.4&fixed_in_version[]=1.2.3&fixed_in_ve
>> rsion[]=1.2.2&fixed_in_version[]=1.2.1&sortby=handler_id&dir=DESC&hide
>> _status_id=-2&match_type=0
>> 
>> 
>>> Victor Boctor <vb...@gm...> hat am 19. September 2014 um 05:39
>>> geschrieben:
>>> 
>>> 
>>> Hi all,
>>> 
>>> It has become a habit to discuss this topic every couple of month.  
>>> I'm seeing there is a lot of activity in terms of checkins, but I 
>>> want us to make sure we are on a path to getting 1.3 out of the door.  
>>> We have always been a month or two away with desire to get some more
> stuff in.
>>> 
>>> At the moment, there is a lot of churn on master that can be 
>>> classified as good change, but not really needed for 1.3 to go out.
>>> 
>>> I would like to suggest staging 1.3 as follows:
>>> 
>>> - Branch for 1.3
>>> - Upgrade our bug tracker to 1.3 branch.
>>> - Put this branch in bug fix only mode.
>>> 
>>> That would give us the following benefits:
>>> 
>>> - A better chance at stabilizing (based on blocking bugs) and releasing.
>>> - Ability to release 1.3 beta/alpha and get more testing.
>>> - Continue doing back porting of good changes, but are not critical 
>>> to
>>> 1.3 release without destabilizing.
>>> - Unblock 2.0 changes
>>> 
>>> Hope that makes sense.
>>> 
>>> Thanks,
>>> -Victor
>>> ---------------------------------------------------------------------
>>> -
>>> -------- Slashdot TV.  Video for Nerds.  Stuff that Matters.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.
>>> clktrk_______________________________________________
>>> mantisbt-dev mailing list
>>> man...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>> 
>> ----------------------------------------------------------------------
>> -------- Slashdot TV.  Video for Nerds.  Stuff that Matters.
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.
>> clktrk _______________________________________________
>> mantisbt-dev mailing list
>> man...@li...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>> 
> 
> 
> ----------------------------------------------------------------------------
> --
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Re: [mantisbt-dev] Staging 1.3 for release

[Paul R. <gra...@bl...>]

Hi Victor,

Indeed - there's a number of changes from 2.0/next branches that I'm not
pulling across at this stage. For example 'bug objects' and "MantisContext"
work ( the 2nd at least, I think roland quite liked)

As I said to roland's reply, I'd like to see us ensure a good quality 1.3
release. At the moment, I don't think we are ready to achieve that.

I've already said the timescale I think we should work too in terms of new
code and fixing stuff - end of October.

In any case, I'm going to be doing several pull requests a day until end of
October and at that point will be stopping and focusing on bug-fixing and
testing for a good quality 1.3 release.

Hopefully by that point we'll have a new build system in place, and enhanced
phpunit tests which should aid the testing process.

Paul

-----Original Message-----
From: Victor Boctor [mailto:vb...@gm...] 
Sent: 21 September 2014 23:33
To: Paul Richards
Cc: MantisBT Dev Mailing List
Subject: Re: [mantisbt-dev] Staging 1.3 for release

Paul, the goal is not to pull all the changes in 2.0/next.  We avoided these
branches to reduce the churn to enable 1.3 going out and to be able to
review the changes.  You porting these changes fixed the latter, but not the
churn problem.

@dregad's suggestion:

- (Paul) stop submitting 5-10 pull requests per day for now,
- focus on testing and fixing issues and stabilization instead, then
- get alpha out the door ASAP, and
- resume the new features fest after 1.3.0a1 is out. 

@vboctor's suggestion:

- blocking bug fixes
- functional bug fixes
- security bugs

Branching to be discussed after 1.3a1 is out.

Let's focus on stablization, upgrading our tracker and getting 1.3.0a1/b1
out.

I've started doing some testing on master and adding some 1.3 support to
plugins that I authored or contributed to.

I'll also start responding to pull requests based on the above criteria
since at least 3 of us seem to be on board with it.

On Sep 19, 2014, at 2:04 PM, P Richards <pa...@ma...> wrote:

> Roland,
> 
> I think the initial with the 1.2 and historical fixes was that we didn't
have plan post 1.2.
> 
> In terms of 1.3, I'd like to see us support this longer term, so I think
it would be good to see us bug port more bug fixes.
> 
> I've not had much time so far in September to spend on Mantis Development,
as I work in a school and the first few weeks are really busy. 
> 
> Now that the first few weeks are done, I should be able to dedicate more
time towards mantis. At the moment, I'm going through existing patches that
people offered to help get committed from next/master-2.x before we look at
1.3.
> 
> You'll probably see the pace of that development accelerate over the next
month as I'll have some free time to work on Mantis, coupled with some free
work time to throw in.
> 
> Hopefully we can get as much merged as possible to reduce both the work in
keeping the patches sync'd up to the current master, and to avoid having
what we've had before of doing a release and then having massive churn on
master.
> 
> I will have pull requests for every patch against master-2 / next in
github within the next 7-10 days.
> 
> This will allow us to delete the historical next/master-2.x branches.
> 
> I've then got 2-3 new features that I'd like to put forward in October,
and plan to spend some time trying to stabilise master for a release at that
point.
> 
> I suggested two weeks ago that we set a date of end of October for new
development - when I said " to branch 1.3 for release" - I meant for an
alpha release, and not for a final release.
> 
> In terms of 'when to branch' - we should branch master into 1.3 before the
first alpha release. But equally, that should be done at the point
everyone's had a chance to get any changes in before the branch. Whilst I
know that I've not had much time to dedicate to Mantis for the last month,
and I know I'm about to get a chunk of time to spend on mantis for the next
month, others may have different schedules. The rational for saying we
should set an "end of October" or even "end of November" date or similar
timescale was to give everyone a chance to finalise any patches before we
move to a period of stabilisation. 
> 
> Paul
> 
> 
> -----Original Message-----
> From: Roland Becker [mailto:ro...@at...]
> Sent: 19 September 2014 10:51
> To: developer discussions; Victor Boctor
> Subject: Re: [mantisbt-dev] Staging 1.3 for release
> 
> Victor,
> 
> I mentioned some time before that I would like to see the branch _after_
1.3.0 or even better 1.3.1 This is to avoid the additional work that is
needed to implement fixes for two branches.
> It seems that you don't consider this approach.
> 
> Ok, at least we shouldn't branch before the fixes for let's say the second
official beta version are implemented and at least the following issues [1]
are fixed.
> 
> I fear that we will see quite soon some commits from Victor and Paul in
master after the branch has been created that will complicate porting
changes from 1.3 to 2.0.
> I fear also, that Victor and Paul will not invest that much time in fixing
bugs in 1.3 and port them to 2.0.
> 
> From my 1.2.x experience:
> Some developers had certainly some pleasure to add new stuff to master 
> / next /
> 2.0 whereas other developers had not that much pleasure to fix hundreds of
bugs in 1.2.x and to port the fixes to master.
> To get a rough impression of what I mean, check "Assigned To" from [2]
> 
> dregad 264
> rombert 102
> atrol 45
> vboctor 31 (even less if you don't count the issues driven by 
> MantisTouch) grangeway 5
> 
> I hope we will not see the same story for 1.3.
> 
> Concerning "Upgrade our bug tracker to 1.3 branch":
> 
> Did someone test that all plugins running on mantisbt.org/bugs are running
fine with current master?
> Maybe some of them can/should be deactivated.
> At least "Source control integration" and "Snippets" should work.
> 
> Roland
> 
> [1]
> http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off
> &sortby=last_updated&dir=DESC&hide_status_id=-2&match_type=0
> [2]
> http://www.mantisbt.org/bugs/search.php?project_id=1&sticky_issues=off
> &fixed_in_version[]=1.2.x&fixed_in_version[]=1.2.17&fixed_in_version[]
> =1.2.16&fixed_in_version[]=1.2.15&fixed_in_version[]=1.2.14&fixed_in_v
> ersion[]=1.2.13&fixed_in_version[]=1.2.12&fixed_in_version[]=1.2.11&fi
> xed_in_version[]=1.2.10&fixed_in_version[]=1.2.9&fixed_in_version[]=1.
> 2.8&fixed_in_version[]=1.2.7&fixed_in_version[]=1.2.6&fixed_in_version
> []=1.2.5&fixed_in_version[]=1.2.4&fixed_in_version[]=1.2.3&fixed_in_ve
> rsion[]=1.2.2&fixed_in_version[]=1.2.1&sortby=handler_id&dir=DESC&hide
> _status_id=-2&match_type=0
> 
> 
>> Victor Boctor <vb...@gm...> hat am 19. September 2014 um 05:39
>> geschrieben:
>> 
>> 
>> Hi all,
>> 
>> It has become a habit to discuss this topic every couple of month.  
>> I'm seeing there is a lot of activity in terms of checkins, but I 
>> want us to make sure we are on a path to getting 1.3 out of the door.  
>> We have always been a month or two away with desire to get some more
stuff in.
>> 
>> At the moment, there is a lot of churn on master that can be 
>> classified as good change, but not really needed for 1.3 to go out.
>> 
>> I would like to suggest staging 1.3 as follows:
>> 
>> - Branch for 1.3
>> - Upgrade our bug tracker to 1.3 branch.
>> - Put this branch in bug fix only mode.
>> 
>> That would give us the following benefits:
>> 
>> - A better chance at stabilizing (based on blocking bugs) and releasing.
>> - Ability to release 1.3 beta/alpha and get more testing.
>> - Continue doing back porting of good changes, but are not critical 
>> to
>> 1.3 release without destabilizing.
>> - Unblock 2.0 changes
>> 
>> Hope that makes sense.
>> 
>> Thanks,
>> -Victor
>> ---------------------------------------------------------------------
>> -
>> -------- Slashdot TV.  Video for Nerds.  Stuff that Matters.
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.
>> clktrk_______________________________________________
>> mantisbt-dev mailing list
>> man...@li...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> 
> ----------------------------------------------------------------------
> -------- Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.
> clktrk _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> 


----------------------------------------------------------------------------
--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
mantisbt-dev mailing list
man...@li...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev