gmane.comp.bug-tracking.mantis.devel

Re: Revised error message for #2800

Roland Becker — 2012-04-15T11:05:10

Damien Regad <damien.regad-5ypYqlS8vzm41k5uCYKmRQ< at >public.gmane.org> hat am 14. April 2012 um 23:00
geschrieben:



You are right,I expressed in a wrong way what I meant when writing "versioned"
We don't have a Wiki for MantisBT versions 1.1.x, 1.2.x, 1.3.x but we do have
administrator guides for the versions.

Maybe "Wiki does not support branching" are better words for what I really mean.

Still fighting with my sometimes misleading English ;-)

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Re: Revised error message for #2800

Damien Regad — 2012-04-14T21:00:23

By the way, just for the record, this statement is incorrect.
e.g. http://www.mantisbt.org/wiki/doku.php/mantisbt:start?do=revisions

D



------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Re: Revised error message for #2800

Damien Regad — 2012-04-14T20:34:10

I have just pushed some commits to:

- amend Error 2800's message as per my initial suggestion, also taking 
Roland's remark into consideration by mentioning the timeout first.

- added a new chapter "Troubleshooting" in the Admin guide, reflecting 
my findings on this error.

- documented several missing config options

Would appreciate your review and comments/corrections on the new chapter.

All of the above have been ported to master as well.

With regards to automatically linking to the documentation from the 
error message, I logged a new issue [1] on the tracker to follow up.

Damien

[1] http://www.mantisbt.org/bugs/view.php?id=14154


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Re: Revised error message for #2800

Roland Becker — 2012-04-09T18:27:48



John Reese <john-YEv5Xp0AzNLQT0dZR+AlfA< at >public.gmane.org> hat am 9. April 2012 um 19:37 geschrieben:


If this is needed we could add a configuration option
Default in config_defaults_inc.php
$g_documentation_root = "%path%docbook/adminguide"

Distros and git checkouts can change this in config_inc.php to
$g_documentation_root = 'http://www.mantisbt.org/docs/master-1.2.x'

BTW, I never used a MantisBT distro package. They don't deliver the docs?

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Re: Revised error message for #2800

John Reese — 2012-04-09T17:37:16

That's actually an extremely good point, and I really like it.  But it
also assumes that users are running an upstream release of MantisBT --
anyone using a distro package or a git checkout won't be able to
follow those links.  That's the only benefit I see to referencing a
page on our site.  Not sure that outweighs the benefits of your
suggestion though...

Re: Revised error message for #2800

Roland Becker — 2012-04-09T12:18:50



Yes, that's what I meant.
I see two advantages when having such kind of information in
admin guide instead of wiki:

The admin guide is delivered with the installation, so we could use
context sensitive help without linking to foreign pages,
something like:
http://<yourLocalMantisBT>/docbook/adminguide/en/administration_guide.html#ADMIN.TROUBLESHOOTING

The admin guide is versioned information, the wiki is not.
There are no wiki branches, where users could look at the information
which fits to their installed version.


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Re: Revised error message for #2800

Damien Regad — 2012-04-08T22:38:20

Thanks for the feedback.

On 07.04.2012 22:57, Roland Becker wrote:

Good point, I agree with you.


I was actually thinking about adding a section on error messages in the 
wiki (maybe as part of the faq page ? or another dedicated one ?). Are 
you saying that this should be an integral part of the admin guide ?

I also don't believe this should be referenced in error message itself, 
as you say it's too technical and concerns only the admin.

Damien


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Re: Revised error message for #2800

Robert Munteanu — 2012-04-08T21:23:54

+1 on the rewording, either one.
+0 on linking to a wiki page on mantisbt.org, given that we actually
take the time to document it.
-1 on linking on a bug report, these things are not very readable for users.

Re: Revised error message for #2800

Roland Becker — 2012-04-07T20:57:24



John Reese <john-YEv5Xp0AzNLQT0dZR+AlfA< at >public.gmane.org> hat am 7. April 2012 um 20:58 geschrieben:


If the message is most of the time caused by session timeout the message
should be the other way round:
Invalid form security token. This could be caused by a session timeout,
or accidentally submitting the form twice.

I like the idea to provide some more information.
I don't like
a) to show this quite technical information to end-users which are not
administrators
b) to link to an external page (maybe we should link to administrator
documentation)




------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Re: Revised error message for #2800

John Reese — 2012-04-07T18:58:31

On Fri, Apr 6, 2012 at 4:11 PM, Damien Regad
<damien.regad-5ypYqlS8vzm41k5uCYKmRQ< at >public.gmane.org> wrote:

I agree that the current message is inadequate.  I also think both
alternatives are good.  Perhaps we should go one step further and have
the message link to a bug report or wiki page with further
information, explanations, and or advice on how to solve those
problems?

Revised error message for #2800

Damien Regad — 2012-04-06T23:11:11

The current message for this error is:

Invalid form security token. Did you submit the form twice by accident?

In light of the number of issues related to this error, and my personal 
experience showing that in most cases it does NOT occur due to multiple 
form submissions but because of a timeout of the PHP session, I think we 
should reword this error message to mention that fact.

Proposed alternatives (see #14122):

Invalid form security token. This may happen if you submitted the form 
twice by accident, or because your session has timed out.

Invalid form security token. This could be caused by accidentally 
submitting the form twice, or by a session timeout.

Thoughts, comments ?

Damien


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Re: MantisBT 1.2.10 -- to be released soon

Robert Munteanu — 2012-04-03T09:02:17

Doesn't that have the same ownership for which we decided to have two
organizations?


Right, I was trying to find a way to have all plugins in one source
tree for refactoring purposes. Perhaps this is better relegated to a
future CI setup.

Robert

Re: MantisBT 1.2.10 -- to be released soon

Roland Becker — 2012-04-03T06:51:03

Just a collection of thoughts, no real conclusion at the moment:

There is one new feature which is implemented in 1.3.x where some users
are waiting for: "Memo" custom fields. [1]
There is also a patch available for 1.2, but we will get upgrade problems
after users apply the patch and we don't change 1.3 [2][3]

Another commit in 1.3 would give us more options to implement
some eye candy [4]
But 1.2.x is already enough to let some people think that there is a new
MantisBT. Have a look at [5] where I started a collection of user
tweaks. Most of them are nothing more than usage of round corners,
gradients, shadows and changed colors, but it seems to be enough
for some users to stop saying: Mantis is ugly.

If we polish the look in 1.3 by implementing some CSS tweaks this might
attract new users.

If we backport the new custom field type [1] to 1.2.x there is hardly any
reason for existing end-users to upgrade to 1.3 at the moment.

[1] http://www.mantisbt.org/bugs/view.php?id=6626
[2] http://www.mantisbt.org

Re: MantisBT 1.2.10 -- to be released soon

John Reese — 2012-04-02T17:42:53

On Mon, Apr 2, 2012 at 10:30 AM, Robert Munteanu
<robert.munteanu-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


Sounds reasonable, although I think these plugins should still reside
in the mantisbt-plugins group.


I don't think community-maintained plugins should be submodules of the
core repository.  That goes back to my point of not wanting to imply
that we support these plugins with anything other than repository
space and spare developer time when possible.  This would also
complicate the matters for developers/users, where they can't tell
from the repository which plugins are official or not; `git submodule`
would always blindly grab everything.


IMO, plugins that aren't being officially supported and maintained
should not have any part whatsoever in the core repositories.

I think pulling in all community plugins by default at development
time is asking for trouble.  If even a single community plugin does
something that breaks Mantis just by "looking at it", either subltly
or obviously, then it b

Re: MantisBT 1.2.10 -- to be released soon

Robert Munteanu — 2012-04-02T17:30:33

Here's a loose proposal, loosely based on my loose understanding of
git submodules:

We have three classes of plugins:

- Required . These are core plugins which live in the
mantisbt/mantisbt repo and are mandatory for MantisBT to work
properly, e.g. MantisCoreFormatting
- Official . These are plugins which are maintained by the core
MantisBT team and live within their own repo in mantisbt, e.g.
XmlImportExport . These plugins are pulled in as git submodules in the
mantisbt plugins directory
- Community . The rest of the plugins, which live in individual repos
in mantisbt-plugins . These plugins are also pulled in as git
submodules, but are excluded from being packaged into the release
tarballs

This way we get the same release tarballs as usual but with the extra
benefit of pulling in all plugins in a single source location at
development time.

WDYT?

Robert

Re: MantisBT 1.2.10 -- to be released soon

John Reese — 2012-04-02T17:06:42

On Mon, Apr 2, 2012 at 6:22 AM, Robert Munteanu
<robert.munteanu-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Ideally, we would take the responsibility of updating plugins in the
mantisbt-plugins group; that's why core developers have access to all
of them in the first place.  And I agree that we should either create
a "stable/master-1.2.x" branch to maintain working versions while
working on updating them for the newest features.

I'm not a fan of adopting plugins into the core repository for two
main reasons: a) it would generally convey a sense of support and
stability, in that people will expect anything that comes with the
core Mantis repository to be "owned" by us; and b) because we can't
grant commit access to individual sub-folders of the repository,
meaning that plugin contributors would either need core repo access,
or they would have to maintain forks of the entire core repo, which I
don't personally like the idea of.

If there comes a time that we do want some of the plugin repositories
to be

Re: MantisBT 1.2.10 -- to be released soon

Robert Munteanu — 2012-04-02T13:22:37

I agree. Hopefully we don't do this too many times. We should also let
the plugin developers know about that ( how ? ) as soon as we have a
first milestone build.


One way is the Jenkins way - everybody commits to core . I'm not sure
how easy is for us to emulate that.

Another way is to also take responsibility for the plugins hosted at
the mantisbt-plugins Github org and update them when we update the
API. For that we should emulate the branching model we have for
mantisbt so that we don't suddenly break compatibility for plugins
targeted for a stable branch.


OK.


Well, a great +1 here. This change alone should be incentive enough
for everyone to upgrade.

My single comment here is to please not start the templating engine
discussion again. I'd be willing to drive the UI rewrite _without_
adding a template engine and deferring that decision to when it
becomes a requirement.

Robert

Re: MantisBT 1.2.10 -- to be released soon

David Hicks — 2012-04-02T13:08:22

I agree completely but you have to keep in mind just how much of
MantisBT's core is changing (and will need to change). It'd be much
easier to rewrite the plugins already in existence than to maintain a
compatibility layer. We're not just changing the API to something
similar. In many cases we are (and will be) changing the fundamental way
MantisBT and plugins work.

This is also the main reason why I dislike modular plugin architectures
where the modules exist outside the main repository. It's much harder to
sed/grep across all MantisBT plugins to make changes alongside API
updates/subsystem rewrites.

The Linux kernel project strongly encourages driver developers (and
other people maintaining branches) to merge their code back into the
mainline "tree" ASAP (assuming there are enough people interested in
supporting it for years to come once it lands in mainline). There is a
very good reason for this. Perhaps MantisBT could copy this approach?



"HTML is the new HTML5" as per [1]. W3C lost relevance a long

Re: MantisBT 1.2.10 -- to be released soon

Robert Munteanu — 2012-04-02T12:09:22

I know I'm late to the party but ... there is some sort of consensus
that breaking APIs should increment the major version number - see
http://semver.org/ .

I think it's a bit rough on the plugin developers to ask them to chase
APIs for each 1.x release. I would really suggest that we at least
provide a compatibility layer, otherwise the following might occur:

- website X runs on 1.2.10 with 3 plugins
- Mantis 1.3 is released
- Website upgrades -> failure since plugins no longer works
- Rollback

which is not really what we want


A big +1 for that.


Again, being late to the party and all, why are we targeting XHTML
strict support rather than - like all the other cool kids - HTML5 ?
There's been a lot of movement in that area and lots of tools we can
leverage, for instance Twitter Bootstrap [1] .

(snip)


What is our selling point for upgrading to 1.3 ? Most of the excellent
changes you've outlined are foundational, but do not offer very
tangible benefits for end-users . Combined with many plugins break

Re: MantisBT 1.2.10 -- to be released soon

Victor Boctor — 2012-04-02T00:50:24

MantisBT 1.2.10 is now released.  Thanks everyone.  The target release date
for 1.2.11 is 1st of May.  In the meantime, let's resolve issues that are
blocking 1.3.0 to get it out asap.

On Sat, Mar 31, 2012 at 9:27 PM, John Reese <john-YEv5Xp0AzNLQT0dZR+AlfA< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
mantisbt-dev mailing list
mantisbt-dev-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

MantisBT 1.2.10 released

Victor Boctor — 2012-04-02T00:34:09

MantisBT 1.2.10 is a maintenance release. All installations that are
currently running any 1.2.x version or older are advised to upgrade to this
release.

A full changelog for 1.2.10 can be found at:
http://www.mantisbt.org/bugs/changelog_page.php?version_id=146

The release can be downloaded at:
http://www.mantisbt.org/download.php

Checkout Hosted MantisBT <http://www.mantisbt.org/hosting.php> to be up and
running in minutes.  For optimized access to MantisBT from iPhone, Android
and Windows Phone checkout MantisTouch <http://www.mantistouch.org/>.

Cheers,
-Mantis Team
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
mantisbt-dev mailing list
mantisbt-dev-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev