My experience with current'ish git
Hi Slava, all, I am happy to see that your development efforts on MC did not remain just good intentions. Now you face a har part: how to make your project successful. I will try to help, at least by reporting bugs. Currently, I have 5 bugs reported total. One is already fixed: #411make loops, rerunning configure ad infinitum and I can confirm it works now. Thanks! This one is marked as a dup: #1386 editor: F7 search does not remember last search string across editing sessions These are open: #414Regression: shell patterns in copy dialog do not work #1384 Whitespace highlighting should be optional #1385 File search dialog is more difficult to use compared to 4.6.1 A word on the project in general. Any open-source project requires not only technical skill, but also some social skills. Projects fail when they are closed-minded, where developers assume I'm the boss - you are the idiot mentality. It is not always easy to remember that users come to you with their complains because they are using your software, and something is not working right. Indirectly, they bring you an important thing: they do debugging for you in various scenarios you personally never use. Caring for users' bug reports and bugs in bugzilla is not a very inspiring work, but if you do it regularly, you are taking an invisible advantage of the work users already did before they wrote an email/bug report: *they diagnosed a problem for you*. You do not need to do it by now. And also you show users that their efforts are not wasted. It's very frustrating to spend days creating a bug report for a project, only to see it staying open for months/years, with not a single comment from developers... Don't let your users feel this way. If you can't fix it right away, at least let reporter know what you think: It is not a bug (explain why), This is easy to fix, This is hard to fix etc. Sometimes you can write in a few lines how this can be fixed (after all, you know the source better than the reporter, and may see what the solution will be), and hint that it will go faster if someone can try to make a patch and user will do it for you! ;) ;) Yes, some users are newbies, and some are real idiots who can abuse your attention. But not all of them. Filter out idiots, direct newbies to Google/Wiki/other info sources, work with the rest. If you'll do it, you'll notice that some of your users will start helping you more. They will send patches, not just bug reports. Don't know how useful above mumblings are... those are just my thoughts about ways to be a successful project. -- vda ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: My experience with current'ish git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Denys Vlasenko wrote: I will try to help, at least by reporting bugs. Currently, I have 5 bugs reported total. One is already fixed: #1386 editor: F7 search does not remember last search string across editing sessions We want to remove all static variables (file-scope visibility). May be, this helps in future with running many editors at one time. New behavior of F7-search it's a side effect. I think, need to show latest item from field history... These are open: #414 Regression: shell patterns in copy dialog do not work It's easy to fix and will fidex in near time. #1384 Whitespace highlighting should be optional Fedora package of mc have patch for it... not hard too. #1385 File search dialog is more difficult to use compared to 4.6.1 Need to discuss with andrew_b :) Any open-source project requires not only technical skill, but also some social skills. Projects fail when they are closed-minded, where developers assume I'm the boss - you are the idiot mentality. We also think this. Please, don't think that we no much write comments in trac because of the arrogance. No-no, this is because of our poor English (this right to me). :( Indirectly, they bring you an important thing: they do debugging for you in various scenarios you personally never use. Of course. And IMHO it's very important. Caring for users' bug reports and bugs in bugzilla is not a very inspiring work, but if you do it regularly, you are taking an invisible advantage of the work users already did before they wrote an email/bug report: *they diagnosed a problem for you*. You do not need to do it by now. At now, too much open bugs and feature request. Some bugs very old, some bugs we have added themselves... Very hard to balance before priority of bugs. For one man bug very critical, for others - not important... And also you show users that their efforts are not wasted. It's very frustrating to spend days creating a bug report for a project, only to see it staying open for months/years, with not a single comment from developers... Don't let your users feel this way. I know it situation :) My patch for GitPlugin of trac (http://trac-hacks.org/attachment/ticket/5310/python24.2.patch) awaiting now too. I have a short time to waiting, but constantly look for activity in the ticket. :) Relative to us, is this mean, that we need to write comment in any case into new bugreport? Don't know how useful above mumblings are... those are just my thoughts about ways to be a successful project. Denys, big thanks for you help. Our work (development of mc) looks not good from other side, I'm understand it :(. Because lot of questions we have discussed at online in jabber-room (usually, Russian-speak jabber-room). Link to room you may found at http://www.midnight-commander.org/wiki/ru/WikiStart#%D0%9E%D0%BD%D0%BB%D0%B0%D0%B9%D0%BD-%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8 This is the reason why mc develops so quickly ... and the reason that the development looks as 'close' from other side :( WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFKSNu+b3oGR6aVLpoRAuDvAJ93SqcaVNoKwiLFK1rhg0esodyNhQCfedfd Cz3dRMKKMfMnR3ERlTls00A= =pv6D -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: My experience with current'ish git
On Monday 29 June 2009 17:20, Slava Zanko wrote: Denys Vlasenko wrote: Caring for users' bug reports and bugs in bugzilla is not a very inspiring work, but if you do it regularly, you are taking an invisible advantage of the work users already did before they wrote an email/bug report: *they diagnosed a problem for you*. You do not need to do it by now. At now, too much open bugs and feature request. Some bugs very old, some bugs we have added themselves... Very hard to balance before priority of bugs. For one man bug very critical, for others - not important... I usually prioritize so that I fix easy bugs, ask for more info in bugs with unclear description, explain what user did wrong in non-bugs, let user know when I can't reproduce a bug. When no more info comes from user for these cases, I close the bug in a month or so. This way, only harder bug remain in the bugzilla. So it stays manageable. It's ok when you have many bugs. It may take some time before you will be able to fix bugs faster than they appear. For some complex projects like compiler or web browser, it's nearly impossible :) What is wrong is when a project stops treating bugzilla as a TODO list, stops trying to shrink it and starts to see it as an endless supply of user's whining. Relative to us, is this mean, that we need to write comment in any case into new bugreport? Yes, this is useful. Do not leave a fresh bug with no comments for months. Don't know how useful above mumblings are... those are just my t houghts about ways to be a successful project. Denys, big thanks for you help. Our work (development of mc) looks not good from other side, I'm understand it :(. I do not imply that you are not doing maintainer's work good enough. So far it looks ok. For example, search dialog now matches old version regarding keyboard navigation. Someone fixed a bug I whined about! Thanks! :) -- vda ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
