Bug Busters

[taazz]

Imagine a client application (bug tracker) that uses the mantis database schema in the background ...

There is a feature request for such application
  http://bugs.freepascal.org/view.php?id=19799
However is has a very low priority IMO. There are plenty of critical bugs and missing features in Lazarus, and the current Mantis browser GUI very well.
So taazz, please first fix the other bugs in Lazarus and then you can make the Mantis client app.

Well a mantis client could be used for other projects as well not only FPC/lazarus so everything depends on my personal time and demand but so far it probably is even lower in my to do list than the team's list. So yeah my priority is to have my desktop going again to be able to waste as much space as I have/want then I'll start working with the trunk again and then I'll look where I can help and be assured I'm not going to just start sending in patches  I'll select a number of issues I'm interested in and you guys will have to point the most important ones out for me to work on.

[JuhaManninen]

On this forum, I believe we have programmers of all levels.

Yes and obviously I did not ask help from the newbies for fixing bugs in a near 2,000,000 LOC Lazarus project.
I asked help from people who are capable for it. I know there are many talented and experienced people around here.

Do Mantis tickets can be sorted (and searched) for hardness of solution? For example, "01" for "very easy to solve" through "10" to "very difficult to solve".
This would help new contributtors to choose tickets according to their experience.

No, for 2 reasons:
1. The hardness depends on the person's skills. Someone is good with parsers, someone with graphics, someone with GTK2 widgetset code etc.
2. To determine the hardness of a particular problem one must dive into the code and analyze it. At that point he would already be half-way fixing the problem.
So, in practice _you_ are the person who must analyze the bugs you want to fix. Understood?

I believe many people here can and would like to contibute, but hey do not know how to do it.
So they try to contribute opening tickets on Mantis.

Yes I know but as I explained we have plenty of tickets but too few patches.
To be honest, some of the tickets are not very good and they must be resolved as "Unable to reproduce" or "No change required".
Handling those poor tickets eats the developers' capacity which could be used for more usefull things.

On the main page of http://lazarus.freepascal.org/ can we have a box similar to "Recent Forum Posts" that shows "Recent Opened/Changed Tickets"?
Or at least, a box similar to "Community" called maybe "Help Development" that shows links like the ones we are posting on this thread? We could put "Recent Opened/Changed Tickets" as on of those links.

Why? Do you mean you cannot fix bugs in Lazarus code unless you have a link for them on the main web page? Nonsense!
Either dive into the code and fix a bug, or then don't do it. There is no need for this empty nonsense.

Does Mantis has any kind of tool for voting? If so, this would clarify what tickets are more needed by community.

Yes. Select a bug you want to get fixed, fix it, attach a patch to the bug report and the fix will be included in the next release. The community will be happy.
But if you only want to vote what _other_ people should do then please stop this nonsense.

[howardpc]

I can't seem to login to Mantis, don't know why.
So I'll attach here a patch for issue 26258 (Object Inspector expand/contract glyph drawn too low), since this was simple enough that even I could figure out what needed changing in objectinspector.pp.

[taazz]

Yes. Select a bug you want to get fixed, fix it, attach a patch to the bug report and the fix will be included in the next release. The community will be happy.
But if you only want to vote what _other_ people should do then please stop this nonsense.

That is partly true lets consider this
What happens (for example) when I have no experience with compilers and even less with exception handling routines how am I suppose to indicate that my need for enabling my application to catch all exceptions and never, ever, allow the default system exception handler to be raised is significant to me but I don't know how to fix it? How about some one that really submits patches in a similar situation? Should we all try our best to be proficient in every aspect of the computer engineering field so we can "fix" what ever bothers us in this project?

How about this

Give all the signed in user of the bug tracker a fixed number of points which they can use to vote for which bugs are important to them.
Lets say they get 10 points they can apply as many as the want to each issue up to the maximum free points they have. Every one that submits a patch for consideration solving an existing bug/feature gets 1 more point, if the patch gets accepted and applied s/he gets one or two more points, if the patch is nothing but point hunting expedition s/he gets banned.

no one gets to work on something they do not like and after a while the people that do the work have more control.

PS:
Just some thoughts until I get my desktop up and going again. waiting anxiously......

[JuhaManninen]

If you want to increase the number of patches you need to make sure that the process is as unobstructive as possible. You need to prepare an expert that will do the following. ...

I don't know what to think of this...
I have understood you taazz are an experienced programmer, yet now you suggest that an "expert" application taking care of some trivial revision control tasks would "increase the number of patches". Actually you ask to replicate the functionality of an SVN client + some other SW which is dummy.

This reminds me of the "expert" people who used to whine on this forum some years ago about how poorly organized the Lazarus development is and how inferior tools are used ... etc.
Nobody never saw a single line of source code from those whiners. Nothing good came from them, they only wasted everybody's time and energy.
One popular topic was Git against SVN. According to the "experts" the usage of Git would bring a substantial amount of new developers to Lazarus project. Well, using Git in a distributed manner has been supported for some 3 years now but still _nobody_ has used this opportunity.
  http://wiki.freepascal.org/Creating_A_Patch#Using_a_forked_Git_repository_directly
"Substantial amount of new developers" my ass!

The fact is that our development tool chain works exceptionally well.
There is FPC and Lazarus. They both are now mature and robust tools.
Then there is the robust SVN server. Many advanced clients can be used with it. Even Git can be used through "git-svn link". I actually use it for my development and it is very good.
There is the excellent Mantis bug tracker. It supports advanced filtering of issues. In fact it is near perfect, better than Bugzilla IMO. Finding the old patches is maybe the only usability problem I can think of.
There is the debugger, GDB. Despite of some imperfections it covers all my debugging needs.

There are still more tools and all of them are good. They have never prevented me from fixing or implementing something in Lazarus code. The only limiting factor has always been my own brain capacity.
For example I have used 10 or 12 hours sometimes to fix a single bug, learning code, experimenting, throwing away the experiments, experimenting more, testing, tweaking and so on.
Finally the change may be only a few lines of code. I can commit it in few seconds. Then I close the bug report with a message "Fixed, please test". It takes another few seconds.
Now when somebody explains that better tools for the development process would "increase the number of patches", it feels so stupid. Such person clearly has no glue about what it means to change code in a 2,000,000 LOC project.
taazz, can you please explain?

[taazz]

1) I never said that I need it.
2) I described what I think is an unobstructive process that I think would help.
3) I did say that I was considering writing the expert though and I never asked any one to do it.
4) I like to minimize my time spend on maintenance tasks as much as possible. For me double clicking on a bat file to start the checkout of the latest revision is a maintenance task and must be automated.

In sort my experience with my first patch on the synedit's sql highlighter was a lesson to learn and it worries me that something similar will happen. Specifically I imposed on Martin_fr with a patch on older files that brought in a lot of old code already cleanup making hes job harder instead of easier. I would like to avoid that in the future if possible.

In the mean time the process I described eliminates 2 time consuming tasks
1) learn how to use a vcs (svn git etc)
2) learn how to create a diff.

Eliminating time consuming tasks by providing a process for that, should in turn help people that do not have the time to spend or they do not want to spend it on those tasks. I never talked about hordes of developers that will come to provide patches I only said that people already using the tool might be more inclined to try and create a patch instead of simple reporting a bug if the time consuming tasks are automated.

PS
There a couple more thinks to the above list that I'm thinking to implement that will help in my opinion like autorunning the test cases of application/library patched making sure that everything is on the green before creating the patch and a couple more thoughts that are not 100% clear in my head yet.

[valdir.marcos]

On this forum, I believe we have programmers of all levels.

Yes and obviously I did not ask help from the newbies for fixing bugs in a near 2,000,000 LOC Lazarus project.
I asked help from people who are capable for it. I know there are many talented and experienced people around here.

I was not talking about newbies either.
But even experienced programmers on Free Pascal, Object Pascal, Delphi, Lazarus, etc may have ZERO experience on handling MANTIS tickets,  BUILDING LAZARUS from its sources and programming for CROSS-PLATFORM (or MULTI-PLATFORM).

Do Mantis tickets can be sorted (and searched) for hardness of solution? For example, "01" for "very easy to solve" through "10" to "very difficult to solve".
This would help new contributtors to choose tickets according to their experience.

No, for 2 reasons:
1. The hardness depends on the person's skills. Someone is good with parsers, someone with graphics, someone with GTK2 widgetset code etc.
2. To determine the hardness of a particular problem one must dive into the code and analyze it. At that point he would already be half-way fixing the problem.
So, in practice _you_ are the person who must analyze the bugs you want to fix. Understood?

Yes, I understand.
Sorry to ask, but here we work on a different infra from Mantis.

I believe many people here can and would like to contibute, but hey do not know how to do it.
So they try to contribute opening tickets on Mantis.

Yes I know but as I explained we have plenty of tickets but too few patches.
To be honest, some of the tickets are not very good and they must be resolved as "Unable to reproduce" or "No change required".
Handling those poor tickets eats the developers' capacity which could be used for more usefull things.

So, the solution would be to close all those insufficient tickets with "Unable to reproduce" until the user reopen it with more information and sources examples to be tracked down.

On the main page of http://lazarus.freepascal.org/ can we have a box similar to "Recent Forum Posts" that shows "Recent Opened/Changed Tickets"?
Or at least, a box similar to "Community" called maybe "Help Development" that shows links like the ones we are posting on this thread? We could put "Recent Opened/Changed Tickets" as on of those links.

Why? Do you mean you cannot fix bugs in Lazarus code unless you have a link for them on the main web page? Nonsense!
Either dive into the code and fix a bug, or then don't do it. There is no need for this empty nonsense.

The reason is the same why you have "Recent Forum Posts" section: call people attention for helping.
Your ANGER and BAD HUMOR will not attract experienced developers to help. Publicity will.

Does Mantis has any kind of tool for voting? If so, this would clarify what tickets are more needed by community.

Yes. Select a bug you want to get fixed, fix it, attach a patch to the bug report and the fix will be included in the next release. The community will be happy.
But if you only want to vote what _other_ people should do then please stop this nonsense.

[/quote]

When you say that voting system is useless, you are saying  that community opinion does not matter.
See one example of voting system on another open source project:
http://tracker.firebirdsql.org/browse/CORE-2530
http://tracker.firebirdsql.org/browse/CORE-2848

The voting system and watchers amount do not have the force of law (obligation), but they help core developers to know the direction to follow.

Try to think out of the box. New ideas are not always bad ones:
http://en.wikipedia.org/wiki/Brainstorming

I think that need, publicity and good will should attract volunteers. But you do not need to agree with me.

[BigChimp]

Interesting post but don't you think it is a bit revealing that a post asking for help on fixing bugs has lead to many replies discussing possible procedures but only 1 patch?

Right now, I think letting people get on with fixing bugs is more important than spending time on changing infrastructure (site etc) in the hope that that will give more attention.

To put it bluntly: Valdir.marcos,  have you already found bugs you can help fix?

[BigChimp]

I can't seem to login to Mantis, don't know why.
So I'll attach here a patch for issue 26258 (Object Inspector expand/contract glyph drawn too low), since this was simple enough that even I could figure out what needed changing in objectinspector.pp.

Thanks, Howard, attached it to the bugtracker item.

[valdir.marcos]

Interesting post but don't you think it is a bit revealing that a post asking for help on fixing bugs has lead to many replies discussing possible procedures but only 1 patch?

I would say few people discussing and only few replies.

Right now, I think letting people get on with fixing bugs is more important than spending time on changing infrastructure (site etc) in the hope that that will give more attention.

I do not agree with you since there are many more new tickets than people to fix them, but I respect your opinion.

To put it bluntly: Valdir.marcos,  have you already found bugs you can help fix?

Not yet. I came from Turbo Pascal / Delphi and so far,  I have stepped to few bugs that were all easily circumvented.
Besides, free and open source Lazarus new releases and new sub-releases are so fast that I, particularly, do not understand why people complain so much about bugs in Lazarus.
I used to complain about bugs in paid Delphi and paid Interbase for years and those bugs were never fixed or had taken years to be dirtly solved. On the contrary, new versions of Delphi (since 7, the best Delphi) always brought more bugs than the previus one.
In terms of solving bugs, Lazarus is the paradise to me.

Since I have moved from Delphi to Lazarus, I am trying to collaborate on two specific needs that I have: Widgetset Enlightenment (E17, E18 and E19) and FortesReport.
They are big and complex projects that take a long time to be studied and patched.
Enlightenment has the problem of changing itself too fast and FortesReport has the graphical challenge.

[BigChimp]

Right now, I think letting people get on with fixing bugs is more important than spending time on changing infrastructure (site etc) in the hope that that will give more attention.

I do not agree with you since there are many more new tickets than people to fix them, but I respect your opinion.

That is IMO EXACTLY why we shouldn't be discussing improving infrastructural things but fixing bugs.
Juha has asked for help, people are reading this thread.

I do understand how you feel but people with experience in this project have had the same kind of discussion over and over again (as Juha indicates) without more bugs getting fixed.
If you want to involve more people, please feel free to set up a voting system, post on blogs, other forums etc.

To put it bluntly: Valdir.marcos,  have you already found bugs you can help fix?

Not yet.

Thanks for confirming what I thought.

[valdir.marcos]

That is IMO EXACTLY why we shouldn't be discussing improving infrastructural things but fixing bugs.
Juha has asked for help, people are reading this thread.

I do understand how you feel but people with experience in this project have had the same kind of discussion over and over again (as Juha indicates) without more bugs getting fixed.

@JuhaManninen and @BigChimp
Have you ever asked WHY or WHY NOT more people getting involved helping fixing bugs via patches?
In Brazil, we have popular saying that if you want a different result, than first you need a different approuch.

If you want to involve more people, please feel free to set up a voting system, post on blogs, other forums etc.

It takes time to see results, but I will try something different from what you are doing. Since what you are doing is not working.
Different examples on the same need:
http://blog.documentfoundation.org/2014/04/24/get-ready-for-libreoffice-4-3-bug-hunting-session/
https://groups.drupal.org/node/440868
https://groups.drupal.org/core/updates

Thanks for confirming what I thought.

Thanks for reading everything I wrote and not just the part that interested to you.

[Mike.Cornflake]

I've been spending this afternoon running through several items in Mantis.  My impression is that what is need more than anything is testers, and anyone can do that.  Some of those issues were reported under 0.9.X and have since been resolved - the issues have just been sitting there awaiting feedback...
I'm testing win32 & GTK2 issues.  I don't have my Linux virtualbox with me, so I've swiped all the GTK2 dlls from GIMP, placed them in a single folder which I've added to my %PATH%.  That seems to be working well for GTK2 testing.
And more than a fair amount of those issues are missing simple test cases.  I've been adding these where I've found them missing.  Again, there's nothing complex required for the test cases.

[Edson]

I was not talking about newbies either.
But even experienced programmers on Free Pascal, Object Pascal, Delphi, Lazarus, etc may have ZERO experience on handling MANTIS tickets,  BUILDING LAZARUS from its sources and programming for CROSS-PLATFORM (or MULTI-PLATFORM).

It's true. I can write a compiler on assembler, but for me, Mantis is an insect,  Lazarus Snapshots is a picture of Lazarus, and Trunk is part of a tree  .

I really want to solve bugs, but I always have problem when enter to Mantis (it confused me). Moreover my Internet conection is slow, and I have problems installing new programs.

IMHO, any help for make the process easier would be good.

[JuhaManninen]

So I'll attach here a patch for issue 26258 (Object Inspector expand/contract glyph drawn too low), since this was simple enough that even I could figure out what needed changing in objectinspector.pp.

Thanks, that made a big difference visually.
I was afraid it would brake other widgetsets which were OK earlier, but for some reason it did not. GTK2 and QT are still good and now Windows is fixed.