Discussion:
[mantisbt-dev] MantisBT 1.3 Release Status Check
Victor Boctor
2014-06-15 16:59:10 UTC
Permalink
I inspected the issues that are marked for v1.3 to see how far we are from
the release and found 7 bugs targeted for 1.3. I grouped them into what
two groups based on my opinion of blocking vs. not. It would be great for
everyone to comment on what they are working on that they feel blocks us
from putting out the 1.3 release candidate. We can follow up with further
fixes before the final releases.

Blocking and Specific to master:
--------------------------------

17437: Plugin breaks
- There are a few changes in 1.3 that breaks plugin, I think we should see
if we can fix those. i.e. keep helper_alternate_class() around just for
plugins until we do the breaking changes with the db layer. There are
cases that are technically breaking, but the chance of breaking is rare,
vs. the helper_alternate_class which I suspect will be more common for
plugins that have configuration pages. I suggest at least fixing the
latter one.

16570: Page content in 'Report Issue' is forgotten when user clicks [Back]
button in browser
- That is a really annoying bug. Paul has a fix that seems to be pending
more reviewers - https://github.com/mantisbt/mantisbt/pull/202

16878: Install triggers varchar to datetime conversion error on sql server
2008
- what's the status?

Shouldn't be blocking
---------------------

9885: Emails on relations is send to people who cannot see the related issue
- Open since 2008. Does it really need to block the release? If there is
a targetted fix, let's do it?

11399: Deprecate $g_show_realname and use $g_show_user_realname_threshold
instead
- I don't think this should block v1.3

12382: Long emails aren't sent and make Mantis freeze
- This is a corner case, is in 1.2.x and can be fixed in a dot release.
Even though it is good to fix, it is not blocking.

12144: changing to the next custom status does not work
- Nice to fix. Fix can come in at any time.

Thanks,
-Victor
P Richards
2014-06-15 17:06:56 UTC
Permalink
In terms of 17437, and plugins<>1.3.



I think we need to decide whether a plugin written for 1.2 should load in 1.3. I’m pretty sure there’s another bug out there way I was saying about making a patch to ensure that the plugins are for the targeted mantis version.



Seperately to that, whilst going through this afternoon, I had the idea whether it was possible to port the db query string format changes to 1.3 – whilst still using adodb. i.e. could we allow in 1.3 both the new + old style strings against adodb, then switch in 2.0 to new without adodb. I don’t know if that’s technically possible, but it would provide a migration.



In terms of 16878, I’d argue we should worry about that against the new db layer, as adodb in some cases makes a bad choice of columns types for mssql, and I believe other parts of the code fail to work.



16570 - This appeared to be a regression, and given it’s browser specific nature, could probably do with wider testing.



The other issues, I’d deem as not blocking.



I think there’s a couple of other blocking issues however not on this list – for instance, roland/myself can reproduce an issue with the captcha not working.





From: Victor Boctor [mailto:***@gmail.com]
Sent: 15 June 2014 17:59
To: MantisBT Dev Mailing List
Subject: [mantisbt-dev] MantisBT 1.3 Release Status Check



I inspected the issues that are marked for v1.3 to see how far we are from the release and found 7 bugs targeted for 1.3. I grouped them into what two groups based on my opinion of blocking vs. not. It would be great for everyone to comment on what they are working on that they feel blocks us from putting out the 1.3 release candidate. We can follow up with further fixes before the final releases.



Blocking and Specific to master:

--------------------------------



17437: Plugin breaks

- There are a few changes in 1.3 that breaks plugin, I think we should see if we can fix those. i.e. keep helper_alternate_class() around just for plugins until we do the breaking changes with the db layer. There are cases that are technically breaking, but the chance of breaking is rare, vs. the helper_alternate_class which I suspect will be more common for plugins that have configuration pages. I suggest at least fixing the latter one.



16570: Page content in 'Report Issue' is forgotten when user clicks [Back] button in browser

- That is a really annoying bug. Paul has a fix that seems to be pending more reviewers - https://github.com/mantisbt/mantisbt/pull/202



16878: Install triggers varchar to datetime conversion error on sql server 2008

- what's the status?



Shouldn't be blocking

---------------------



9885: Emails on relations is send to people who cannot see the related issue

- Open since 2008. Does it really need to block the release? If there is a targetted fix, let's do it?



11399: Deprecate $g_show_realname and use $g_show_user_realname_threshold instead

- I don't think this should block v1.3



12382: Long emails aren't sent and make Mantis freeze

- This is a corner case, is in 1.2.x and can be fixed in a dot release. Even though it is good to fix, it is not blocking.



12144: changing to the next custom status does not work

- Nice to fix. Fix can come in at any time.



Thanks,

-Victor
Victor Boctor
2014-06-15 17:17:06 UTC
Permalink
Roland Becker
2014-06-15 21:18:10 UTC
Permalink
> I keep forgetting the bug tracker process we agreed on for tracking 1.3
> blocking issues, but I think just having target release set as 1.3 is simple.
> Roland may correct me if I'm wrong.

At the moment there are 34 open issues with target version 1.3.x.
There is a filter "Blocking v1.3 issues" (target version = 1.3.x && status <
resolved && (severity = crash || block || major) which shows the mentioned 7
issues at the moment.
This filter should be used to get a decision if 1.3.0 final can be released or
not.
For beta/release candidate we could allow severity = major.
P Richards
2014-06-15 21:49:30 UTC
Permalink
What's our policy on version labelling atm?

Paul

-----Original Message-----
From: Roland Becker [mailto:***@atrol.de]
Sent: 15 June 2014 22:18
To: Victor Boctor; developer discussions
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check

> I keep forgetting the bug tracker process we agreed on for tracking
> 1.3 blocking issues, but I think just having target release set as 1.3 is
simple.
> Roland may correct me if I'm wrong.

At the moment there are 34 open issues with target version 1.3.x.
There is a filter "Blocking v1.3 issues" (target version = 1.3.x && status <
resolved && (severity = crash || block || major) which shows the mentioned 7
issues at the moment.
This filter should be used to get a decision if 1.3.0 final can be released
or not.
For beta/release candidate we could allow severity = major.

----------------------------------------------------------------------------
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast.
Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
Damien Regad
2014-06-16 13:34:55 UTC
Permalink
On 15.06.2014 23:49, P Richards wrote:
> What's our policy on version labelling atm?

Semantic versioning


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
unknown
1970-01-01 00:00:00 UTC
Permalink
--_c0eacdcd-f26d-4f07-8c05-e7d47e21c9bd_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

If db layer with compatibility mode is viable, then it can be considered. It depends on breaking / risk / time. In my opinion, the biggest blocker for db layer for 1.3 is:
- breaking plugin- further delays to 1.3
If both are not an issue, I would be happy to reconsider.
For the other bugs, I request the following:- If you have a pull request for the fix, let's get it in.- If the bug is not blocking and is assigned to you, remove the target version.- If you are aware of a blocking bug, then please set the target version on it.- If you are working on a blocking but, it would be great to get a time line of when the fix will be ready.- For some of the bugs we may decide it doesn't block a beta/release candidate, but it blocks final. The goal is really to get the release out there and start getting feedback about new bugs that users are hitting.
I keep forgetting the bug tracker process we agreed on for tracking 1.3 blocking issues, but I think just having target release set as 1.3 is simple. Roland may correct me if I'm wrong.From: ***@mantisforge.org
To: mantisbt-***@lists.sourceforge.net
Date: Sun, 15 Jun 2014 18:06:56 +0100
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check

In terms of 17437, and plugins<>1.3. I think we need to decide whether a plugin written for 1.2 should load in 1.3. I’m pretty sure there’s another bug out there way I was saying about making a patch to ensure that the plugins are for the targeted mantis version. Seperately to that, whilst going through this afternoon, I had the idea whether it was possible to port the db query string format changes to 1.3 – whilst still using adodb. i.e. could we allow in 1.3 both the new + old style strings against adodb, then switch in 2.0 to new without adodb. I don’t know if that’s technically possible, but it would provide a migration. In terms of 16878, I’d argue we should worry about that against the new db layer, as adodb in some cases makes a bad choice of columns types for mssql, and I believe other parts of the code fail to work. 16570 - This appeared to be a regression, and given it’s browser specific nature, could probably do with wider testing. The other issues, I’d deem as not blocking. I think there’s a couple of other blocking issues however not on this list – for instance, roland/myself can reproduce an issue with the captcha not working. From: Victor Boctor [mailto:***@gmail.com]
Sent: 15 June 2014 17:59
To: MantisBT Dev Mailing List
Subject: [mantisbt-dev] MantisBT 1.3 Release Status Check I inspected the issues that are marked for v1.3 to see how far we are from the release and found 7 bugs targeted for 1.3. I grouped them into what two groups based on my opinion of blocking vs. not. It would be great for everyone to comment on what they are working on that they feel blocks us from putting out the 1.3 release candidate. We can follow up with further fixes before the final releases. Blocking and Specific to master:-------------------------------- 17437: Plugin breaks- There are a few changes in 1.3 that breaks plugin, I think we should see if we can fix those. i.e. keep helper_alternate_class() around just for plugins until we do the breaking changes with the db layer. There are cases that are technically breaking, but the chance of breaking is rare, vs. the helper_alternate_class which I suspect will be more common for plugins that have configuration pages. I suggest at least fixing the latter one. 16570: Page content in 'Report Issue' is forgotten when user clicks [Back] button in browser- That is a really annoying bug. Paul has a fix that seems to be pending more reviewers - https://github.com/mantisbt/mantisbt/pull/202 16878: Install triggers varchar to datetime conversion error on sql server 2008- what's the status? Shouldn't be blocking--------------------- 9885: Emails on relations is send to people who cannot see the related issue- Open since 2008. Does it really need to block the release? If there is a targetted fix, let's do it? 11399: Deprecate $g_show_realname and use $g_show_user_realname_threshold instead- I don't think this should block v1.3 12382: Long emails aren't sent and make Mantis freeze- This is a corner case, is in 1.2.x and can be fixed in a dot release. Even though it is good to fix, it is not blocking. 12144: changing to the next custom status does not work- Nice to fix. Fix can come in at any time. Thanks,-Victor
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
mantisbt-dev mailing list
mantisbt-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--_c0eacdcd-f26d-4f07-8c05-e7d47e21c9bd_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>If db layer with compatibility mode is viable, then it can be considered. &nbsp;It depends on breaking / risk / time. &nbsp;In my opinion, the biggest blocker for db layer for 1.3 is:<div><br></div><div>- breaking plugin</div><div>- further delays to 1.3</div><div><br></div><div>If both are not an issue, I would be happy to reconsider.</div><div><br></div><div>For the other bugs, I request the following:</div><div>- If you have a pull request for the fix, let's get it in.</div><div>- If the bug is not blocking and is assigned to you, remove the target version.</div><div>- If you are aware of a blocking bug, then please set the target version on it.</div><div>- If you are working on a blocking but, it would be great to get a time line of when the fix will be ready.</div><div>- For some of the bugs we may decide it doesn't block a beta/release candidate, but it blocks final. &nbsp;The goal is really to get the release out there and start getting feedback about new bugs that users are hitting.</div><div><br></div><div>I keep forgetting the bug tracker process we agreed on for tracking 1.3 blocking issues, but I think just having target release set as 1.3 is simple. &nbsp;Roland may correct me if I'm wrong.</div><br /><br /><div><hr id="stopSpelling">From&#58; ***@mantisforge.org<br>To&#58; mantisbt-***@lists.sourceforge.net<br>Date&#58; Sun, 15 Jun 2014 18&#58;06&#58;56 +0100<br>Subject&#58; Re&#58; [mantisbt-dev] MantisBT 1.3 Release Status Check<br><br><style><!--
.ExternalClass p.ecxMsoNormal, .ExternalClass li.ecxMsoNormal, .ExternalClass div.ecxMsoNormal {
font-size:12.0pt;
font-family:"Times New Roman","serif";
}

.ExternalClass a:link, .ExternalClass span.ecxMsoHyperlink {
color:blue;
text-decoration:underline;
}

.ExternalClass span.ecxMsoHyperlinkFollowed {
color:purple;
text-decoration:underline;
}

.ExternalClass span.ecxEmailStyle17 {
font-family:"Calibri","sans-serif";
color:#1F497D;
}

.ExternalClass .ecxMsoChpDefault {
font-family:"Calibri","sans-serif";
}

.ExternalClass div.ecxWordSection1 {
}

--></style><div class=ecxWordSection1><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">In terms of 17437, and plugins&lt;&gt;1.3.</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">&#160;</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">I think we need to decide whether a plugin written for 1.2 should load in 1.3. I’m pretty sure there’s another bug out there way I was saying about making a patch to ensure that the plugins are for the targeted mantis version.</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">&#160;</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">Seperately to that, whilst going through this afternoon, I had the idea whether it was possible to port the db query string format changes to 1.3 – whilst still using adodb. i.e. could we allow in 1.3 both the new + old style strings against adodb, then switch in 2.0 to new without adodb. I don’t know if that’s technically possible, but it would provide a migration.</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">&#160;</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">In terms of 16878, I’d argue we should worry about that against the new db layer, as adodb in some cases makes a bad choice of columns types for mssql, and I believe other parts of the code fail to work.</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">&#160;</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">16570 - This appeared to be a regression, and given it’s browser specific nature, could probably do with wider testing.</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">&#160;</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">The other issues, I’d deem as not blocking.</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">&#160;</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">I think there’s a couple of other blocking issues however not on this list – for instance, roland/myself can reproduce an issue with the captcha not working.</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">&#160;</span></p><p class=ecxMsoNormal><span style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;color&#58;#1F497D;">&#160;</span></p><p class=ecxMsoNormal><b><span lang=EN-US style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;">From&#58;</span></b><span lang=EN-US style="font-size&#58;11.0pt;font-family&#58;&quot;Calibri&quot;,&quot;sans-serif&quot;;"> Victor Boctor [mailto&#58;***@gmail.com] <br><b>Sent&#58;</b> 15 June 2014 17&#58;59<br><b>To&#58;</b> MantisBT Dev Mailing List<br><b>Subject&#58;</b> [mantisbt-dev] MantisBT 1.3 Release Status Check</span></p><p class=ecxMsoNormal>&#160;</p><div><div><p class=ecxMsoNormal>I inspected the issues that are marked for v1.3 to see how far we are from the release and found 7 bugs targeted for 1.3. &#160;I grouped them into what two groups based on my opinion of blocking vs. not. &#160;It would be great for everyone to comment on what they are working on that they feel blocks us from putting out the 1.3 release candidate. &#160;We can follow up with further fixes before the final releases.</p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>Blocking and Specific to master&#58;</p></div><div><p class=ecxMsoNormal>--------------------------------</p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>17437&#58; Plugin breaks</p></div><div><p class=ecxMsoNormal>- There are a few changes in 1.3 that breaks plugin, I think we should see if we can fix those. &#160;i.e. keep helper_alternate_class() around just for plugins until we do the breaking changes with the db layer. &#160;There are cases that are technically breaking, but the chance of breaking is rare, vs. the helper_alternate_class which I suspect will be more common for plugins that have configuration pages. &#160;I suggest at least fixing the latter one.</p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>16570&#58; Page content in 'Report Issue' is forgotten when user clicks [Back] button in browser</p></div><div><p class=ecxMsoNormal>- That is a really annoying bug. &#160;Paul has a fix that seems to be pending more reviewers - <a href="https&#58;//github.com/mantisbt/mantisbt/pull/202" target=_blank>https&#58;//github.com/mantisbt/mantisbt/pull/202</a></p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>16878&#58; Install triggers varchar to datetime conversion error on sql server 2008</p></div><div><p class=ecxMsoNormal>- what's the status?</p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>Shouldn't be blocking</p></div><div><p class=ecxMsoNormal>---------------------</p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>9885&#58; Emails on relations is send to people who cannot see the related issue</p></div><div><p class=ecxMsoNormal>- Open since 2008. &#160;Does it really need to block the release? &#160;If there is a targetted fix, let's do it?</p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>11399&#58; Deprecate $g_show_realname and use $g_show_user_realname_threshold instead</p></div><div><p class=ecxMsoNormal>- I don't think this should block v1.3</p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>12382&#58; Long emails aren't sent and make Mantis freeze</p></div><div><p class=ecxMsoNormal>- This is a corner case, is in 1.2.x and can be fixed in a dot release. &#160;Even though it is good to fix, it is not blocking.</p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>12144&#58; changing to the next custom status does not work</p></div><div><p class=ecxMsoNormal>- Nice to fix. &#160;Fix can come in at any time.</p></div><div><p class=ecxMsoNormal>&#160;</p></div><div><p class=ecxMsoNormal>Thanks,</p></div><div><p class=ecxMsoNormal>-Victor</p></div></div></div><br>------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing &amp; Easy Data Exploration
http&#58;//p.sf.net/sfu/hpccsystems<br>_______________________________________________
mantisbt-dev mailing list
mantisbt-***@lists.sourceforge.net
https&#58;//lists.sourceforge.net/lists/listinfo/mantisbt-dev</div> </div></body>
</html>
--_c0eacdcd-f26d-4f07-8c05-e7d47e21c9bd_--
Damien Regad
2014-06-16 14:02:20 UTC
Permalink
>
Roland Becker
2014-06-16 20:56:20 UTC
Permalink
No additional blocking issues for alpha1 from my side.

> Damien Regad <***@mantisbt.org> hat am 16. Juni 2014 um 16:02 geschrieben:
>
>
> >
P Richards
2014-06-18 21:05:58 UTC
Permalink
Damien,

I've resent my ssh key to Victor, as well as adding my public key to this
email.

As soon as the key has been added to the server, I can push the security
fixes I have to a private repository on that box that people can clone form.

Hopefully it'll get added soon as Victor has promised several times
previously to do this.

Paul

-----Original Message-----
From: Damien Regad [mailto:***@mantisbt.org]
Sent: 16 June 2014 15:02
To: Mantisbt-***@lists.sourceforge.net
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check
Damien Regad
2014-06-18 22:01:01 UTC
Permalink
On 2014-06-18 23:05, P Richards wrote:
> I can push the security
> fixes I have to a private repository on that box that people can clone form.

I don't see why server access should be needed to share code privately.

What's wrong with git format-patch and attaching the files to an e-mail?
Paul Richards
2014-06-18 22:11:24 UTC
Permalink
That means you don't get to see the breakdown of the commits that make up
the branch.

In any case, victor promised to add the new key in October. I can
appreciate Victor may have been concentrating on his commercial venture of
MantisHub, but equally, it doesn't take long to add a new ssh key for a
team member onto the project web server.

Paul


On Wed, Jun 18, 2014 at 11:01 PM, Damien Regad <***@mantisbt.org> wrote:

> On 2014-06-18 23:05, P Richards wrote:
> > I can push the security
> > fixes I have to a private repository on that box that people can clone
> form.
>
> I don't see why server access should be needed to share code privately.
>
> What's wrong with git format-patch and attaching the files to an e-mail?
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> mantisbt-dev mailing list
> mantisbt-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
Damien Regad
2014-06-18 22:18:45 UTC
Permalink
On 2014-06-19 00:11, Paul Richards wrote:
> That means you don't get to see the breakdown of the commits that make
> up the branch.

That is incorrect, format-patch will generate one patch file per commit
Victor Boctor
2014-06-19 05:27:27 UTC
Permalink
I don't want to setup git repositories on the server. Please use private repositories via bitbucket.org or format-patch to share code privately. You can even use your server for the same given that I recall you already have gitlab installed on it. That would also enable Damien to access the code that he has been asking for a very long time. I won't guess why it hasn't happened.
> I can appreciate Victor may have been concentrating on his commercial venture of MantisHubBeing busy has nothing to do with not adding the key, I'll provide you access once I believe it is necessary. The above comment wasn't necessary.Date: Wed, 18 Jun 2014 23:11:24 +0100
From: ***@mantisforge.org
To: mantisbt-***@lists.sourceforge.net
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check

That means you don't get to see the breakdown of the commits that make up the branch.
In any case, victor promised to add the new key in October. I can appreciate Victor may have been concentrating on his commercial venture of MantisHub, but equally, it doesn't take long to add a new ssh key for a team member onto the project web server.

Paul

On Wed, Jun 18, 2014 at 11:01 PM, Damien Regad <***@mantisbt.org> wrote:

On 2014-06-18 23:05, P Richards wrote:

> I can push the security

> fixes I have to a private repository on that box that people can clone form.



I don't see why server access should be needed to share code privately.



What's wrong with git format-patch and attaching the files to an e-mail?





------------------------------------------------------------------------------

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions

Find What Matters Most in Your Big Data with HPCC Systems

Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.

Leverages Graph Analysis for Fast Processing & Easy Data Exploration

http://p.sf.net/sfu/hpccsystems

_______________________________________________

mantisbt-dev mailing list

mantisbt-***@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Damien Regad
2014-06-19 13:12:29 UTC
Permalink
On 2014-06-19 07:27, Victor Boctor wrote:
> You can even use your server for the same given that I recall you
> already have gitlab installed on it. That would also enable Damien to
> access the code that he has been asking for a very long time.

LOL I had forgotten about / gave up on it... As I recall Paul told me on
IRC back in January that he'd have some free time in the coming week to
fix this Gitlab access. It's been a loooooooooong week ;-)
Paul Richards
2014-08-11 19:15:44 UTC
Permalink
Victor, as promised on the github PR, here is a copy of my current SSH
public key

Paul


-----Original Message-----
From: P Richards [mailto:***@mantisforge.org]
Sent: 18 June 2014 22:06
To: 'developer discussions'
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check

Damien,

I've resent my ssh key to Victor, as well as adding my public key to this
email.

As soon as the key has been added to the server, I can push the security
fixes I have to a private repository on that box that people can clone form.

Hopefully it'll get added soon as Victor has promised several times
previously to do this.

Paul

-----Original Message-----
From: Damien Regad [mailto:***@mantisbt.org]
Sent: 16 June 2014 15:02
To: Mantisbt-***@lists.sourceforge.net
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check
Paul Richards
2014-08-20 16:51:46 UTC
Permalink
Hello,

Victor, can you use the attached key instead of the previous one.

I've expired the previous public key and have created a new public key to be
added.

Paul

-----Original Message-----
From: Paul Richards [mailto:***@blueyonder.co.uk]
Sent: 11 August 2014 20:16
To: 'developer discussions'
Subject: [mantisbt-dev] FW: MantisBT 1.3 Release Status Check

Victor, as promised on the github PR, here is a copy of my current SSH
public key

Paul


-----Original Message-----
From: P Richards [mailto:***@mantisforge.org]
Sent: 18 June 2014 22:06
To: 'developer discussions'
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check

Damien,

I've resent my ssh key to Victor, as well as adding my public key to this
email.

As soon as the key has been added to the server, I can push the security
fixes I have to a private repository on that box that people can clone form.

Hopefully it'll get added soon as Victor has promised several times
previously to do this.

Paul

-----Original Message-----
From: Damien Regad [mailto:***@mantisbt.org]
Sent: 16 June 2014 15:02
To: Mantisbt-***@lists.sourceforge.net
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check
Paul Richards
2014-10-06 18:44:49 UTC
Permalink
HI victor,

The temporary public key I created before I've now stopped using - so please
do not add the previously issued key when you get around to it.

The correct key is attached, and is valid until 10th October

Paul


-----Original Message-----
From: Paul Richards [mailto:***@blueyonder.co.uk]
Sent: 20 August 2014 17:52
To: 'developer discussions'
Subject: [mantisbt-dev] FW: FW: MantisBT 1.3 Release Status Check

Hello,

Victor, can you use the attached key instead of the previous one.

I've expired the previous public key and have created a new public key to be
added.

Paul

-----Original Message-----
From: Paul Richards [mailto:***@blueyonder.co.uk]
Sent: 11 August 2014 20:16
To: 'developer discussions'
Subject: [mantisbt-dev] FW: MantisBT 1.3 Release Status Check

Victor, as promised on the github PR, here is a copy of my current SSH
public key

Paul


-----Original Message-----
From: P Richards [mailto:***@mantisforge.org]
Sent: 18 June 2014 22:06
To: 'developer discussions'
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check

Damien,

I've resent my ssh key to Victor, as well as adding my public key to this
email.

As soon as the key has been added to the server, I can push the security
fixes I have to a private repository on that box that people can clone form.

Hopefully it'll get added soon as Victor has promised several times
previously to do this.

Paul

-----Original Message-----
From: Damien Regad [mailto:***@mantisbt.org]
Sent: 16 June 2014 15:02
To: Mantisbt-***@lists.sourceforge.net
Subject: Re: [mantisbt-dev] MantisBT 1.3 Release Status Check
Loading...