[Gramps-devel] ADMIN: Status of website migration

Our site is nearly ready. The change to the new hosting is complete, with the only thing outstanding being the movement of the SSL certificate. Until that happens, you will be warned that it is unsafe to visit. Hopefully the certificate will soon be into place...

Nick,

The certificate seems to be in place, Chrome doesn't complain about it at all.

Can you configure Mantis so that comments aren't all in bold face, and have attachments appear together near the summary so that one needn't search through the comments to find them? It would be even better if one could flag patches to appear at the top and leave images in-line... and of course it would be really nice if one could view diffs in the tracker and images would actually *display* inline instead of having to download and open them in another application, but I guess that's asking for too much.

Regards,
John Ralls

Nick Wallingford (Gramps)

2017-05-31 03:37:04 UTC

Post by John Ralls
Can you configure Mantis so that comments aren't all in bold face, and have attachments appear together near the summary so that one needn't search through the comments to find them? It would be even better if one could flag patches to appear at the top and leave images in-line... and of course it would be really nice if one could view diffs in the tracker and images would actually *display* inline instead of having to download and open them in another application, but I guess that's asking for too much.

I'm not much of a bug tracker user so you may need to clarify. But I
don't see the comments in bold.

And as near as I can tell, attachments relate to specific comments, so
they appear 'with' the relevant comment.

But like I say, I may be missing something. Give me an example tracker
number for me to look at...

Nick Wallingford
***@gramps-project.org

John Ralls

2017-05-31 04:27:24 UTC

I'm not much of a bug tracker user so you may need to clarify. But I don't see the comments in bold.
And as near as I can tell, attachments relate to specific comments, so they appear 'with' the relevant comment.
But like I say, I may be missing something. Give me an example tracker number for me to look at...

Nick,

It appears that the bold issue is browser-specific:
Chrome: All of the comments are bold and the split between the author column and the comment column is centered in the window.
Firefox: the comments aren't bold and the split is about 1:5.
Safari & Opera: Comments aren't bold and the split is 1:12

I mostly use Chrome.

There's another obvious difference: Only on Chrome the left-hand toolbar has an icon for "summary" that looks like a little graph.

https://gramps-project.org/bugs/view.php?id=7638 <https://gramps-project.org/bugs/view.php?id=7638> is an example of a bug with a patch on it. It was posted on 30 April 2014 and appears there in the stream. Since Mantis doesn't seem to be able to distinguish patches from screen shots I guess there's no way to have only patches summarized at the top, but since the inline behavior is new I wonder if it's configurable so that attachments are linked at the top, inline, or both. A better bug tracker *will* treat patches specially, providing status for them (as in "new", "needs work", "accepted", "rejected", and "superseded") as well as making it possible to easily identify bugs that have patches needing review.

I see that you put a teensy image on https://gramps-project.org/bugs/view.php?id=8366 <https://gramps-project.org/bugs/view.php?id=8366> and that it displays in line, but frankly icons aren't much use on most bug reports. Sam attached a couple of modest-sized (~45K) screenshots on that bug last week and they show only as links. Perhaps there's an inline file size configuration that you can adjust?

Regards,
John Ralls

Paul Franklin

2017-05-31 07:54:18 UTC

I have discovered that the way to upload an attachment
is to click on the "Add Note" button below the <attachment
area> -- once you have "browsed" or "dropped" the to-upload
file.

Nick Hall

2017-05-31 12:35:53 UTC

Post by John Ralls
I see that you put a teensy image on
https://gramps-project.org/bugs/view.php?id=8366 and that it displays
in line, but frankly icons aren't much use on most bug reports. Sam
attached a couple of modest-sized (~45K) screenshots on that bug last
week and they show only as links. Perhaps there's an inline file size
configuration that you can adjust?

I have increased the setting to 100K. The value needs to be set in
bytes rather than K as implied in the documentation.

Nick H.

John Ralls

2017-05-31 13:43:17 UTC

I see that you put a teensy image on https://gramps-project.org/bugs/view.php?id=8366 and that it displays in line, but frankly icons aren't much use on most bug reports. Sam attached a couple of modest-sized (~45K) screenshots on that bug last week and they show only as links. Perhaps there's an inline file size configuration that you can adjust?

I have increased the setting to 100K. The value needs to be set in bytes rather than K as implied in the documentation.

Thanks. That takes care of showing most attachments in the browser.

Regards,
John Ralls

Paul Culley

2017-05-31 16:28:46 UTC

Another bug tracker request:
On my Chrome and Firefox browsers, the activities region, where all the
notes are, is as wide as the longest object in a note, so usually needs to
use the horizontal scroll-bar. Unfortunately with a long list of notes,
that bar is only accessible by scrolling down. So attempting to read a
note near the top is a very frustrating experience.

For example https://gramps-project.org/bugs/view.php?id=9932

I hope there is some setting to use a word-wrap to the window size... Or
else I will really hate this...

Paul C.

Post by John Ralls
I see that you put a teensy image on https://gramps-project.org/

bugs/view.php?id=8366 and that it displays in line, but frankly icons
aren't much use on most bug reports. Sam attached a couple of modest-sized
(~45K) screenshots on that bug last week and they show only as links.
Perhaps there's an inline file size configuration that you can adjust?

Post by Nick Hall
I have increased the setting to 100K. The value needs to be set in

bytes rather than K as implied in the documentation.
Thanks. That takes care of showing most attachments in the browser.
Regards,
John Ralls
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Nick Hall

2017-05-31 17:20:13 UTC

Post by Paul Culley
I hope there is some setting to use a word-wrap to the window size...

The problem is caused by the use of the <pre> tag in the first note.

Nick H.

Paul Franklin

2017-05-31 20:51:54 UTC

I don't see anything I can click on to get a "roadmap"
in the new bug tracker UI.

Nick Wallingford (Gramps)

2017-05-31 20:58:59 UTC

Post by Paul Franklin
I don't see anything I can click on to get a "roadmap"
in the new bug tracker UI.

With both Chrome and Firefox, there is a Roadmap button on the left of
the screen (either logged in or not). I haven't checked any other browsers.

Nick W.
***@gramps-project.org

Paul Franklin

2017-05-31 22:57:32 UTC

Post by Nick Wallingford (Gramps)

Post by Paul Franklin
I don't see anything I can click on to get a "roadmap"
in the new bug tracker UI.

With both Chrome and Firefox, there is a Roadmap button on the left of
the screen (either logged in or not). I haven't checked any other browsers.

With my browser (one of the Mozilla family) I see no such button.
Nor do I see ones which are related (view_all_bug_page.php and
changelog_page.php for instance), although I can see them in the
"source" view of that page.

Just like I can no longer easily login, since whatever the new UI
does is not whatever it used to do, which my browser was happy
to remember, so that I didn't have to type my name every time,
as I now have to do.

Nick Wallingford (Gramps)

2017-05-31 23:43:10 UTC

Post by Nick Wallingford (Gramps)
With both Chrome and Firefox, there is a Roadmap button on the left of
the screen (either logged in or not). I haven't checked any other browsers.

With my browser (one of the Mozilla family) I see no such button.
Nor do I see ones which are related (view_all_bug_page.php and
changelog_page.php for instance), although I can see them in the
"source" view of that page.
Just like I can no longer easily login, since whatever the new UI
does is not whatever it used to do, which my browser was happy
to remember, so that I didn't have to type my name every time,
as I now have to do.

If you can see the relevant tags and links in the source for the page -
what is it that is stopping it from rendering in your browser?

I've intentionally done as close as I could to a 'clean' install for
this upgrade, with only one set of (minimal) mods specific to us (I try
to avoid having to use these, as they must be maintained!) And then
whatever settings were in our existing config file.

Could you send me the text you see in the page's source offlist? I'll
do some reading and see what I can figure is happening.

Nick Wallingford
***@gramps-project.org

Paul Franklin

2017-06-01 00:20:52 UTC

Post by Nick Wallingford (Gramps)
Could you send me the text you see in the page's source offlist? I'll
do some reading and see what I can figure is happening.

Sure.

Sorry for copying the list. No moderator approval is needed.

Tim Lyons

2017-05-31 22:00:08 UTC

Nick W, thanks for all the work you have done to get more up to date software
- it's never easy, and there are always old things that one misses, as well
as seeing the benefits.

Post by Paul Culley
I hope there is some setting to use a word-wrap to the window size...

The problem is caused by the use of the
<pre>
tag in the first note.

Well, yeahbut, even if that stops word-wrap on the whole of the first note,
perhaps it should not affect the other notes, especially as you have to
scroll right down to find the scroll bar.

Does this perhaps need to be raised as a bug on Mantis, if it can't be
changed any other way?

Tim.

--
View this message in context: http://gramps.1791082.n4.nabble.com/Re-ADMIN-Status-of-website-migration-tp4680043p4680059.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

Paul Culley

2017-06-01 12:57:54 UTC

Regarding the long/wide comments in bug tracker, I understand what makes an
object wide, the issue is that since Mantis now has separate frames, each
with their own bottom scroll-bar, when you have a long comments section
then you cannot even get to the scroll-bar without vertically scrolling the
entire page.

If I remember right, I think the previous version of Mantis had only a
single frame, so the web browser had the horizontal scroll-bar available at
the bottom of the page at all times.

If we could get each individual comment to have its own frame (with
scroll-bar if necessary) or do away with the separate frames for each
section, this would not be an issue.

As it is, I suspect that those of us who have edit rights, will end up
editing out the <pre> and other tags that lead to this, just to read the
darn thing.

Post by Paul Culley
I hope there is some setting to use a word-wrap to the window size...

The problem is caused by the use of the <pre> tag in the first note.
Nick H.

Nick Hall

2017-06-01 14:52:36 UTC

Post by Paul Culley
Regarding the long/wide comments in bug tracker, I understand what
makes an object wide, the issue is that since Mantis now has separate
frames, each with their own bottom scroll-bar, when you have a long
comments section then you cannot even get to the scroll-bar without
vertically scrolling the entire page.
If I remember right, I think the previous version of Mantis had only a
single frame, so the web browser had the horizontal scroll-bar
available at the bottom of the page at all times.
If we could get each individual comment to have its own frame (with
scroll-bar if necessary) or do away with the separate frames for each
section, this would not be an issue.

I can't find any configuration option to change this behaviour.

Post by Paul Culley
As it is, I suspect that those of us who have edit rights, will end up
editing out the <pre> and other tags that lead to this, just to read
the darn thing.

We could remove <pre> from the list of valid tags. This would prevent
it being interpreted.

Nick H.

Paul Franklin

2017-06-01 16:57:37 UTC

Post by Nick Hall
We could remove <pre> from the list of valid tags. This would prevent
it being interpreted.

Yet another negative change/drawback.

Nick Hall

2017-06-01 18:02:06 UTC

Post by Nick Hall
We could remove <pre> from the list of valid tags. This would prevent
it being interpreted.

Yet another negative change/drawback.

What do you suggest?

I would prefer using markdown rather than html. This is supported by
the latest version of Mantis, but not enabled by default.

I also think we should investigate source integration.

Nick.

Nick Wallingford (Gramps)

2017-06-01 18:42:59 UTC

Post by Paul Franklin
Yet another negative change/drawback.

What do you suggest?

The upgrade to the current version of MantisBT came about because we
were well behind with upgrades. That was because our previous hosting
was restricted to old versions of both mysql and php - and neither had
any sort of plan to upgrade. It came to a head when I got an urgent
security warning - but it turned out our install was so old that it
wasn't an issue! (Note: I am not saying "this is a good thing".)

We are, to put it bluntly, "consumers" for the MantisBT application.
Apart from actually coding many of the changes suggested, our only real
course of action is to (if you feel strongly about it) work with the
Mantis development team to 'fix' things we do not like.

We have currently one instance of using our own coding in this app, in
order to make this one aspect work "just for us". What it means is that
every time we upgrade the application, I need to go back and make the
changes. Every deviation from the basic install has the potential for
extra and on-going work.

I am not saying that we have to be happy with everything that Mantis
provides - but (1) we may not be able to/want to make every change
suggested (2) we will most certainly want to remain with a current
version and (3) while Mantis is pretty well respected, there may be
other products out there to review.

The current feature set and functionality for Mantis and its ongoing
development is not really something we have a lot of control over.
While we are trying to provide a useful bug tracker, I don't want to
find us in the business of forking into our own version too much!

Nick Wallingford
***@gramps-project.org

Tim Lyons

2017-06-02 15:46:41 UTC

Post by Nick Wallingford (Gramps)

Post by Paul Franklin
Yet another negative change/drawback.

What do you suggest?

The upgrade to the current version of MantisBT came about because we
were well behind with upgrades. That was because our previous hosting
was restricted to old versions of both mysql and php - and neither had
any sort of plan to upgrade. It came to a head when I got an urgent
security warning - but it turned out our install was so old that it
wasn't an issue! (Note: I am not saying "this is a good thing".)
We are, to put it bluntly, "consumers" for the MantisBT application.
Apart from actually coding many of the changes suggested, our only real
course of action is to (if you feel strongly about it) work with the
Mantis development team to 'fix' things we do not like.
We have currently one instance of using our own coding in this app, in
order to make this one aspect work "just for us". What it means is that
every time we upgrade the application, I need to go back and make the
changes. Every deviation from the basic install has the potential for
extra and on-going work.
I am not saying that we have to be happy with everything that Mantis
provides - but (1) we may not be able to/want to make every change
suggested (2) we will most certainly want to remain with a current
version and (3) while Mantis is pretty well respected, there may be
other products out there to review.
The current feature set and functionality for Mantis and its ongoing
development is not really something we have a lot of control over.
While we are trying to provide a useful bug tracker, I don't want to
find us in the business of forking into our own version too much!
Nick Wallingford

<bicycle shed>

Yes, (a) I quite agree that we don't want to be making our own changes to
Mantis, (b) I think it is a good thing to keep up to date with the software
and (c) it wouldn't be a good idea to fiddle around disabling some tags.

As I said before, I do understand that some features or mis-features in
newer version will be better for users, and some will be worse - that's just
how software is.

I see that https://gramps-project.org/bugs/view.php?id=9932 has now been
edited to avoid the problem.

My suggestion is that the current behaviour should be regarded/raised as a
bug in Mantis. Surely it can't be right that one long "pre" taged line
causes all the rest of the completely separate comments to be stretched to
the length of the long line, with the scroll bar hidden at the bottom of the
bug, which can be many pages further on.

I think I have seen other UIs where there is just a scroll bar for the
formatted text, for example here: https://trac.macports.org/ticket/54242

So, is this already a bug report to MantisBT?

Regards,
Tim.

(By the way, I don't think we should change the bug tracker just because we
don't like a feature).

--
View this message in context: http://gramps.1791082.n4.nabble.com/Re-ADMIN-Status-of-website-migration-tp4680043p4680084.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

Paul Franklin

2017-06-02 03:18:21 UTC

Post by Nick Hall
We could remove <pre> from the list of valid tags. This would prevent
it being interpreted.

Yet another negative change/drawback.

What do you suggest?

Keeping <pre> (and <code>, as NickW suggests.).

Nick Wallingford (Gramps)

2017-06-01 23:40:53 UTC

Post by Nick Hall
We could remove <pre> from the list of valid tags. This would prevent
it being interpreted.

Yes, we can determine which tags are allowed in the comments area. But
the way I figure it, the <PRE> and <CODE> tags do have a purpose, and if
used well contribute to readability and understanding.

Using <PRE> to create lines that are too long for the screen? I would
have no qualms editing a msg to reduce the line length. If users use
the tags well, and Mantis delivers up code appropriately, and if the
user's browser renders it as it should be - all should be well. What
could possibly go wrong?

Seriously, I believe we should allow <PRE> tags - but just be willing to
edit if they become obstructive. It that work gets onerous, then we can
restrict the tag's use...

Nick Wallingford
***@gramps-project.org

Nick Hall

2017-06-02 12:16:45 UTC

Post by Nick Wallingford (Gramps)
Seriously, I believe we should allow <PRE> tags - but just be willing
to edit if they become obstructive. It that work gets onerous, then
we can restrict the tag's use...

I agree.

A quick search reveals that we mainly use only three tags: <pre>, <i>
and <b>.

Using tags incorrectly can cause problems. For an example, see:

https://gramps-project.org/bugs/view.php?id=980#c2478

I didn't realise that the <code> tag was in the valid list by default.

Nick H.

Sam Manzi

2017-06-03 23:57:47 UTC

Hi Nick,

Thank you for the upgrades, testing mantisdb and the blog seems fine to me.

Believe I've identified an issue with the wiki, when attempting to register
as a new user ("request an account") at submission time I end up getting a
blank page and the same blank page when attempting to go to the confirm
accounts page(from a bookmarked shortcut I had, so the link may have
changed?) :
https://gramps-project.org/wiki/index.php?title=Special:ConfirmAccounts

Kind regards
Sam

Paul Franklin

2017-06-05 21:03:26 UTC

The email notifications are current configured to send emails to the
user who reported the issue, the user who is handling the issue and
users monitoring this issue (that last one in most cases, but not all).
There are 13 different cases - from email on updated, email on deleted,
etc, to trigger the sending.

Your role in the bug tracker is as a Developer, which explains why you
are getting those emails. You can configure your own preferences in
your profile/account information page.

I have been a Developer for years, yet only now am
I getting non-monitored bug tracker email messages.

No changes to these configurations were made in the transition to the
upgraded version of MantisBT, and I can't find any references to the
behaviour being changed.

OK. It changed but I can easily believe they didn't document it.

But I'm pretty sure that you can restrict the emails received relating
to your Developer status.

I will put it on my list, to try to investigate. 8-)

In the meantime, I'll just live with it, and the other stuff.

Thanks for looking into it.

Nick Wallingford (Gramps)

2017-06-05 21:31:00 UTC

Post by Paul Franklin
In the meantime, I'll just live with it, and the other stuff.

Sorry. I may not have been clear. I am not suggesting that you just
have to live with it. I'm pretty certain for receiving (or in your
case, not receiving) emails can be controlled by each user in their
profile settings.

If that fails, I would then look into it more closely.

As for any changes to the defaults, I am not saying that documentation
is not there - I'm saying that I have not seen it. And in the scheme of
things, as I see it, it isn't a major issue. It would not, I think,
impact on reporters and others in the bug tracker, and if there was a
change, it results in *more* rather than *less* - and if it can be user
configured, will not result in too many problems.

I'm not sure *why* you were not getting emails such as this previously -
my reading of it is that you *should* have been all along, given the
Developer status of your account.

The other stuff you refer to (overall GUI and failure to retain
username/password between sessions) relates to the browser you are
using. And though I know you want to keep using it, I believe you will
increasingly find issues similar to this as it ages even more.

Nick Wallingford
***@gramps-project.org

Paul Franklin

2017-06-11 18:09:47 UTC

Evidently in the new bug tracker an inline doubled-underscore
turns on bold (and a second inline doubled-underscore turns it
off). This is somewhat annoying as some of the tracebacks
contain such things (see 10065 for instance).

Can this "feature" be disabled?

Thanks.

Nick Hall

2017-06-11 19:38:31 UTC

Post by Paul Franklin
Evidently in the new bug tracker an inline doubled-underscore
turns on bold (and a second inline doubled-underscore turns it
off). This is somewhat annoying as some of the tracebacks
contain such things (see 10065 for instance).
Can this "feature" be disabled?

Yes. I enabled markdown as an experiment.

It can be useful, but is annoying for file names.

Nick.

Nick Wallingford (Gramps)

2017-06-11 19:44:41 UTC

Post by Nick Hall
Yes. I enabled markdown as an experiment.
It can be useful, but is annoying for file names.

The BBCode like editing suits many people, as it mimics what is
generally available in a wiki. But as the other Nick says, it can mess
up file names if people do not 'escape' these simple characters that
result in formatting changes.

Paul Franklin

2017-06-12 04:26:01 UTC

Post by Paul Franklin
Can this "feature" be disabled?

Yes. I enabled markdown as an experiment.
It can be useful, but is annoying for file names.

Thank you for taking care of it.

Paul Franklin

2017-06-14 04:41:40 UTC

Post by Paul Franklin
Can this "feature" be disabled?

Yes. I enabled markdown as an experiment.
It can be useful, but is annoying for file names.

Thank you for taking care of it.

The "bold font" behavior seems to be back.

See 10077 and 10078 for instance.

Nick Hall

2017-06-14 20:29:04 UTC

Post by Paul Franklin
Can this "feature" be disabled?

Yes. I enabled markdown as an experiment.
It can be useful, but is annoying for file names.

Thank you for taking care of it.

The "bold font" behavior seems to be back.
See 10077 and 10078 for instance.

Markdown is still enabled.

I have edited these bugs to use <pre> tags. Attaching the output as a
file would be another good option.

Nick.

Paul Franklin

2017-06-15 00:13:48 UTC

Post by Nick Hall
Markdown is still enabled.

Are you saying "... and it will stay enabled"?

Given that our built-in crash reporter includes traceback
when it posts a bug report, I think that is a very poor idea.

Unless you plan to recursively search gramps50 and
eliminate every double-underscore method and variable?
8-)

Nick Hall

2017-06-15 11:29:07 UTC

Post by Nick Hall
Markdown is still enabled.

Are you saying "... and it will stay enabled"?

I suggest that we continue the evaluation.

Post by Paul Franklin
Given that our built-in crash reporter includes traceback
when it posts a bug report, I think that is a very poor idea.

We can easily add <pre> tags.

Nick.

John Ralls

2017-06-15 14:47:42 UTC

Post by Nick Hall
Markdown is still enabled.

Are you saying "... and it will stay enabled"?

I suggest that we continue the evaluation.

Post by Paul Franklin
Given that our built-in crash reporter includes traceback
when it posts a bug report, I think that is a very poor idea.

We can easily add <pre> tags.

Or better yet, add the code-block markup for whatever flavor of markdown this is (e.g. Github uses ```).

The issue I have is that there’s no indication in the UI that it’s there, no help button to explain the markup to users (there are a bunch of different wiki markup flavors out there, which one is this?) and no preview button so that one can see what one’s post will look like until it’s added.

Regards,
John Ralls

Nick Hall

2017-06-15 18:35:29 UTC

Post by John Ralls

Post by Nick Hall
We can easily add <pre> tags.

Or better yet, add the code-block markup for whatever flavor of markdown this is (e.g. Github uses ```).

I enabled this feature because I am also evaluating the Mantis Source
Integration plugin. It should enable us to see any markdown in commit
messages correctly displayed. Since Mantis use GitHub and this plugin
themselves, it looks like they use GitHub flavour markdown, but I am not
100% sure.

Post by John Ralls
The issue I have is that thereâs no indication in the UI that itâs there, no help button to explain the markup to users (there are a bunch of different wiki markup flavors out there, which one is this?) and no preview button so that one can see what oneâs post will look like until itâs added.

I agree that a "preview" button would be nice, for the existing markup
as well as for markdown.

To explain markdown, and other handy features, we could add an extra
menu item on the left-hand-side which links to a wiki page.

The advantages of markdown are:

1. Integration with GitHub.

2. Easy to learn, but developers probably already know the basics.

The only disadvantages is that we have to escape some characters or use
code blocks. I can find cases where the current markup should be
escaped but isn't.

I certainly think this is worth evaluating.

Nick.

John Ralls

2017-06-15 19:43:03 UTC

Post by John Ralls

Post by Nick Hall
We can easily add <pre> tags.

Or better yet, add the code-block markup for whatever flavor of markdown this is (e.g. Github uses ```).

I enabled this feature because I am also evaluating the Mantis Source Integration plugin. It should enable us to see any markdown in commit messages correctly displayed. Since Mantis use GitHub and this plugin themselves, it looks like they use GitHub flavour markdown, but I am not 100% sure.

Post by John Ralls
The issue I have is that there’s no indication in the UI that it’s there, no help button to explain the markup to users (there are a bunch of different wiki markup flavors out there, which one is this?) and no preview button so that one can see what one’s post will look like until it’s added.

I agree that a "preview" button would be nice, for the existing markup as well as for markdown.
To explain markdown, and other handy features, we could add an extra menu item on the left-hand-side which links to a wiki page.
1. Integration with GitHub.
2. Easy to learn, but developers probably already know the basics.
The only disadvantages is that we have to escape some characters or use code blocks. I can find cases where the current markup should be escaped but isn't.
I certainly think this is worth evaluating.

No, there's another disadvantage: If we start putting markdown in commit messages then they'll look weird when viewed anywhere but Github. I'd prefer we not go down that road.

Regards,
John Ralls

Nick Hall

2017-06-15 19:59:43 UTC

Post by John Ralls
No, there's another disadvantage: If we start putting markdown in commit messages then they'll look weird when viewed anywhere but Github. I'd prefer we not go down that road.

If we don't want markdown in commit messages, we should state it in a
new policy.

Mantis actually supports a subset of html, bbcode and markdown. We could
still allow it in Mantis for those that want to use it. What do you think?

Nick.

Paul Franklin

2017-06-15 20:07:04 UTC

Post by Nick Hall
If we don't want markdown in commit messages, we should state it in a
new policy.

Great idea. I say "git log" and "git show" all the time.

Post by Nick Hall
Mantis actually supports a subset of html, bbcode and markdown. We could
still allow it in Mantis for those that want to use it. What do you think?

I am against the use of double-underscore in Mantis, as I
have repeatedly said, for all my previously-stated reasons.

I have no objections to < pre > (which has always been there).

Nick Hall

2017-06-15 20:23:03 UTC

Post by Nick Hall
Mantis actually supports a subset of html, bbcode and markdown. We could
still allow it in Mantis for those that want to use it. What do you think?

I am against the use of double-underscore in Mantis, as I
have repeatedly said, for all my previously-stated reasons.

OK. If other developers agree with you than I am happy to disable the
setting.

Nick.

Paul Franklin

2017-06-15 20:56:50 UTC

Post by Nick Hall
Mantis actually supports a subset of html, bbcode and markdown. We could
still allow it in Mantis for those that want to use it. What do you think?

I am against the use of double-underscore in Mantis, as I
have repeatedly said, for all my previously-stated reasons.

OK. If other developers agree with you than I am happy to disable the
setting.

OK.

You might consider whether you want to start a separate
thread, for such a "policy" decision. In case people are
not reading this thread anymore because they think it is
all about the "website migration" -- as opposed to how the
bug tracker should function.

Nick Wallingford (Gramps)

2017-06-15 21:07:21 UTC

Post by Paul Franklin
You might consider whether you want to start a separate
thread, for such a "policy" decision. In case people are
not reading this thread anymore because they think it is
all about the "website migration" -- as opposed to how the
bug tracker should function.

I guess one might say that the *policy* is that users should have an
effective bug reporting mechanism that doesn't require much more than
'normal' web interaction capabilities.

But the *operational* side of that is something that I variously end up
working on regularly, as it would be an unusual week that I do not need
to make some changes to the configuration/capability of bugtracker, wiki
and blog. Though I did not enable the markup, it is certainly the type
of thing that I might do on a regular basis. And I can assure you that
I would not really want to clutter this list with each of those 'policy'
changes - they are not what I perceive as 'policy'...

Adding a polling module, for instance (something that came up in the
last few months) might involve me installing and testing a range of
options. I don't really think our project would be greatly enhanced if
we were to try to document such things fully, and argue out the feature
sets on this developers' list.

If there are things that need to be changed to make our internal systems
more usable for developers, even if only a 'maybe' to begin with, I
suggest we keep trying to do so - and not sure I want to experience a
thread to discuss each one of them...

Nick Wallingford
Tauranga, NZ

Paul Culley

2017-06-15 21:44:28 UTC

While we are discussing the bug tracker, a more interesting issue is that
the URL for it has changed; thus rendering Gramps built-in report code non
useful.

Old URL http://bugs.gramps-project.org/bug_report_page.php
New URL https://gramps-project.org/bugs/bug_report_page.php

Paul C.

On Thu, Jun 15, 2017 at 4:07 PM, Nick Wallingford (Gramps) <

Post by Paul Franklin
You might consider whether you want to start a separate

Post by Paul Franklin
thread, for such a "policy" decision. In case people are
not reading this thread anymore because they think it is
all about the "website migration" -- as opposed to how the
bug tracker should function.

I guess one might say that the *policy* is that users should have an
effective bug reporting mechanism that doesn't require much more than
'normal' web interaction capabilities.
But the *operational* side of that is something that I variously end up
working on regularly, as it would be an unusual week that I do not need to
make some changes to the configuration/capability of bugtracker, wiki and
blog. Though I did not enable the markup, it is certainly the type of
thing that I might do on a regular basis. And I can assure you that I
would not really want to clutter this list with each of those 'policy'
changes - they are not what I perceive as 'policy'...
Adding a polling module, for instance (something that came up in the last
few months) might involve me installing and testing a range of options. I
don't really think our project would be greatly enhanced if we were to try
to document such things fully, and argue out the feature sets on this
developers' list.
If there are things that need to be changed to make our internal systems
more usable for developers, even if only a 'maybe' to begin with, I suggest
we keep trying to do so - and not sure I want to experience a thread to
discuss each one of them...
Nick Wallingford
Tauranga, NZ
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Nick Wallingford

2017-06-15 22:05:56 UTC

Post by Paul Culley
While we are discussing the bug tracker, a more interesting issue is
that the URL for it has changed; thus rendering Gramps built-in report
code non useful.
Old URL http://bugs.gramps-project.org/bug_report_page.php
New URL https://gramps-project.org/bugs/bug_report_page.php

The use of the sub-domain bugs.gramps-project.org has been functional
since we implemented an SSL cert to make the entire hosting https - that
was several years ago now, I think.

I don't always know how all our various systems fit together - let me
know where the link you are viewing appears, please.

I *did*, just this morning, hopefully correct a link to the bug tracker
that is on the opening page of gramps-project.org . It took me longer
than it should have to find where I needed to change it, as I am not all
that WordPress competent...

Nick Wallingford
Tauranga, NZ

Paul Franklin

2017-06-16 04:29:46 UTC

Post by Nick Wallingford (Gramps)

Post by Paul Franklin
You might consider whether you want to start a separate
thread, for such a "policy" decision. In case people are
not reading this thread anymore ...

The only reason I suggested a separate thread is that (the
other) Nick suggested a vote on my request and I was trying
to maximize the number of people who knew that a vote was
taking place. Or maybe a "canvas" or "opinion poll" if "vote"
sounds too severe or something. 8-)

Post by Nick Wallingford (Gramps)
If there are things that need to be changed to make our internal systems
more usable for developers, even if only a 'maybe' to begin with, I
suggest we keep trying to do so - and not sure I want to experience a
thread to discuss each one of them...

I am definitely not trying to make more work for you, Nick.

You do an immense amount of things for us -- and as you
have hinted I'm sure that most of it happens in the background,
unacknowledged.

But we do appreciate it, even if we don't say so every day!

John Ralls

2017-06-15 20:21:49 UTC

Post by John Ralls
No, there's another disadvantage: If we start putting markdown in commit messages then they'll look weird when viewed anywhere but Github. I'd prefer we not go down that road.

If we don't want markdown in commit messages, we should state it in a new policy.
Mantis actually supports a subset of html, bbcode and markdown. We could still allow it in Mantis for those that want to use it. What do you think?

I'm mostly indifferent about it in comments. If Mantis supports syntax highlighting it could be useful for code snippets, but otherwise I don't see much reason to use it. As Paul has pointed out the __foo__ behavior is unfortunate; perhaps when wrapped in a code block (```...``` on Github) it would behave better.

I noticed one other wart: A block quote in one comment that was rendered the same as a code block. Combined with the UI issues I mentioned earlier it all suggests that the feature is not yet fully baked.

Regards,
John Ralls

Nick Hall

2017-06-15 20:28:39 UTC

Post by John Ralls
I noticed one other wart: A block quote in one comment that was rendered the same as a code block. Combined with the UI issues I mentioned earlier it all suggests that the feature is not yet fully baked.

Yes. Indented lines will be regarded as a code block.

https://daringfireball.net/projects/markdown/syntax#precode

I'll disable it now before it is used. I have only seen it used a few
times in git commit messages.

Nick.

Paul Franklin

2017-06-15 15:44:02 UTC

Post by Nick Hall
Markdown is still enabled.

Are you saying "... and it will stay enabled"?

I suggest that we continue the evaluation.

Post by Paul Franklin
Given that our built-in crash reporter includes traceback
when it posts a bug report, I think that is a very poor idea.

We can easily add <pre> tags.
Nick.

I still think it is a poor idea, a big inconvenience for very
minimal gain.

Among other things, it will mean somebody will have to
edit each bug report which some user pastes in from
running gramps in a console window or xterm, which is
one of the standard things we advise them to do. Not
every bug report comes from our automatic poster.

Are /you/ willing to do that, within say 24 hours of whenever
I send you a pointer to some particular bug? Or are you
saying that since regular readers of the bug tracker will
be most bothered they can start getting into that habit?

What about old bugs (like the one I was looking at within
the last hour)? Some have the identical problem for the
exact same reason. You can't seriously be saying that
we need to edit every such bug, just because you think
that whatever "markup" you have enabled will help (you).

I request that you turn it off.

If you want to continue "evaluation" how long will that last,
and why are you evaluating it at all? Who will benefit? How
exactly? Certainly it won't be me.

Respectfully.

Nick Hall

2017-06-15 18:46:54 UTC

Post by Paul Franklin
I still think it is a poor idea, a big inconvenience for very
minimal gain.
Among other things, it will mean somebody will have to
edit each bug report which some user pastes in from
running gramps in a console window or xterm, which is
one of the standard things we advise them to do. Not
every bug report comes from our automatic poster.
Are/you/ willing to do that, within say 24 hours of whenever
I send you a pointer to some particular bug? Or are you
saying that since regular readers of the bug tracker will
be most bothered they can start getting into that habit?
What about old bugs (like the one I was looking at within
the last hour)? Some have the identical problem for the
exact same reason. You can't seriously be saying that
we need to edit every such bug, just because you think
that whatever "markup" you have enabled will help (you).
I request that you turn it off.
If you want to continue "evaluation" how long will that last,
and why are you evaluating it at all? Who will benefit? How
exactly? Certainly it won't be me.

It will benefit anyone using Mantis GitHub integration which I think
could be very useful. I plan to evaluate this and markdown for a few months.

There is no reason to correct old bugs, certainly not closed ones. I
will probably correct any bug that I am working on.

It is much better to encourage users to upload log files, terminal
output, stack traces etc... as attachments.

I regard this as only a minor drawback.

Nick.

John Ralls

2017-06-15 19:47:31 UTC

Post by Paul Franklin
I still think it is a poor idea, a big inconvenience for very
minimal gain.
Among other things, it will mean somebody will have to
edit each bug report which some user pastes in from
running gramps in a console window or xterm, which is
one of the standard things we advise them to do. Not
every bug report comes from our automatic poster.
Are
/you/
willing to do that, within say 24 hours of whenever
I send you a pointer to some particular bug? Or are you
saying that since regular readers of the bug tracker will
be most bothered they can start getting into that habit?
What about old bugs (like the one I was looking at within
the last hour)? Some have the identical problem for the
exact same reason. You can't seriously be saying that
we need to edit every such bug, just because you think
that whatever "markup" you have enabled will help (you).
I request that you turn it off.
If you want to continue "evaluation" how long will that last,
and why are you evaluating it at all? Who will benefit? How
exactly? Certainly it won't be me.

It will benefit anyone using Mantis GitHub integration which I think could be very useful. I plan to evaluate this and markdown for a few months.
There is no reason to correct old bugs, certainly not closed ones. I will probably correct any bug that I am working on.
It is much better to encourage users to upload log files, terminal output, stack traces etc... as attachments.
I regard this as only a minor drawback.

Why is markdown necessary for Github integration?

Requiring users to create attachments is a barrier: Rather than just pasting in copied content they must instead paste it into an editor, save it to a file, then upload the file. That will serve only to discourage them from providing the information.

Regards,
John Ralls

Nick Hall

2017-06-15 20:02:15 UTC

Post by John Ralls
Why is markdown necessary for Github integration?

It isn't. It is only useful when developers use markdown in commit
messages.

Post by John Ralls
Requiring users to create attachments is a barrier: Rather than just pasting in copied content they must instead paste it into an editor, save it to a file, then upload the file. That will serve only to discourage them from providing the information.

This is just my personal preference. I hate scrolling through large
amounts of inline text.

Nick.

Nick Hall

2017-06-20 13:53:11 UTC

Three different developers (Serge, me, Josip) have noticed
that foo.gramps files uploaded to the bug tracker and then
subsequently downloaded (by either the same person or a
different person) are not correct.
When downloaded they are compressed twice, not once.
When uploaded they start out as the gramps-compressed
(gunzip?) normal foo.gramps file. I can't tell if the second
compressing happens upon receipt by Mantis or when the
file is then downloaded.
But a simple test failed. I got back the same file I had
uploaded, when that file was a Windows-made foo.zip of
a simple text file I'd created.
Only when I uploaded an old (3.1.3, thus compressed)
data.gramps and then downloaded it were the file sizes
different. (I haven't tested if it's doubly compressed but
I assume it is.)
So I suspect (= guess) that Mantis somehow (?) looks
at the file-type encoding(?) and if it is something it thinks
it understands (foo.txt, "official" foo.zip, etc.) it leaves it alone.
But if it detects something it doesn't know about (maybe
a gunzip-compressed file for instance), then it compresses
it (again), perhaps for safety.
Anyway, I hope you can fix it -- if it's a bug. If it's by design
then at the least I think you should notify people it happens.
Thanks.

Mantis doesn't compress attachments. There is a feature request:

http://mantisbt.org/bugs/view.php?id=10603

What bug reports are you having problems with?

Nick.

Paul Franklin

2017-06-20 17:33:27 UTC

http://mantisbt.org/bugs/view.php?id=10603
What bug reports are you having problems with?
Nick.

I'd have to research it, to find the real bugs we noticed
problems with.

I did my last test on 9422.

If you look at the last comment, the byte count gives the
correct size of the file I uploaded. If you download it, it
will be a different size (and I said, probably doubly zipped,
although I haven't checked).

Note that I didn't copy the whole list but you added it
so I am replying to them also.

Nick Hall

2017-06-20 18:32:44 UTC

Post by Paul Franklin
If you look at the last comment, the byte count gives the
correct size of the file I uploaded. If you download it, it
will be a different size (and I said, probably doubly zipped,
although I haven't checked).

For some reason output compression is not being disabled. See:

https://github.com/mantisbt/mantisbt/blob/master/file_download.php#L131

We need to check the ini files and permissions.

Nick.

Nick Wallingford (Gramps)

2017-06-20 19:19:46 UTC

Post by Nick Hall
https://github.com/mantisbt/mantisbt/blob/master/file_download.php#L131
We need to check the ini files and permissions.

That bug had a small change that was to seemingly fix the issue. I can
confirm our config has that change in it already (ie, the fix was
incorporated into our version).

I'm a bit snowed under here today, so not likely to any more done on
this - I do see there are a few config items that might impact, but will
have to leave it to Nick H for the rest of the day, at least - family
health stuff takes priority.

Nick Wallingford
Tauranga, NZ

Paul Franklin

2017-07-05 19:50:43 UTC

I want to "reopen" a bug on the bug tracker.

It won't let me.

When I click on the "reopen" button I get an error
message (1104 I think it was), saying it is read-only.

I'd appreciate it if you can fix that.

Thanks.

Paul Franklin

2017-07-11 17:19:01 UTC

https://github.com/mantisbt/mantisbt/blob/master/file_download.php#L131
We need to check the ini files and permissions.
Nick.

I believe this is still happening, the file compression
when a foo.gramps is downloaded.

Nick Wallingford

2017-06-16 08:27:48 UTC