Marcus Denker wrote:
Am 06.08.2004 um 08:45 schrieb Serge Stinckwich:
We already talk offline about the use of a BTS like Mantis
with some
of you. Can we try to make an experiment for example to manage the bugs in the stable 3.7 ? My vision is to have something
like the way
the linux kernel dev work : a very conservative stable
version with a
frozen API and only bug fixes, and an unstable version managed with the BFAV process.
Maybe, we can also have a maintainer for the stable version like Marcelo Tosatti is the Linux kernel 2.4 maintainer. We could have several stable release (3.7.1, 3.7.2, ...) at fixed time,
for example
every two or three months.
Yes, bugfixes for the stable version would be nice. I think we should try that. Of course, we would need somebody who steps forward as a maintainer.
But for mantis: I'd like to move all bugs over, even those from 3.8 and the old ones that are in BFAV.
And from an earlier mail of Marcus':
Some non-public Squeak projects have used Mantis with some success. So we should try to use Mantis for Bug-tracking and BFAV for managing reviews/harvesting only.
I don't really understand this. If we use BFAV for reviews, but not for bugs, what do we review? Only fixes/enhancements? What do we harvest, if not bugfixes?
Or do you propose that Mantis keeps track of bug state? So I submit a bug to the list, BFAV picks it up (as per usual) and I submit a bug report to Mantis? And then when Joe Foo fixes it, he changes the status of the bug report to "feedback" and Doug, when he harvests the fix, changes the status of the report to "fixed" or something?
Ken & Brent wrote BFAV precisely to allow people to post bugs and allow people to track these. If noone reviews bugfixes in BFAV (this is what's irritating you, isn't? Loads of bug reports & bug fixes but noone looking at the fixes?), why would people start tracking bugs in, say, Mantis?
I do think that BFAV needs categories - Squeak-3.6, Squeak-3.7, Squeak-current, BFAV, Network-HTML, etc. Then I could submit a bug report for the Squeak-3.6 image, and the Squeak-3.6 image maintainer could just filter out all the other stuff and see my bug mre easily.
frank
******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************
Am 06.08.2004 um 11:49 schrieb Frank Shearar:
I don't really understand this. If we use BFAV for reviews, but not for bugs, what do we review? Only fixes/enhancements?
We only review fixes. Not bugs. There is e.g. no way that BFAV can anwer questions like:
Are there any severe bugs left that should be fixed for release 3.7? What are the bugs that have been reported with 3.6 and fixed in 3.7?
There are lots of BUG posting that might have seen a fix, or maybe not. I don't know.
Or do you propose that Mantis keeps track of bug state? So I submit a bug to the list, BFAV picks it up (as per usual) and I submit a bug report to Mantis? And then when Joe Foo fixes it, he changes the status of the bug report to "feedback" and Doug, when he harvests the fix, changes the status of the report to "fixed" or something?
People would submit to mantis. Because manits asks for lots of important stuff: version of Squeak, Plattfrom, steps to reproduce. After that the status can be changed, the bug can be assigned to different people, it can be moved to different categories.
Ken & Brent wrote BFAV precisely to allow people to post bugs and allow people to track these. If noone reviews bugfixes in BFAV (this is what's irritating you, isn't? Loads of bug reports & bug fixes but noone looking at the fixes?),
No, the problem is not that nobody looks at the fixes: Nobdy looks at the bug-reports. Bug reports just sit there. I don't know how many bugs there are, if some are important or not, on which system they where reported. I can't seach for bugs, and so on.
why would people start tracking bugs in, say, Mantis?
Usability is important. if you tell people "look at that webpage, there's a list of open bugs. And on that one, fil in the form to report bugs" is somewhat more userfriendly... especially with lots of meta-data to be changed for each bug (assigment to a developer, status, comments...). And this is quite different from the process of harvesting a changeset.
Marcus
Let me add, that with a fully-fledged bug tracking system we could easily do things, that are impossible or hard to do with the current bug fix archive viewer. Some of the things are:
* Reliable registry: Using the subject of an email the BFAV guesses if the email is a new report or an addition to an existing report. This can fail and in the worst case a report gets assigned to an already closed report and so just disappears. * Merging: When two different reports describe the same issue it is hard to merge those just using BFAV. One reporter has to close his report and resend the same report with the same subject line of the other report. * Reopening: Once a report is closed you can't reopen it with BFAV. * Protection: Now everybody can close and approve reports. Even if this happens by accident you can't resolve the situation easily, because you can't reopen a report. * Web Interface: Now you can't just use a browser to search and track reports. * Many things more like packages, versions, severity levels, confirmation, assignment, automatic notifications, ...
Alex
Does anyone already know why we can't we re-open a BFAV bug report? At first I'd assumed that it was a "policy" decision, but based on folks' comments thats not the case. My next guess was that it's because we cannot "rewrite an email". I'm treating the BFAV server side as a black box and so I assume this to be a given. Now I'm wondering if reopening posts is a solvable problem on the client side. I've been experimenting with ways to split and regroup posts from the client side already. Regrouping faces similar problems and potential solutions. In both cases, if we solve the problem on the client side it involves duplicating posts. So if there is something I can invoke on the server side to update a post that would be helpful. Any insights about "why we cann't re-open a BFAV post" would be appreciated. Tom
Alexander Lazareviæ wrote: Let me add, that with a fully-fledged bug tracking system we could easily do things, that are impossible or hard to do with the current bug fix archive viewer. Some of the things are:
Reliable registry: Using the subject of an email the BFAV guesses if the email is a new report or an addition to an existing report. This can fail and in the worst case a report gets assigned to an already closed report and so just disappears. Merging: When two different reports describe the same issue it is hard to merge those just using BFAV. One reporter has to close his report and resend the same report with the same subject line of the other report. Reopening: Once a report is closed you can't reopen it with BFAV. [snip]
I'm not entirely sure I understand what you are getting at, but here are my comments.
Making any change to a group (set of messages with the same title) would of course require sending another message to that group. Reopening the group would require in some way marking this new message in a way that BFAV (at least client and probably both server and client) understand that this action is to be performed.
Basically this could be done by simply adding to the existing protocol. Where we currently have a '[closed]' tag you could add a '[reopen]' tag. Now it's not absolutely essential that the server be modified to support this; you could always search for tags on the client side. However for efficiency reasons it makes sense to repeat processing as few times as possible which is why the server side looks for tags once and only once and sets a bitmask in the message list so that the client has to do less work to make these decisions. In which case if the community desires the ability to reopen groups then I would be quite happy to add the desired functionality to the server side which should only take a few minutes. We just need to work out the details and coordinate. We also need to keep in mind what havok this may cause to users still using older versions of the BFAV2 client and what if anything we can do about that. Of course it wouldn't be the first time we have to force everyone to upgrade.
Let me know.
By the way I'm on IRC during US daylight hours nearly every weekday. You can generally find me in #squeak but even if I'm not there I may still be on the server which you can find out with the /whois command.
Ken
On Sat, 2004-08-07 at 10:18, Thomas Koenig wrote:
Does anyone already know why we can't we re-open a BFAV bug report? At first I'd assumed that it was a "policy" decision, but based on folks' comments that’s not the case. My next guess was that it's because we cannot "rewrite an email". I'm treating the BFAV server side as a black box and so I assume this to be a given. Now I'm wondering if reopening posts is a solvable problem on the client side. I've been experimenting with ways to split and regroup posts from the client side already. Regrouping faces similar problems and potential solutions. In both cases, if we solve the problem on the client side it involves duplicating posts. So if there is something I can invoke on the server side to update a post that would be helpful. Any insights about "why we cann't re-open a BFAV post" would be appreciated. Tom
On Saturday, August 7, 2004, at 11:18 AM, Thomas Koenig wrote:
Does anyone already know why we can't we re-open a BFAV bug report? At first I'd assumed that it was a "policy" decision, but based on folks' comments that’s not the case.
Right, it was never a policy decision... it was simply never implemented.
My next guess was that it's because we cannot "rewrite an email". I'm treating the BFAV server side as a black box and so I assume this to be a given. Now I'm wondering if reopening posts is a solvable problem on the client side. I've been experimenting with ways to split and regroup posts from the client side already. Regrouping faces similar problems and potential solutions. In both cases, if we solve the problem on the client side it involves duplicating posts. So if there is something I can invoke on the server side to update a post that would be helpful. Any insights about "why we cann't re-open a BFAV post" would be appreciated.
True, we can't "rewrite an email", but in some ways that's okay, because if you keep all the emails, you keep the history of what's happened.
I think right now the BFAV client doesn't classify groups according to the order in which posts appear. In other words, if there's a "[closed]" anywhere in a group, right now it always treats it as closed. We should be able to add a [reopened] tag, which moves a group back to the Review tab. But it should only appear there if a [reopened] post appears *after* the last [closed] post. It should also be possible to close a reopened post again, of course.
Actually, I've needed the same capability for moving an [approved] item back to Review status. There are several groups under Approved right now (at the bottom of the list) that have some issue and should go back to Review. We could probably also handle this with a [reopened] tag.
So, if we could enhance the BFAV client to do this, that would be a big improvement. Should be doable.
I guess support for a new [reopened] tag also needs to be added to the BFAV server. (I'm not quite sure why the BFAV server has to know about all the tags... I guess this is for performance reasons?)
Another BFAV improvement which is really needed is some sort of website which shows the current status of all fixes/enhancements for the last month, similar to Bert's old sqfixes site, so everyone has a quick/easy place to check what the status of something is. I already emailed about that privately... I wanted to work on this after 3.7 is released if no one else gets to it.
Merging groups together would be more difficult with the current system... I know Ken has talked about eventually replacing the emailed-based server with something more robust.
- Doug
Tom
Alexander Lazareviæ wrote: Let me add, that with a fully-fledged bug tracking system we could easily do things, that are impossible or hard to do with the current bug fix archive viewer. Some of the things are:
Reliable registry: Using the subject of an email the BFAV guesses if the email is a new report or an addition to an existing report. This can fail and in the worst case a report gets assigned to an already closed report and so just disappears. Merging: When two different reports describe the same issue it is hard to merge those just using BFAV. One reporter has to close his report and resend the same report with the same subject line of the other report. Reopening: Once a report is closed you can't reopen it with BFAV. [snip]
Doug, I will pursue the reopen and split/merge issues. Who do I talk to about the server side? Tom
Doug wrote
True, we can't "rewrite an email", but in some ways that's okay, because if you keep all the emails, you keep the history of what's happened.
I think right now the BFAV client doesn't classify groups according to the order in which posts appear. In other words, if there's a "[closed]" anywhere in a group, right now it always treats it as closed. We should be able to add a [reopened] tag, which moves a group back to the Review tab. But it should only appear there if a [reopened] post appears *after* the last [closed] post. It should also be possible to close a reopened post again, of course.
Actually, I've needed the same capability for moving an [approved] item back to Review status. There are several groups under Approved right now (at the bottom of the list) that have some issue and should go back to Review. We could probably also handle this with a [reopened] tag.
So, if we could enhance the BFAV client to do this, that would be a big improvement. Should be doable.
I guess support for a new [reopened] tag also needs to be added to the BFAV server. (I'm not quite sure why the BFAV server has to know about all the tags... I guess this is for performance reasons?)
[snip]
Merging groups together would be more difficult with the current system... I know Ken has talked about eventually replacing the emailed-based server with something more robust.
[snip]
On Sat, 2004-08-07 at 13:34, Thomas Koenig wrote:
Doug, I will pursue the reopen and split/merge issues. Who do I talk to about the server side?
Uh... Are we talking about the BFAV server? Did you not see my reply to your original message?
Anyway, at least currently I'm still in charge of the BFAV2 server, if you need anything there either from a maintenance or code standpoint let me know.
Ken
Tom
On Sat, 2004-08-07 at 12:56, Doug Way wrote:
Actually, I've needed the same capability for moving an [approved] item back to Review status. There are several groups under Approved right now (at the bottom of the list) that have some issue and should go back to Review. We could probably also handle this with a [reopened] tag.
Maybe we should just implement a set of tags that re-categorize a group. 're-reviewed', 're-approved', 're-update', 're-unreviewed'? That might be going overboard but you get the idea.
I guess support for a new [reopened] tag also needs to be added to the BFAV server. (I'm not quite sure why the BFAV server has to know about all the tags... I guess this is for performance reasons?)
The BFAV server knows about the tag so that the text processing work has to only be done once. This was a large part of the speed improvement between BFAV and BFAV2. It doesn't of course have to know what the tags mean, it just has to know what category the tag is and what bitmask it maps to. A few minutes work basically.
Another BFAV improvement which is really needed is some sort of website which shows the current status of all fixes/enhancements for the last month, similar to Bert's old sqfixes site, so everyone has a quick/easy place to check what the status of something is. I already emailed about that privately... I wanted to work on this after 3.7 is released if no one else gets to it.
I would be willing to look into this. However I've been burned rather badly in a couple of cases in the last couple of years putting in a lot of time on projects to then get no reaction, good, bad, or otherwise. I would only really be willing to do this if I'm presented with a clear design that the community in some fashion agrees will provide the desired functionality.
Merging groups together would be more difficult with the current system... I know Ken has talked about eventually replacing the emailed-based server with something more robust.
I spent quite a bit of time a few months ago looking into this. But I hit a wall on security. Its amazing really how much safety is built into the current system just due to the fact that it is an 'append-only' system. There's never any case in which information can be lost or overwritten. Implementing anything as safe in an object database model looked to be difficult. That wasn't the only reason I stopped, but it certainly slowed me down.
Again I would be willing to look at this again if the community as a whole could come to some sort of a consensus as to what they would really want out of such a system.
However the more I've thought about it I'm coming around to the idea of breaking the bug tracking and harvesting systems apart. There are many many open source bug tracking systems available, it really should be possible to make use of one of these. On the harvesting issue I found Michael's reminder of the dual update stream interesting.
I've recently been spending the bulk of my freetime working with Brian Rice and Lee Salzman and company on Slate. Clearly this is a much smaller and simpler (thank goodness) system than Squeak. But it has been amazingly refreshing to email a patch to the mailing list and have Lee or Brian harvest it within a couple of hours and that be the end of the issue.
I'm wondering if we can't find some sort of compromise between that and the current system for Squeak. Have two seperate streams: a stable stream that only the harvest master can modify (maybe multiple harvest masters) and an unstable stream that either any harvester, or better yet a larger body of developers, can modify. Each developer can then choose to subscribe to either stream for an image. For those on the stable stream life would continue as it is. For those on the unstable stream it would be understood that catastrope is just an update away and that you ALWAYS save before loading updates, maybe a couple of copies. Better yet the system offers to let you stop updating after each update and verify the state of your system. Whatever. The point here is to be more optimistic about updates in which case I believe we will have more eyeballs and people react much more strongly to problems than to reviewing.
Ken
On Saturday, August 7, 2004, at 04:39 PM, Ken Causey wrote:
On Sat, 2004-08-07 at 12:56, Doug Way wrote:
Actually, I've needed the same capability for moving an [approved] item back to Review status. There are several groups under Approved right now (at the bottom of the list) that have some issue and should go back to Review. We could probably also handle this with a [reopened] tag.
Maybe we should just implement a set of tags that re-categorize a group. 're-reviewed', 're-approved', 're-update', 're-unreviewed'? That might be going overboard but you get the idea.
True, although I don't think we need re-approved and re-update. If something goes back to review, then a simple [approved] or [update - xxxx] can still move it to Approved/Update. (Even if it's the second time it's approved... it's the order that matters.)
I'm not sure we really need re-unreviewed, either. (Although I wouldn't have a big problem with allowing it.) Right now, everything in Unreviewed has had no discussion whatsoever, which would not really be true for something bumped back from a different status.
So if we're only left with 're-reviewed', we could just call it 'reopened'. Although 're-reviewed' is okay with me too.
I guess support for a new [reopened] tag also needs to be added to the BFAV server. (I'm not quite sure why the BFAV server has to know about all the tags... I guess this is for performance reasons?)
The BFAV server knows about the tag so that the text processing work has to only be done once. This was a large part of the speed improvement between BFAV and BFAV2. It doesn't of course have to know what the tags mean, it just has to know what category the tag is and what bitmask it maps to. A few minutes work basically.
Ah, cool.
Another BFAV improvement which is really needed is some sort of website which shows the current status of all fixes/enhancements for the last month, similar to Bert's old sqfixes site, so everyone has a quick/easy place to check what the status of something is. I already emailed about that privately... I wanted to work on this after 3.7 is released if no one else gets to it.
I would be willing to look into this. However I've been burned rather badly in a couple of cases in the last couple of years putting in a lot of time on projects to then get no reaction, good, bad, or otherwise. I would only really be willing to do this if I'm presented with a clear design that the community in some fashion agrees will provide the desired functionality.
I think it should be relatively easy to get some consensus on this, I'll try to come up with an example and see what people think. Also I'll try to keep it simple enough so that it's easy to implement.
Merging groups together would be more difficult with the current system... I know Ken has talked about eventually replacing the emailed-based server with something more robust.
I spent quite a bit of time a few months ago looking into this. But I hit a wall on security. Its amazing really how much safety is built into the current system just due to the fact that it is an 'append-only' system. There's never any case in which information can be lost or overwritten. Implementing anything as safe in an object database model looked to be difficult. That wasn't the only reason I stopped, but it certainly slowed me down.
Again I would be willing to look at this again if the community as a whole could come to some sort of a consensus as to what they would really want out of such a system.
Yeah, I think it would be more difficult to come to a consensus on this, and it's not particularly urgent. The current append-only system has its advantages.
... On the harvesting issue I found Michael's reminder of the dual update stream interesting.
Will reply about this in more detail tomorrow.
- Doug
Doug Way wrote:
On Saturday, August 7, 2004, at 04:39 PM, Ken Causey wrote:
On Sat, 2004-08-07 at 12:56, Doug Way wrote:
Actually, I've needed the same capability for moving an [approved] item back to Review status. There are several groups under Approved right now (at the bottom of the list) that have some issue and should go back to Review. We could probably also handle this with a [reopened] tag.
Maybe we should just implement a set of tags that re-categorize a group. 're-reviewed', 're-approved', 're-update', 're-unreviewed'? That might be going overboard but you get the idea.
True, although I don't think we need re-approved and re-update. If something goes back to review, then a simple [approved] or [update - xxxx] can still move it to Approved/Update. (Even if it's the second time it's approved... it's the order that matters.)
I'm not sure we really need re-unreviewed, either. (Although I wouldn't have a big problem with allowing it.) Right now, everything in Unreviewed has had no discussion whatsoever, which would not really be true for something bumped back from a different status.
So if we're only left with 're-reviewed', we could just call it 'reopened'. Although 're-reviewed' is okay with me too.
Reopen will move closed messages to review and re-review will move from approved to review tab ? Sounds good to me Karl
squeak-dev@lists.squeakfoundation.org
-
Alexander Lazarević -
Doug Way -
Frank Shearar -
Karl Ramberg -
Ken Causey -
Marcus Denker -
Thomas Koenig