Thread: [Freemind-developer] Handling trackers
A premier mind-mapping software written in Java
Brought to you by:
christianfoltin,
danielpolansky
From: Dan P. <dan...@gm...> - 2007-07-12 18:06:22
|
Hi, before some time there have been some questions on when to close solved issues like bugs and feature requests. A proposal of an answer created by me can be found at: http://freemind.sourceforge.net/wiki/index.php/Handling_trackers The wording goes: When a feature request or a bug (both an *issue*) is solved in CVS, it shall be closed not immediately; it shall be closed only after a final release containing the solution is out. A note that the issue has been solved in CVS, including in which beta or RC version it has been solved, can be posted into the issue though. Please let us discuss the proposal ideally at the talk page of that wiki page, or here if you prefer. I do not hold the proposal binding for anyone; it is there more to help to gain common understanding of what the options are and what their pros and cons are, or to see that there is no disagreement about the preferable option. Best regards, Dan |
From: Dimitry P. <dpo...@gm...> - 2007-07-13 22:37:16
|
Hi, I propose using of state "Pending" for all issues closed in CVS. Currently all Pending issues are automatically closed after 60 days, but this setting can be changed. Dimitry |
From: Dan P. <dan...@gm...> - 2007-07-14 10:19:06
|
Hi, please see my answer at http://freemind.sourceforge.net/wiki/index.php/Talk:Handling_trackers --Dan |
From: Dimitry P. <dpo...@gm...> - 2007-07-14 10:42:10
|
Hi, please see my answer at http://freemind.sourceforge.net/wiki/index.php/Talk:Handling_trackers --Dimitry Dan Polansky schrieb: > Hi, please see my answer at > > http://freemind.sourceforge.net/wiki/index.php/Talk:Handling_trackers > > --Dan |
From: Dan P. <dan...@gm...> - 2007-07-14 10:50:09
|
Ditto. |
From: Dimitry P. <dpo...@gm...> - 2007-07-14 11:07:07
|
We could also use status "closed" with resolution "fixed" which should be changed to "accepted" after when the release is published. --DimitriPolivaev 04:06, 14 Jul 2007 (PDT) |
From: Dan P. <dan...@gm...> - 2007-07-14 11:21:06
|
We could also use status "closed" with resolution "fixed" which should be changed to "accepted" after when the release is published. --DimitriPolivaev<http://freemind.sourceforge.net/wiki/index.php?title=User:DimitriPolivaev&action=edit>04:06, 14 Jul 2007 (PDT) That solves the con 1. What about the con 3? Anyway, setting to closed issues that are in some beta version, not with the last stable version, seems fine to me. Whoever downloaded one beta is probably willing to download another beta or RC. But these issues would be set to solved only after another beta or RC is published. All right? So the only items now in discussion are bugs and requests in the last stable version that have been solved in CVS. What about them? Setting them to closed would still cause that people would not see them in the tracker. --Danielpolansky<http://freemind.sourceforge.net/wiki/index.php/User:Danielpolansky>04:20, 14 Jul 2007 (PDT) |
From: Dimitry P. <dpo...@gm...> - 2007-07-14 11:48:15
|
> So the only items now in discussion are bugs and requests in the last > stable version that have been solved in CVS. What about them? Setting > them to closed would still cause that people would not see them in > the tracker. --Danielpolansky 04:20, 14 Jul 2007 (PDT) > Why not? Everyone can select an option to see the slosed items too. I think that the expected version with the bug fix should be mentioned in the detail field. If last published version is say 0.9.0 beta 9, but the issue is closed with relution "fixed" and the details informs that the bug fix is done in 0.9.0 beta 10 (11, 12...), there is no way to misunderstanding. The tracker should always reflect the real situation, so letting the issue "open" althaugh it has been fixed is less nice for me. --DimitriPolivaev 04:46, 14 Jul 2007 (PDT) |
From: Dan P. <dan...@gm...> - 2007-07-14 12:28:16
|
Dimitry, I do not understand your "why not?" I have been trying to explain why not all along. You seem a bit selfish to me, not for the first time. The important thing for you is that you, a developer, like the solution; who cares about new users coming to a tracker and trying to figure out how to work with it. You liked it, so what's the problem. Oh Oh. --Dan On 7/14/07, Dimitry Polivaev <dpo...@gm...> wrote: > > > So the only items now in discussion are bugs and requests in the last > > stable version that have been solved in CVS. What about them? Setting > > them to closed would still cause that people would not see them in > > the tracker. --Danielpolansky 04:20, 14 Jul 2007 (PDT) > > > Why not? Everyone can select an option to see the slosed items too. I > think that the expected version with the bug fix should be mentioned in > the detail field. If last published version is say 0.9.0 beta 9, but the > issue is closed with relution "fixed" and the details informs that the > bug fix is done in 0.9.0 beta 10 (11, 12...), there is no way to > misunderstanding. The tracker should always reflect the real situation, > so letting the issue "open" althaugh it has been fixed is less nice for > me. > > --DimitriPolivaev 04:46, 14 Jul 2007 (PDT) > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > |
From: Dimitry P. <dpo...@gm...> - 2007-07-14 13:01:09
|
The important thing is that we have a solution which is better than nothing. If one had a better one we could use it too, but currently we do not have any solution and any policy. Leaving items open for an undefined period of time is not a way which sounds like a defined and understood process, is it? Best regards, Dimitry. |
From: Dan P. <dan...@gm...> - 2007-07-15 15:56:53
|
Leaving items open until a solution is provided to the customer IS A DEFINED PROCESS, which is not to say it is a good one. Did you think of other options besides the one you have suggested? What about using other fields for filtering, like Category or Group? Both are currently used for other purposes, but that could be changed, depending what you consider your priority when filtering. There surely are some other solutions, possibly worse in some regard. It is just that I did not hear any other so far. --Dan On 7/14/07, Dimitry Polivaev <dpo...@gm...> wrote: > > The important thing is that we have a solution which is better than > nothing. If one had a better one we could use it too, but currently we > do not have any solution and any policy. > > Leaving items open for an undefined period of time is not a way which > sounds like a defined and understood process, is it? > > Best regards, Dimitry. > |
From: Eric L. <Eric@Lavar.de> - 2007-07-25 20:34:01
|
Hi, still cleaning up my inbox after my holiday. We currently don't really use groups. I had created two of them aligned with FreeMind versions while I was doing some cleanup with the idea of assigning the group to a tracker entry means "this bug can still be found in version X". We could also create groups called "Solved after X" meaning "After release of version X, this bug has been fixed (in CVS or Subversion, whatever), it should be gone in the next version." i.e. a bug should either be in group "FreeMind X" i.e. it's in the current version and hasn't been fixed yet, or in group "Solved after X", and we know it's fixed. Bugs still open with no groups and in other groups can be tested against the latest version by less knowledgeable guys like me and put in the group "FreeMind X" for developers to solve. Pros: 1- users see by default all bugs they might find in the current version, even if they're fixed in CVS/Subversion, and we avoid duplicates. 2- developers can filter on group "FreeMind X" in order to see the bug they should concentrate upon. 3- before release, testers can filter on "Solved after X" to check that the bugs are really gone. 4- testers can also filter on "FreeMind Y" (Y<X) and check if the bug still exists in version X, close it if not, change group to "FreeMind X" if yes. Cons: 1- need to create 2 new groups for each release, and groups can't be deleted. We could alleviate this by creating groups only for stable releases; actually it's not a bad idea, I don't think it would hurt much anybody. 2- bugs closed because fixed in a released beta version are not seen anymore by users using a stable version. To fix this, we could decide to close only after release of stable versions. I personally think that it would be too messy. We should close after each release, and alleviate by releasing more often stable versions... Does it make sense? Eric Dan Polansky wrote: > Leaving items open until a solution is provided to the customer IS A > DEFINED PROCESS, which is not to say it is a good one. Did you think of > other options besides the one you have suggested? What about using other > fields for filtering, like Category or Group? Both are currently used > for other purposes, but that could be changed, depending what you > consider your priority when filtering. There surely are some other > solutions, possibly worse in some regard. It is just that I did not hear > any other so far. --Dan > > On 7/14/07, *Dimitry Polivaev* <dpo...@gm... > <mailto:dpo...@gm...>> wrote: > > The important thing is that we have a solution which is better than > nothing. If one had a better one we could use it too, but currently we > do not have any solution and any policy. > > Leaving items open for an undefined period of time is not a way which > sounds like a defined and understood process, is it? > > Best regards, Dimitry. -- Gewalt ist die letzte Zuflucht der Inkompetenz. Violence is the Last Resort of the Incompetent. Gwalt jest ostatnem schronieniem niekompetencji. La violence est le dernier refuge de l'incompetence. ~ Isaac Asimov |