Re: [Xenomai-core] Bug tracker.
Heikki Lindholm wrote: Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: There's the if. What I've seen on sourceforge is that often times bugs that are reported on the ml don't appear in the tracker and vice versa, although the tracker can probably be configured to forward reports to ml, or? Who will type the ml-only reports to the tracker? Btw. would you only allow developers to file bugs into the tracker? I would use it as a one line answer to bug reports on the mailing list... I would prefer users to always post on the mailing list first, and if it looks like a real bug, a developer would ask the user to fill a bug report. That might work. As a case study of something to avoid: I know at least Ok. Have a look and tell me: https://gna.org/bugs/?func=additemgroup=xenomai -- Gilles Chanteperdrix.
Re: [Xenomai-core] Bug tracker.
Heikki Lindholm wrote: Looks good, doesn't place too much burden on the user. One might consider adding details of the hardware platform used (CPU/chipset/etc) or similar, because that isn't necessarily obvious from the configs. Done, thanks. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Bug tracker.
Heikki Lindholm wrote: Btw. Do you think the Task/Patch/Tech Support Managers are worth using? If not, can the unused(/-ful) ones be disabled from the site? We will wait for the web site to sort this out. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Bug tracker.
Gilles Chanteperdrix kirjoitti: Hi, GNA offers a bug tracking system which is undoubtely a useful tool for lots of projects. What about using it for the Xenomai project ? I'm not stronly opposing, but in my opinion it causes information to scatter in contrast to the ml. There'll be bug reports on the ml regardless of having or not having a bug tracking system in function. It's more difficult to follow/search two places than one. And this project isn't the size of openoffice or debian, so maybe the ml doesn't get cluttered by incoming bug reports. And finally, many bug reports already contain a reasonable fix and their tracking summarizes to Applied. There are benefits, too, of course, like forcing a good format for a report. -- Heikki Lindholm
Re: [Xenomai-core] Bug tracker.
I'm not stronly opposing, but in my opinion it causes information to scatter in contrast to the ml. There'll be bug reports on the ml regardless of having or not having a bug tracking system in function. It's more difficult to follow/search two places than one. And this project isn't the size of openoffice or debian, so maybe the ml doesn't get cluttered by incoming bug reports. And finally, many bug reports already contain a reasonable fix and their tracking summarizes to Applied. There are benefits, too, of course, like forcing a good format for a report. One point in favor of the use of a tracker like that of Gforge or GNA, is that it assigns a unique number to every bug / wish, which could then be easily referenced in Changelogs, CVS/SVN commits, etc. It is easier to track bugs and have an history (when that bug has been reported? when has it been fixed? etc. which is not always clear from a ML). I see it as complementary to the ML. (my 2-yen contribution) -- Romain Lenglet
Re: [Xenomai-core] Bug tracker.
Heikki Lindholm wrote: Gilles Chanteperdrix kirjoitti: Hi, GNA offers a bug tracking system which is undoubtely a useful tool for lots of projects. What about using it for the Xenomai project ? I'm not stronly opposing, but in my opinion it causes information to scatter in contrast to the ml. There'll be bug reports on the ml regardless of having or not having a bug tracking system in function. I do not see it as a substitute for the mailing list. Of course there would still be posts on the mailing list, but it provides a standardized answer to bug reports on the mailing lists; instead of answering please send me your .xeno_config, your .config, a small example exhibiting the behaviour that you think is bad, please look at the mailing list archives, do you have the bug with the latest revision ? over and over again, we would answer please read instructions at http:// and fill a bug report. The bug data get naturally attached to it in the tracker. Another reason to track bugs is simply, well, to avoid forgetting them. It's more difficult to follow/search two places than one. If for every real bug reported on the mailing list, there is a entry on the tracker ; there is only one place to search : the tracker, because it is a database, and much easier to search than mailing list archives, provided of course we add the important fields to the submission form. And this project isn't the size of openoffice or debian, so maybe the ml doesn't get cluttered by incoming bug reports. Bug reports and FAQs do represent the vast majority of RTAI user mailing list traffic for example. Answering these is time consuming, so since our ressources are limited, any productivity tool is a good idea. If the bug tracker turns out to be time consuming, we will stop using it, but how do we know if we do not try ? And finally, many bug reports already contain a reasonable fix and their tracking summarizes to Applied. There are benefits, too, of course, like forcing a good format for a report. My perception is that bug reports on the mailing list almost never contain a fix, and even worse, people naturally tend to avoid giving you all the elements that would allow to solve the bug, so you have to ask the same questions over and over again. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Bug tracker.
Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: Gilles Chanteperdrix kirjoitti: Hi, GNA offers a bug tracking system which is undoubtely a useful tool for lots of projects. What about using it for the Xenomai project ? It's more difficult to follow/search two places than one. If for every real bug reported on the mailing list, there is a entry on the tracker ; there is only one place to search : the tracker, because it is a database, and much easier to search than mailing list archives, provided of course we add the important fields to the submission form. There's the if. What I've seen on sourceforge is that often times bugs that are reported on the ml don't appear in the tracker and vice versa, although the tracker can probably be configured to forward reports to ml, or? Who will type the ml-only reports to the tracker? Btw. would you only allow developers to file bugs into the tracker? And this project isn't the size of openoffice or debian, so maybe the ml doesn't get cluttered by incoming bug reports. Bug reports and FAQs do represent the vast majority of RTAI user mailing list traffic for example. Answering these is time consuming, so since our ressources are limited, any productivity tool is a good idea. If the bug tracker turns out to be time consuming, we will stop using it, but how do we know if we do not try ? As I said I'm not strongly opposing. Go ahead and give it a spin - not too difficult to back out from that. Although, on the USER side, I've never preferred a bts (login req/learn to use/etc) to ml (e-mail client). all the elements that would allow to solve the bug, so you have to ask the same questions over and over again. Isn't this what most of life is about anyway? :) -- Heikki Lindholm
Re: [Xenomai-core] Bug tracker.
Heikki Lindholm wrote: There's the if. What I've seen on sourceforge is that often times bugs that are reported on the ml don't appear in the tracker and vice versa, although the tracker can probably be configured to forward reports to ml, or? Who will type the ml-only reports to the tracker? Btw. would you only allow developers to file bugs into the tracker? I would use it as a one line answer to bug reports on the mailing list... I would prefer users to always post on the mailing list first, and if it looks like a real bug, a developer would ask the user to fill a bug report. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Bug tracker.
Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: There's the if. What I've seen on sourceforge is that often times bugs that are reported on the ml don't appear in the tracker and vice versa, although the tracker can probably be configured to forward reports to ml, or? Who will type the ml-only reports to the tracker? Btw. would you only allow developers to file bugs into the tracker? I would use it as a one line answer to bug reports on the mailing list... I would prefer users to always post on the mailing list first, and if it looks like a real bug, a developer would ask the user to fill a bug report. That might work. As a case study of something to avoid: I know at least three persistent bugs in the firefox browser I'm using and I thought about reporting them, ending up in http://www.mozilla.org/support/firefox/bugs which in turn leads to many worksome steps and eventually to http://www.mozilla.org/quality/bug-writing-guidelines.html Blech! It seems easier to write a firefox from ground up than giving them a bug report --- and thus my observations stay unreported. Moral of the story: keep it simple! -- Heikki Lindholm
