Back in September of last year in more or less official terms (the best we could manage at the time anyway) it was suggested that all new BUG reports be posted on the Mantis database. At that time all ENH and FIXes would still go to the list. Compliance with this policy has been spotty at best. I'm now suggesting that we stop with the half-way measures and simply designate that the Mantis database (http://bugs.impara.de/) is THE official location for new BUG, ENH, and FIX reports.
Why?
1. As the BFAV server maintainer I can testify that the system itself is somewhat fragile.
2. Posting BUG reports to the list has some benefits in terms of visibility but it has some major problems.
a. Any tool that has to try to automatically extract the useful reports for the flood of activity has a difficult job even under the best of circumstances.
b. There is no enforcement in email for any kind of standard of reporting in terms of minimal information or staying on topic. One result of this is that more than a few threads in BFAV are overloaded with off-topic discussion. This makes the task for the prospective fixer, harvester, reviewer whatever rather more difficult. Also it has happened in more than one case that reports to the list have the exact same subject even if they are not really on the same topic. This results in them being mixed together in BFAV client.
3. As we progress to a world where people are signing up to be responsible for parts of Squeak we need a way to filter reports to those people that are best placed to handle them. BFAV has a difficult time of providing this. Mantis already has the facilities to do this.
Now, I don't expect the world to change overnight. I expect that for some time after we make this 'official' that reports will continue to appear on the mailing list. In fact sending reports to the mailing list is something that newbies would probably be more comfortable with than immediately jumping in and tackling the complexities of filling out a Mantis report form. To that end the Janitors group is proposing to form a small team who will accept the responsibility for seeing that all reports to the list after some date (sometime next week I hope) will be checked for reasonable validity and be posted as new reports on the Mantis database. I expect that we will continue to provide this service well into the forseeable future although with luck the volume of new reports to the list will decrease.
Why not?
1. Using the Mantis requires a little knowledge. I think with the process I outline above that the Janitors will handle we can completely address this one by allow the occasional report to still appear on the list and the understanding that as quickly as possible we will see to it that it shows up in the Mantis database.
2. Using the Mantis database is awkward. Admittedly this is a new tool to many people. I feel that once everyone has learned to use it that most of the awkwardness will disappear. The only acception to this that I can come up with is trying to evaluate Squeak code attachments. Right now that requires a two-step of saving the file from the web page and then opening it in Squeak with a filelist or similar tool. I personally don't think that is too bad. However I expect that before too long we can address this one as well with a little Squeak tool that allows you to specify the Mantis ID number of the issue and then offers you a list of attachments that can be viewed and processed as easily as attachments in the BFAV client.
Ken Causey
Ken, if you want to retire BFAV then that is of course your right. It is certainly a pain to have two not-very-well integrated systems in use for users and maintainers.
HOwever, I think you could do us all a very big favour by trying to make a new BFAV tool that talks to the Mantis DB. Personally I find that stupid, cumbersome, irritating web UI to be stupid, cumbersome and irritating. Even if it is only possible to make the original reporting of a bug as easy _from within Squeak_ as BFAV made it then life would be much nicer.
Just my 10c worth ( hey, I'm important so I get more than 2c ;-) )
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Don't document the program; program the document.
On Fri, 2005-02-25 at 11:56 -0800, Tim Rowledge wrote:
Ken, if you want to retire BFAV then that is of course your right. It is certainly a pain to have two not-very-well integrated systems in use for users and maintainers.
Thanks, but that might be putting it a little too strongly. I'm only one of several developers of BFAV and it could be argued that I only developed a small part of it, so that doesn't really give me much more right than everyone else has.
HOwever, I think you could do us all a very big favour by trying to make a new BFAV tool that talks to the Mantis DB. Personally I find that stupid, cumbersome, irritating web UI to be stupid, cumbersome and irritating. Even if it is only possible to make the original reporting of a bug as easy _from within Squeak_ as BFAV made it then life would be much nicer.
Just my 10c worth ( hey, I'm important so I get more than 2c ;-) )
Hey, I'll be happy to give you 10c. But I think you've got it a bit backwards here. I for one have spent time in the past writing tools to support 'future' policies only to have the policy never come into effect and for my tool to go completely unused. I'm not up for that. A tool would be useful, I don't deny it. However the Mantis web access without any other tool is perfectly useable if not ideal. As I mentioned in that email if we agree to move exclusively to the Mantis database I'm quite happy to help out with a tool (or tools) and I know others that are also interested in working on this. But we aren't going to do so before the commitment to using the existing tool is made.
Ken
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Don't document the program; program the document.
hi ken
I think that your are right even if BFAV was really a big help. Have you some time/ideas to replace it? and migrate what is pending in BFAV into Mantis.
Stef
On 25 févr. 05, at 20:21, Ken Causey wrote:
Back in September of last year in more or less official terms (the best we could manage at the time anyway) it was suggested that all new BUG reports be posted on the Mantis database. At that time all ENH and FIXes would still go to the list. Compliance with this policy has been spotty at best. I'm now suggesting that we stop with the half-way measures and simply designate that the Mantis database (http://bugs.impara.de/) is THE official location for new BUG, ENH, and FIX reports.
Why?
- As the BFAV server maintainer I can testify that the system itself
is somewhat fragile.
- Posting BUG reports to the list has some benefits in terms of
visibility but it has some major problems.
a. Any tool that has to try to automatically extract the useful reports for the flood of activity has a difficult job even under the best of circumstances.
b. There is no enforcement in email for any kind of standard of reporting in terms of minimal information or staying on topic. One result of this is that more than a few threads in BFAV are overloaded with off-topic discussion. This makes the task for the prospective fixer, harvester, reviewer whatever rather more difficult. Also it has happened in more than one case that reports to the list have the exact same subject even if they are not really on the same topic. This results in them being mixed together in BFAV client.
- As we progress to a world where people are signing up to be
responsible for parts of Squeak we need a way to filter reports to those people that are best placed to handle them. BFAV has a difficult time of providing this. Mantis already has the facilities to do this.
Now, I don't expect the world to change overnight. I expect that for some time after we make this 'official' that reports will continue to appear on the mailing list. In fact sending reports to the mailing list is something that newbies would probably be more comfortable with than immediately jumping in and tackling the complexities of filling out a Mantis report form. To that end the Janitors group is proposing to form a small team who will accept the responsibility for seeing that all reports to the list after some date (sometime next week I hope) will be checked for reasonable validity and be posted as new reports on the Mantis database. I expect that we will continue to provide this service well into the forseeable future although with luck the volume of new reports to the list will decrease.
Why not?
- Using the Mantis requires a little knowledge. I think with the
process I outline above that the Janitors will handle we can completely address this one by allow the occasional report to still appear on the list and the understanding that as quickly as possible we will see to it that it shows up in the Mantis database.
- Using the Mantis database is awkward. Admittedly this is a new
tool to many people. I feel that once everyone has learned to use it that most of the awkwardness will disappear. The only acception to this that I can come up with is trying to evaluate Squeak code attachments. Right now that requires a two-step of saving the file from the web page and then opening it in Squeak with a filelist or similar tool. I personally don't think that is too bad. However I expect that before too long we can address this one as well with a little Squeak tool that allows you to specify the Mantis ID number of the issue and then offers you a list of attachments that can be viewed and processed as easily as attachments in the BFAV client.
Ken Causey
On Fri, 2005-02-25 at 21:50 +0100, stéphane ducasse wrote:
hi ken
I think that your are right even if BFAV was really a big help. Have you some time/ideas to replace it?
First of all I think that Mantis is a perfectly acceptable replacement as it is. So for the immediate term I think we are OK. However it is my intention to use what we have learned and will learn as we make the current transitions (partitioning the system, etc.) to design a new system with the assistance of others. I plan to make baby steps as much as possible however so that may involve little tools to work with Mantis from Squeak more easily in the medium term to perhaps a wholy new Squeak only OODB/P2P/whatever extravaganza in the long term.
and migrate what is pending in BFAV into Mantis.
As soon as we agree that moving to Mantis (completely) is the way to go I'm already signing people up for the task of copying new posts to the list to Mantis as I outlined in my first message. We also are already discussing a second task that involves going through BFAV and moving any incomplete issues there and I would expect that to start no later than two weeks from the beginning of the first task.
Ken
Stef
Hi Ken
I think that the first things would be to change the send to the list feature with a BIG warning telling" ARE YOU SHOULD THAT YOU DO NOT WANT TO USE MANTIS"
With the experience we have on squeaksource (you may contact lukas and adrian) they build squeaksource (version .9) in three four days, it would be worth to see if we can use seaside and that we can script the applications to send bug report/upload code there directly. But as this is your time I will use what you propose.
I think that what was really great with BFAV is that I could browse the code and load it from Squeak itself. That was great compared with the first horrible interface we had for harvesting (which was already better than a simple mailinglist)
Stef
On 25 févr. 05, at 22:13, Ken Causey wrote:
On Fri, 2005-02-25 at 21:50 +0100, stéphane ducasse wrote:
hi ken
I think that your are right even if BFAV was really a big help. Have you some time/ideas to replace it?
First of all I think that Mantis is a perfectly acceptable replacement as it is. So for the immediate term I think we are OK. However it is my intention to use what we have learned and will learn as we make the current transitions (partitioning the system, etc.) to design a new system with the assistance of others. I plan to make baby steps as much as possible however so that may involve little tools to work with Mantis from Squeak more easily in the medium term to perhaps a wholy new Squeak only OODB/P2P/whatever extravaganza in the long term.
and migrate what is pending in BFAV into Mantis.
As soon as we agree that moving to Mantis (completely) is the way to go I'm already signing people up for the task of copying new posts to the list to Mantis as I outlined in my first message. We also are already discussing a second task that involves going through BFAV and moving any incomplete issues there and I would expect that to start no later than two weeks from the beginning of the first task.
Ken
Stef
On Sat, 2005-02-26 at 08:51 +0100, stéphane ducasse wrote:
Hi Ken
I think that the first things would be to change the send to the list feature with a BIG warning telling" ARE YOU SHOULD THAT YOU DO NOT WANT TO USE MANTIS"
That is something to think about. We plan to handle moving posts from the list to Mantis though for at least a few months so I'm not worried about it at this point.
With the experience we have on squeaksource (you may contact lukas and adrian) they build squeaksource (version .9) in three four days, it would be worth to see if we can use seaside and that we can script the applications to send bug report/upload code there directly. But as this is your time I will use what you propose.
My biggest issue is with trying to build a complex tool before we really understand how the process is going to work. BFAV was built to support the harvesting process. Even with that in mind it had to be molded over time to try to fit the reality of the process rather than the ideal. But I'm afraid in the end it was not successful because largely the harvesting process has not been successful.
With that in mind I think we need to develop and experience a working process before anyone spends a lot of time on tools that don't get used or at best are never quite right because we built the tool before we understood the problem.
I think that what was really great with BFAV is that I could browse the code and load it from Squeak itself. That was great compared with the first horrible interface we had for harvesting (which was already better than a simple mailinglist)
With one additional step (click on the link in the report and save the attachment) you have this through the FileList. Don't you agree? (Although one thing you end up with if you aren't careful is a folder full of attachments without any organization so no it's not ideal.)
Ken
Stef
Right on, Ken. I think your approach shows a lot of wisdom.
I appreciate you and the rest of the "Janitors" willingness to use a lot of elbow grease to help bug/fix/enh material get to the right people during the transition to a partitioned image. I hope that partitioning & team-building succeeds so well that the Janitors end up having very little to do :)
Thank you, Frank, and Tom for all your work keeping the BFAV going.
On Feb 25, 2005, at 2:21 PM, Ken Causey wrote:
Back in September of last year in more or less official terms (the best we could manage at the time anyway) it was suggested that all new BUG reports be posted on the Mantis database. At that time all ENH and FIXes would still go to the list. Compliance with this policy has been spotty at best. I'm now suggesting that we stop with the half-way measures and simply designate that the Mantis database (http://bugs.impara.de/) is THE official location for new BUG, ENH, and FIX reports. ...
Just wanted to publicly chime in that I support the move to Mantis.
As some food for thought, here's what I would list as the main advantages of Mantis vs BFAV, roughly in order of importance:
Advantages of Mantis: - Accessibility - Stability - Based on a database, not an email-list as a backend - More powerful categorization features - No mixing of often off-topic discussion
Advantages of BFAV: - UI in Squeak - Supports offline evaluation of fixes/enhs
Accessibility is a key issue... right now it's considerably easier & quicker for a beginner to check on the status of a fix in Mantis, just go to the website. With BFAV you have to install BFAV from SqueakMap (which sometimes wasn't working, so you'd have to know to go to SqueakSource instead), then this would install various prereqs for you (which were sometimes unstable, mostly due to Squeak's not-yet-existent support for real dependencies), then you'd have to wait for it to download the big BFAV archive of fixes which would take a while. A lot of these problems were beyond the BFAV developers' control, having to do with it being based on the old email-list system as a backend, and the lack of stable package dependencies in Squeak.
BFAV has some cool features, though. The UI being directly available in Squeak is really nice. This lets you do a quick "browse code" on a fix/enh changeset, for example. I think we should try to get this going, one way or another, with Mantis. One way would be to improve Scamper to the point that it at least supports html tables, then Mantis would probably be usable in Scamper. Then you could "browse code" etc directly on changeset attachments in Mantis. Another option would be to write a special Mantis client in Squeak (although that sounds like considerably more work).
Then you also have the ability to evaluate fixes/enhs offline with BFAV, since they're all stored locally, which is quite nice. (Although this isn't really a crucial feature.) I doubt this feature will be available with Mantis anytime soon.
But anyway, I think Mantis is a lot closer to where we want to be, so let's go for it & switch over.
- Doug
On Sat, 26 Feb 2005 17:17:52 -0500, Doug Way dway@mailcan.com wrote:
Just wanted to publicly chime in that I support the move to Mantis.
As some food for thought, here's what I would list as the main advantages of Mantis vs BFAV, roughly in order of importance:
Advantages of Mantis:
- Accessibility
- Stability
- Based on a database, not an email-list as a backend
- More powerful categorization features
- No mixing of often off-topic discussion
Advantages of BFAV:
- UI in Squeak
- Supports offline evaluation of fixes/enhs
<snip />
But anyway, I think Mantis is a lot closer to where we want to be, so let's go for it & switch over.
I wonder what would happen if we had a rock solid native web browser built in Squeak. Maybe some of anxieties about having to have the system built and accessible right in Morphic would go away because Mantis would be directly accessible in Squeak.
:-( Unfortunately I don't have any exciting news to announce isn this area, but I agree about the accessibility in Squeak is super high on my list of importance (and I really wish we had the best web browser you could find on the planet).
Cheers,
John
John Pierce wrote:
On Sat, 26 Feb 2005 17:17:52 -0500, Doug Way dway@mailcan.com wrote:
Just wanted to publicly chime in that I support the move to Mantis.
As some food for thought, here's what I would list as the main advantages of Mantis vs BFAV, roughly in order of importance:
Advantages of Mantis:
- Accessibility
- Stability
- Based on a database, not an email-list as a backend
- More powerful categorization features
- No mixing of often off-topic discussion
Advantages of BFAV:
- UI in Squeak
- Supports offline evaluation of fixes/enhs
<snip />
But anyway, I think Mantis is a lot closer to where we want to be, so let's go for it & switch over.
I wonder what would happen if we had a rock solid native web browser built in Squeak. Maybe some of anxieties about having to have the system built and accessible right in Morphic would go away because Mantis would be directly accessible in Squeak.
:-( Unfortunately I don't have any exciting news to announce isn this area, but I agree about the accessibility in Squeak is super high on my list of importance (and I really wish we had the best web browser you could find on the planet).
Cheers,
John
I've been experimenting with table support in Scamper from time to time. Attached is my latest effort, a ugly hack, and stuff does not show up very nice. It uses a grid layout change set (from a french guy, sorry, I can't remember his name) called SFC which I modified a little to be able to add rows and cols after it was initiated. One of several problems with html table layout is that you have to estimate how things should look and how big cells should be etc. and I have not found a nice way to do this properly. Also downloading gif and jpg take a little time and their size is not allways known so I have the TableMorph stepping and change through several iterations.
There is lot's of stuff to improve on in this change set :-)
Karl
Hi fellas!
I support Ken's Team in all this, let's us for once get this mess sorted out and the first step is to focus on Mantis and move from there.
One thing Doug didn't mention about Mantis is IMHO the ability to assign bugs to developers - not that we use it (?), but it could be a nice thing to start using.
I worked as a "janitor" on a software company and we had a role - a person that every morning took the list of fresh reports and assigned them all to the "correct" developer. And if it wasn't obvious a guess was made - and if the developer didn't think it was his/hers then it was bounced around. But it always had someone assigned to it. :)
Of course there are multiple issues with this for Squeak - and we probably should wait until partitioning is under way.
regards, Göran
BFAV has some cool features, though. The UI being directly available in Squeak is really nice. This lets you do a quick "browse code" on a fix/enh changeset, for example. I think we should try to get this going, one way or another, with Mantis. One way would be to improve Scamper to the point that it at least supports html tables, then Mantis would probably be usable in Scamper. Then you could "browse code" etc directly on changeset attachments in Mantis. Another option would be to write a special Mantis client in Squeak (although that sounds like considerably more work).
An alternative, is to use WWW-mining techniques: download the HTML from Mantis, parse it, and grovel around looking for the tasty bits. Here's some info on how to do this kind of thing from Squeak:
"How to Mine Web pages" http://coweb.cc.gatech.edu/cs2340/1271
Also, here are some student projects which do a lot of this kind of thing:
"Cases" http://coweb.cc.gatech.edu/cs2340/17
Scan down for "MP3 jukebox" and "Newspaper", both of which snagged content from the web.
HTML-trawling is effective for web sites that don't change too often, and it takes less code in Squeak than you'd expect. (Which was, in fact, part of the reason for doing it in the above-linked class. It's really great seeing students accomplish something they didn't think was in their grasp!)
-Lex
squeak-dev@lists.squeakfoundation.org
-
Brent Vukmer -
Doug Way -
goran.krampe＠bluefish.se -
John Pierce -
karl -
Ken Causey -
Lex Spoon -
stéphane ducasse -
Tim Rowledge