Bugs item #2004979, was opened at 2008-06-28 06:28 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None
Status: Closed
Resolution: Fixed Priority: 5 Private: No Submitted By: Frank Barknecht (fbar) Assigned to: Hans-Christoph Steiner (eighthave) Summary: hid defaults to debugging (flood of "hid_get_events")
Initial Comment: It seems, [hid] still defaults to have debugging on which results in a flood of "hid_get_events" messages to the console, when polling is on, unless one sends [debug 0( to [hid]
Also see http://lists.puredata.info/pipermail/pd-list/2007-01/046275.html
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-28 13:14
Message: Logged In: YES user_id=27104 Originator: NO
One Pd-extended 0.40.3 is released, I'll merge all of the changes into trunk (this is a fairly standard way to deal with release branches). In the meantime, I recommend you use the release version.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar) Date: 2008-06-28 08:05
Message: Logged In: YES user_id=569446 Originator: YES
I'm using the "trunk", not a branch. I did a "cd trunk/externals; make hid" as told in hid's README. It still starts with debugging then.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-28 06:58
Message: Logged In: YES user_id=27104 Originator: NO
I just fixed this and some other bugs and annoyances with [hid]. This should be fixed by this commit, let me know if it is not:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/v...
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979...
Hallo, SourceForge.net hat gesagt: // SourceForge.net wrote:
Submitted By: Frank Barknecht (fbar) Assigned to: Hans-Christoph Steiner (eighthave) Summary: hid defaults to debugging (flood of "hid_get_events")
Initial Comment: It seems, [hid] still defaults to have debugging on which results in a flood of "hid_get_events" messages to the console, when polling is on, unless one sends [debug 0( to [hid]
Also see http://lists.puredata.info/pipermail/pd-list/2007-01/046275.html
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-28 13:14
Message: Logged In: YES user_id=27104 Originator: NO
One Pd-extended 0.40.3 is released, I'll merge all of the changes into trunk (this is a fairly standard way to deal with release branches).
A fairly standard way to deal with bugs fixes is to include them in "trunk". I don't think, one can expect users to follow every branch. In fact, I don't check out the branches at all, because there are so many of them and I don't want to search every branch for a bug fix.
Ciao
On Jun 29, 2008, at 10:54 AM, Frank Barknecht wrote:
Hallo, SourceForge.net hat gesagt: // SourceForge.net wrote:
Submitted By: Frank Barknecht (fbar) Assigned to: Hans-Christoph Steiner (eighthave) Summary: hid defaults to debugging (flood of "hid_get_events")
Initial Comment: It seems, [hid] still defaults to have debugging on which results in a flood of "hid_get_events" messages to the console, when polling is on, unless one sends [debug 0( to [hid]
Also see http://lists.puredata.info/pipermail/pd-list/ 2007-01/046275.html
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-06-28 13:14
Message: Logged In: YES user_id=27104 Originator: NO
One Pd-extended 0.40.3 is released, I'll merge all of the changes into trunk (this is a fairly standard way to deal with release branches).
A fairly standard way to deal with bugs fixes is to include them in "trunk". I don't think, one can expect users to follow every branch. In fact, I don't check out the branches at all, because there are so many of them and I don't want to search every branch for a bug fix.
They will be included in trunk. We would never get anything done if we had to maintain trunk in a releasable state.
Come on, please don't give me a hard time about trunk not being perfectly working. I have enough to do with getting a good release out.
.hc
Ciao
Frank Barknecht _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 29, 2008, at 10:54 AM, Frank Barknecht wrote:
A fairly standard way to deal with bugs fixes is to include them in "trunk". I don't think, one can expect users to follow every branch. In fact, I don't check out the branches at all, because there are so many of them and I don't want to search every branch for a bug fix.
They will be included in trunk. We would never get anything done if we had to maintain trunk in a releasable state.
Come on, please don't give me a hard time about trunk not being perfectly working. I have enough to do with getting a good release out.
I didn't want to give you a hard time, sorry if I sounded like that. It's a minor bug and can be fixed in the trunk in whatever time you prefer.
Though there is a larger question lurking here: What should trunk be and how should bug reporters check, if a bug may be already fixed? Or in short: What is the reference repository: some branches or the trunk? To me, trunk was that reference version (and for the record: to me it is for bug reports regarding my stuff, unless the reports are branch-specific). But if you regard pd-extended branches as reference for your externals, I'll take note of that for future reports.
Ciao
On Jun 29, 2008, at 2:10 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 29, 2008, at 10:54 AM, Frank Barknecht wrote:
A fairly standard way to deal with bugs fixes is to include them in "trunk". I don't think, one can expect users to follow every branch. In fact, I don't check out the branches at all, because there are so many of them and I don't want to search every branch for a bug fix.
They will be included in trunk. We would never get anything done if we had to maintain trunk in a releasable state.
Come on, please don't give me a hard time about trunk not being perfectly working. I have enough to do with getting a good release out.
I didn't want to give you a hard time, sorry if I sounded like that. It's a minor bug and can be fixed in the trunk in whatever time you prefer.
Though there is a larger question lurking here: What should trunk be and how should bug reporters check, if a bug may be already fixed? Or in short: What is the reference repository: some branches or the trunk? To me, trunk was that reference version (and for the record: to me it is for bug reports regarding my stuff, unless the reports are branch-specific). But if you regard pd-extended branches as reference for your externals, I'll take note of that for future reports.
Trunk is the reference, but during a release cycle, I am following the practice laid out by a number of other projects of focusing all my work on the release branch. Then once the release is done, I'll merge those changes into trunk. Otherwise, it is a lot of work maintaining changes in two branches at the same time.
.hc
Ciao
Frank Barknecht _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
kill your television
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 29, 2008, at 2:10 PM, Frank Barknecht wrote:
Though there is a larger question lurking here: What should trunk be and how should bug reporters check, if a bug may be already fixed? Or in short: What is the reference repository: some branches or the trunk? To me, trunk was that reference version (and for the record: to me it is for bug reports regarding my stuff, unless the reports are branch-specific). But if you regard pd-extended branches as reference for your externals, I'll take note of that for future reports.
Trunk is the reference, but during a release cycle, I am following the practice laid out by a number of other projects of focusing all my work on the release branch. Then once the release is done, I'll merge those changes into trunk. Otherwise, it is a lot of work maintaining changes in two branches at the same time.
That's perfectly fine. Maybe I should rephrase the question to: When to close bugs?
If I encounter a bug, I first update my checkout to the latest version of the trunk, recompile, and if the bug still is there, I go to the bug report page and look, if there is an open bug report regarding it. Mabye I'll also search the mailing list. In this case I didn't find a bug report, and in the archive I saw you asking for a report. So I sat down and wrote one. It was closed some minutes later because there is a branch that doesn't have the bug anymore.
Now someone else may come along, do the same thing as I did, but now there is no open bug report anymore so she may go through the same procedure again.
Anyway, no need to further pursue this issue in this petty case, but in general I'd prefer if bug reports would stay open until they are fixed in the main branch i.e. the trunk to avoid duplicate reports.
Ciao
On Jun 29, 2008, at 2:53 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 29, 2008, at 2:10 PM, Frank Barknecht wrote:
Though there is a larger question lurking here: What should trunk be and how should bug reporters check, if a bug may be already fixed? Or in short: What is the reference repository: some branches or the trunk? To me, trunk was that reference version (and for the record: to me it is for bug reports regarding my stuff, unless the reports are branch-specific). But if you regard pd-extended branches as reference for your externals, I'll take note of that for future reports.
Trunk is the reference, but during a release cycle, I am following the practice laid out by a number of other projects of focusing all my work on the release branch. Then once the release is done, I'll merge those changes into trunk. Otherwise, it is a lot of work maintaining changes in two branches at the same time.
That's perfectly fine. Maybe I should rephrase the question to: When to close bugs?
If I encounter a bug, I first update my checkout to the latest version of the trunk, recompile, and if the bug still is there, I go to the bug report page and look, if there is an open bug report regarding it. Mabye I'll also search the mailing list. In this case I didn't find a bug report, and in the archive I saw you asking for a report. So I sat down and wrote one. It was closed some minutes later because there is a branch that doesn't have the bug anymore.
Now someone else may come along, do the same thing as I did, but now there is no open bug report anymore so she may go through the same procedure again.
Anyway, no need to further pursue this issue in this petty case, but in general I'd prefer if bug reports would stay open until they are fixed in the main branch i.e. the trunk to avoid duplicate reports.
Bug reports should be closed when they don't need any more attention. When reporting bugs, ideally people would also search closed reports to see if the issue has ever been reported or if there has been any work or discussion related to this issue. "Closed" should not be a synonym for "Complete". There is a separate pull- down menu for that, with states like "Accepted" for patches and "Fixed" for bugs.
So instead of searching only "Open" status, I encourage everyone to search with "Any" status.
.hc
Ciao
Frank Barknecht _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Bug reports should be closed when they don't need any more attention. When reporting bugs, ideally people would also search closed reports to see if the issue has ever been reported or if there has been any work or discussion related to this issue. "Closed" should not be a synonym for "Complete". There is a separate pull- down menu for that, with states like "Accepted" for patches and "Fixed" for bugs.
A bug that is "Closed" can not be(come) "Fixed" anymore.
Ciao
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Bug reports should be closed when they don't need any more attention. When reporting bugs, ideally people would also search closed reports to see if the issue has ever been reported or if there has been any work or discussion related to this issue. "Closed" should not be a synonym for "Complete". There is a separate pull- down menu for that, with states like "Accepted" for patches and "Fixed" for bugs.
A bug that is "Closed" can not be(come) "Fixed" anymore.
hmm, technically it can (on the sf tracker); but i guess you are rather referring to the social aspects of it.
i agree with hans, that people reporting bugs should also look whether there bug has already been reported, and eventually been closed (and find out why the issue has been closed)
of course this does not solve the problem of two branches containing different bugfixes.
i guess it would be good practice to add a note when someone is closing an ticket when a bug has been fixed only in a certain branch.
furthermore, if release cycles were shorter (PdX-0.40 is now pending for more than one month) the problem would become less noticeable. (but of course there are only so many hours per day...)
finally this is probably a good example why Pd-extended should be split into a lot of small packages with there own release cycles. there is really no need for a [hid]-bugfix to wait for [hexloader] to be fixed in order to get propagated back into the main-trunk.
but then, other meta-packages (e.g. linux-distros like debian) have this problem too, but it is somewhat alleviated by the fact that the debian-maintainers are not necessarily involved in upstream-maintainance (which i think is the main problem here; most other devs but hans would probably have fixed the bug in the main trunk rather than some branch; but he is quite free to do so; i cannot complain that the bugfix is non-existant on the latest-and-greatest CVS head...)
fgamsdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Bug reports should be closed when they don't need any more attention. When reporting bugs, ideally people would also search closed reports to see if the issue has ever been reported or if there has been any work or discussion related to this issue. "Closed" should not be a synonym for "Complete". There is a separate pull- down menu for that, with states like "Accepted" for patches and "Fixed" for bugs.
A bug that is "Closed" can not be(come) "Fixed" anymore.
hmm, technically it can (on the sf tracker); but i guess you are rather referring to the social aspects of it.
Yes. To me, "Closed" means that an issue doesn't need any more work. This can mean that it's tested and fixed, that it won't be fixed, that is is invalid, a duplicate etc. But the main feature of bugs marked "Closed" to me is, that no further work is needed in this issue, and "Open" bugs are bugs that still need one or more Actions to be performed.
The bug in question is fixed in a branch, but what was still left to do was to apply that fix to the trunk. After that the report would be closed. I don't understand what is gained by closing a report when there is still work pending, however minor that may be? (And personally I don't think, a bug fix missing from trunk is that minor, but that's another story.) An open bug report is just a little reminder and it doesn't hurt anyone. At least I hope it doesn't ...
Ciao
On Jul 10, 2008, at 12:56 PM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Bug reports should be closed when they don't need any more attention. When reporting bugs, ideally people would also search closed reports to see if the issue has ever been reported or if there has been any work or discussion related to this issue. "Closed" should not be a synonym for "Complete". There is a separate pull- down menu for that, with states like "Accepted" for patches and "Fixed" for bugs.
A bug that is "Closed" can not be(come) "Fixed" anymore.
hmm, technically it can (on the sf tracker); but i guess you are rather referring to the social aspects of it.
Yes. To me, "Closed" means that an issue doesn't need any more work. This can mean that it's tested and fixed, that it won't be fixed, that is is invalid, a duplicate etc. But the main feature of bugs marked "Closed" to me is, that no further work is needed in this issue, and "Open" bugs are bugs that still need one or more Actions to be performed.
The bug in question is fixed in a branch, but what was still left to do was to apply that fix to the trunk. After that the report would be closed. I don't understand what is gained by closing a report when there is still work pending, however minor that may be? (And personally I don't think, a bug fix missing from trunk is that minor, but that's another story.) An open bug report is just a little reminder and it doesn't hurt anyone. At least I hope it doesn't ...
The "Open", "Pending", and "Closed" states have to do with attention, not the state of the bug. If someone reports a bug, then no dev can reproduce it, I would not say that this bug is fixed. But I do think it is appropriate to set that bug to "Pending" asking for an example patch. If no one is willing to follow up on it, then it'll be closed in two weeks automatically. So that would be "Closed" but definitely not "Fixed".
It is an important distinction in managing all of the bugs. It is the best way I can think of for keeping track of which bug reports need developer attention.
.hc
Ciao
Frank Barknecht _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner wrote:
The "Open", "Pending", and "Closed" states have to do with attention, not the state of the bug. If someone reports a bug, then no dev can
indeed, and thus frank is right when requesting that a bug should not be set to "Closed" when it still needs attention (e.g. merge it back from one branch into the main trunk).
the same goes for patches: if there is a bug-report about bug-#123 and there is also a patch that closes this bug, this does (imo) not qualify to close the bug-report as long as the upstream author has not included the patch yet.
reproduce it, I would not say that this bug is fixed. But I do think it is appropriate to set that bug to "Pending" asking for an example patch. If no one is willing to follow up on it, then it'll be closed in two weeks automatically. So that would be "Closed" but definitely not "Fixed".
right again. the (prelaminary) "resolution" should probably be "works for me" or "invalid".
i think that the correct state of bug#2004979 would be "Open" and "Fixed"
It is an important distinction in managing all of the bugs. It is the best way I can think of for keeping track of which bug reports need developer attention.
and as your bug still needs attention it should be open. but i am repeating myself.
good night, fgmasdr IOhannes
On Jul 11, 2008, at 4:32 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
The "Open", "Pending", and "Closed" states have to do with attention, not the state of the bug. If someone reports a bug, then no dev can
indeed, and thus frank is right when requesting that a bug should not be set to "Closed" when it still needs attention (e.g. merge it back from one branch into the main trunk).
the same goes for patches: if there is a bug-report about bug-#123 and there is also a patch that closes this bug, this does (imo) not qualify to close the bug-report as long as the upstream author has not included the patch yet.
reproduce it, I would not say that this bug is fixed. But I do think it is appropriate to set that bug to "Pending" asking for an example patch. If no one is willing to follow up on it, then it'll be closed in two weeks automatically. So that would be "Closed" but definitely not "Fixed".
right again. the (prelaminary) "resolution" should probably be "works for me" or "invalid".
i think that the correct state of bug#2004979 would be "Open" and "Fixed"
It is an important distinction in managing all of the bugs. It is the best way I can think of for keeping track of which bug reports need developer attention.
and as your bug still needs attention it should be open. but i am repeating myself.
Anyone feel like distilling this thread into a FAQ? It would be good to have it documented so it is clear what practice we are following.
.hc
good night, fgmasdr IOhannes
------------------------------------------------------------------------ ----
All information should be free. - the hacker ethic
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
SourceForge.net