[Pharo-project] can you check the last update
Hi all I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1 I have to find some time (argh) to improve the process and the tools. because this is far too much manual. Stef
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval? Stef On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
No, RandomCleanup is broken and can be deleted. That was the upload problem. I renamed that to RandomRemoval to be sure that everything is fine. UnimplementedCalls is completely different and in the upstream now (in 10044). If I take a 10044 image and merge on RandomRemoval I can see the removals I've done. Norbert
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks I deleted RandomCleanup And will proceed the other one as time let me do it. Stef On Jun 25, 2008, at 9:32 AM, Norbert Hartl wrote:
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
No, RandomCleanup is broken and can be deleted. That was the upload problem. I renamed that to RandomRemoval to be sure that everything is fine. UnimplementedCalls is completely different and in the upstream now (in 10044). If I take a 10044 image and merge on RandomRemoval I can see the removals I've done.
Norbert
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Are you going to harvest the rest of the packages, too? KernelTests-al.67 Monticello-al.319 are fixing all but 2 remaining tests. Norbert On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
But norbert when I do an update + a merge of Slice-randomRemoval I get an empty list. Stef On Jun 25, 2008, at 9:32 AM, Norbert Hartl wrote:
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
No, RandomCleanup is broken and can be deleted. That was the upload problem. I renamed that to RandomRemoval to be sure that everything is fine. UnimplementedCalls is completely different and in the upstream now (in 10044). If I take a 10044 image and merge on RandomRemoval I can see the removals I've done.
Norbert
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yes I'm just losing time because sometimes there is not enough information for me. So may be we should have a wiki so that I can follow what I should integrate. Stef On Jun 25, 2008, at 9:45 AM, Norbert Hartl wrote:
Are you going to harvest the rest of the packages, too?
KernelTests-al.67 Monticello-al.319
are fixing all but 2 remaining tests. Norbert
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 2008-06-25 at 09:44 +0200, Stéphane Ducasse wrote:
But norbert when I do an update + a merge of Slice-randomRemoval I get an empty list.
Yes that's true for an 10045 image as you integrated exactly that fix. Loading updates shows something like "..NorbertCleaning.." and checking the package dependencies of SLICE-RandomRemoval all are loaded in 10045. So I can't tell why that happened but it did. So you can just delete SLICE-RandomRemoval and dependencies. Norbert
Stef
On Jun 25, 2008, at 9:32 AM, Norbert Hartl wrote:
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
No, RandomCleanup is broken and can be deleted. That was the upload problem. I renamed that to RandomRemoval to be sure that everything is fine. UnimplementedCalls is completely different and in the upstream now (in 10044). If I take a 10044 image and merge on RandomRemoval I can see the removals I've done.
Norbert
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yes this is strange :) but ok I will move on. Can you just check that I did not lose anything. stef On Jun 25, 2008, at 9:58 AM, Norbert Hartl wrote:
On Wed, 2008-06-25 at 09:44 +0200, Stéphane Ducasse wrote:
But norbert when I do an update + a merge of Slice-randomRemoval I get an empty list.
Yes that's true for an 10045 image as you integrated exactly that fix. Loading updates shows something like "..NorbertCleaning.." and checking the package dependencies of SLICE-RandomRemoval all are loaded in 10045. So I can't tell why that happened but it did. So you can just delete SLICE-RandomRemoval and dependencies.
Norbert
Stef
On Jun 25, 2008, at 9:32 AM, Norbert Hartl wrote:
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
No, RandomCleanup is broken and can be deleted. That was the upload problem. I renamed that to RandomRemoval to be sure that everything is fine. UnimplementedCalls is completely different and in the upstream now (in 10044). If I take a 10044 image and merge on RandomRemoval I can see the removals I've done.
Norbert
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 2008-06-25 at 09:54 +0200, Stéphane Ducasse wrote:
yes I'm just losing time because sometimes there is not enough information for me. So may be we should have a wiki so that I can follow what I should integrate.
As this is the inbox everything should be treated until it is empty. I thought this was the reason for TreatedInbox. We could do a SLICE for every fix so you could see what needs to be updated. But then it is hard to be sure someone reviewed it. Maybe the best solution is to use the issue tracker on google. That's the purpose it serves. If someone has an update he can open a ticket with type "patch" and status "Fixed". If another one has reviewed it he can change the status to "verified". To see what is ready for update you just filter the issues by status "Verified" Norbert
Stef
On Jun 25, 2008, at 9:45 AM, Norbert Hartl wrote:
Are you going to harvest the rest of the packages, too?
KernelTests-al.67 Monticello-al.319
are fixing all but 2 remaining tests. Norbert
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 2008-06-25 at 10:13 +0200, Stéphane Ducasse wrote:
yes this is strange :) but ok I will move on. Can you just check that I did not lose anything.
I checked already and it looks good for me. Norbert
stef
On Jun 25, 2008, at 9:58 AM, Norbert Hartl wrote:
On Wed, 2008-06-25 at 09:44 +0200, Stéphane Ducasse wrote:
But norbert when I do an update + a merge of Slice-randomRemoval I get an empty list.
Yes that's true for an 10045 image as you integrated exactly that fix. Loading updates shows something like "..NorbertCleaning.." and checking the package dependencies of SLICE-RandomRemoval all are loaded in 10045. So I can't tell why that happened but it did. So you can just delete SLICE-RandomRemoval and dependencies.
Norbert
Stef
On Jun 25, 2008, at 9:32 AM, Norbert Hartl wrote:
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
No, RandomCleanup is broken and can be deleted. That was the upload problem. I renamed that to RandomRemoval to be sure that everything is fine. UnimplementedCalls is completely different and in the upstream now (in 10044). If I take a 10044 image and merge on RandomRemoval I can see the removals I've done.
Norbert
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
We could do a SLICE for every fix so you could see what needs to be updated. But then it is hard to be sure someone reviewed it.
Maybe the best solution is to use the issue tracker on google. That's the purpose it serves. If someone has an update he can open a ticket with type "patch" and status "Fixed". If another one has reviewed it he can change the status to "verified". To see what is ready for update you just filter the issues by status "Verified"
Yes we should do that
Norbert
Stef
On Jun 25, 2008, at 9:45 AM, Norbert Hartl wrote:
Are you going to harvest the rest of the packages, too?
KernelTests-al.67 Monticello-al.319
are fixing all but 2 remaining tests. Norbert
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 2008-06-25 at 10:26 +0200, Stéphane Ducasse wrote:
We could do a SLICE for every fix so you could see what needs to be updated. But then it is hard to be sure someone reviewed it.
Maybe the best solution is to use the issue tracker on google. That's the purpose it serves. If someone has an update he can open a ticket with type "patch" and status "Fixed". If another one has reviewed it he can change the status to "verified". To see what is ready for update you just filter the issues by status "Verified"
Yes we should do that
Ok, I changed a few things: - removed unnecessary columns Difficulty and Priority from Issue list view - added status closed so it either goes -> defect -> fix -> verified -> close or -> patch -> fix -> verified -> close - treated a few issues to have correct status So Stef, all you have to do is to save this link http://code.google.com/p/pharo/issues/list?q=status%3AVerified&can=1 and click it if you want to know what to do ;) I hope you like it. Norbert
Norbert
Stef
On Jun 25, 2008, at 9:45 AM, Norbert Hartl wrote:
Are you going to harvest the rest of the packages, too?
KernelTests-al.67 Monticello-al.319
are fixing all but 2 remaining tests. Norbert
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Jun 25, 2008 at 10:26 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Maybe the best solution is to use the issue tracker on google. That's the purpose it serves. If someone has an update he can open a ticket with type "patch" and status "Fixed". If another one has reviewed it he can change the status to "verified". To see what is ready for update you just filter the issues by status "Verified"
Yes we should do that
http://code.google.com/p/pharo/issues/detail?id=16 -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Wed, Jun 25, 2008 at 10:50 AM, Norbert Hartl <norbert@hartl.name> wrote:
Ok, I changed a few things:
- removed unnecessary columns Difficulty and Priority from Issue list view - added status closed so it either goes -> defect -> fix -> verified -> close or -> patch -> fix -> verified -> close - treated a few issues to have correct status
You may want to remove other statuses. Here is the list: New = Issue has not had initial review yet Accepted = Problem reproduced / Need acknowledged Started = Work on this issue has begun Comment = A question has been asked Fixed = Developer made requested changes, QA should verify Verified = QA has verified that the fix worked Invalid = This was not a valid issue report Duplicate = This report duplicates an existing issue WontFix = We decided to not take action on this issue Closed = The fix has been treated and issue is closed -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Wed, Jun 25, 2008 at 10:50 AM, Norbert Hartl <norbert@hartl.name> wrote:
- removed unnecessary columns Difficulty and Priority from Issue
Should I remove them completely from the issue tracking system? Fixed = Developer made requested changes, QA should verify Verified = QA has verified that the fix worked Invalid = This was not a valid issue report Duplicate = This report duplicates an existing issue WontFix = We decided to not take action on this issue Closed = The fix has been treated and issue is closed -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Wed, 2008-06-25 at 10:54 +0200, Damien Cassou wrote:
On Wed, Jun 25, 2008 at 10:50 AM, Norbert Hartl <norbert@hartl.name> wrote:
Ok, I changed a few things:
- removed unnecessary columns Difficulty and Priority from Issue list view - added status closed so it either goes -> defect -> fix -> verified -> close or -> patch -> fix -> verified -> close - treated a few issues to have correct status
You may want to remove other statuses. Here is the list:
New = Issue has not had initial review yet Accepted = Problem reproduced / Need acknowledged Started = Work on this issue has begun Comment = A question has been asked
Fixed = Developer made requested changes, QA should verify Verified = QA has verified that the fix worked Invalid = This was not a valid issue report Duplicate = This report duplicates an existing issue WontFix = We decided to not take action on this issue Closed = The fix has been treated and issue is closed
Which you would delete? They are all good and useful in my opinion. The only one which isn't useful to me is "Started". Norbert
On Wed, 2008-06-25 at 10:55 +0200, Damien Cassou wrote:
On Wed, Jun 25, 2008 at 10:50 AM, Norbert Hartl <norbert@hartl.name> wrote:
- removed unnecessary columns Difficulty and Priority from Issue
Should I remove them completely from the issue tracking system?
Fixed = Developer made requested changes, QA should verify Verified = QA has verified that the fix worked Invalid = This was not a valid issue report Duplicate = This report duplicates an existing issue WontFix = We decided to not take action on this issue Closed = The fix has been treated and issue is closed
I don't understan. I removed the columns in the view as they are only disturbing. What do you mean by showing the list of statusses? Norbert
On Wed, Jun 25, 2008 at 11:05 AM, Norbert Hartl <norbert@hartl.name> wrote:
On Wed, 2008-06-25 at 10:55 +0200, Damien Cassou wrote:
On Wed, Jun 25, 2008 at 10:50 AM, Norbert Hartl <norbert@hartl.name> wrote:
- removed unnecessary columns Difficulty and Priority from Issue
Should I remove them completely from the issue tracking system?
Fixed = Developer made requested changes, QA should verify Verified = QA has verified that the fix worked Invalid = This was not a valid issue report Duplicate = This report duplicates an existing issue WontFix = We decided to not take action on this issue Closed = The fix has been treated and issue is closed
I don't understan. I removed the columns in the view as they are only disturbing. What do you mean by showing the list of statusses?
I meant: Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement Type-Task = Work item that doesn't change the code or docs Type-Patch = Source code patch for review Type-Other = Some other kind of issue Priority-High = Strongly want to resolve in the specified milestone Priority-Medium = Normal priority Priority-Low = Might slip to later milestone Difficulty-VeryEasy = Anybody can fix that in a few seconds Difficulty-Easy = Only little knowledge and time required Difficulty-Medium = Knowledge and time required Difficulty-Hard = Requires more than one expert -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Wed, 2008-06-25 at 12:52 +0200, Damien Cassou wrote:
On Wed, Jun 25, 2008 at 11:05 AM, Norbert Hartl <norbert@hartl.name> wrote:
On Wed, 2008-06-25 at 10:55 +0200, Damien Cassou wrote:
On Wed, Jun 25, 2008 at 10:50 AM, Norbert Hartl <norbert@hartl.name> wrote:
- removed unnecessary columns Difficulty and Priority from Issue
Should I remove them completely from the issue tracking system?
Fixed = Developer made requested changes, QA should verify Verified = QA has verified that the fix worked Invalid = This was not a valid issue report Duplicate = This report duplicates an existing issue WontFix = We decided to not take action on this issue Closed = The fix has been treated and issue is closed
I don't understan. I removed the columns in the view as they are only disturbing. What do you mean by showing the list of statusses?
I meant:
Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement Type-Task = Work item that doesn't change the code or docs Type-Patch = Source code patch for review Type-Other = Some other kind of issue Priority-High = Strongly want to resolve in the specified milestone Priority-Medium = Normal priority Priority-Low = Might slip to later milestone Difficulty-VeryEasy = Anybody can fix that in a few seconds Difficulty-Easy = Only little knowledge and time required Difficulty-Medium = Knowledge and time required Difficulty-Hard = Requires more than one expert
Why you want to remove them? Now they are only visible in the admin area where to don't disturb anyone. But do as you think is best. Norbert
Excellent!!! I like one click todo :)
We could do a SLICE for every fix so you could see what needs to be updated. But then it is hard to be sure someone reviewed it.
Maybe the best solution is to use the issue tracker on google. That's the purpose it serves. If someone has an update he can open a ticket with type "patch" and status "Fixed". If another one has reviewed it he can change the status to "verified". To see what is ready for update you just filter the issues by status "Verified"
Yes we should do that
Ok, I changed a few things:
- removed unnecessary columns Difficulty and Priority from Issue list view - added status closed so it either goes -> defect -> fix -> verified -> close or -> patch -> fix -> verified -> close - treated a few issues to have correct status
So Stef, all you have to do is to save this link
http://code.google.com/p/pharo/issues/list?q=status%3AVerified&can=1
and click it if you want to know what to do ;)
I hope you like it.
Norbert
Norbert
Stef
On Jun 25, 2008, at 9:45 AM, Norbert Hartl wrote:
Are you going to harvest the rest of the packages, too?
KernelTests-al.67 Monticello-al.319
are fixing all but 2 remaining tests. Norbert
On Wed, 2008-06-25 at 09:00 +0200, Stéphane Ducasse wrote:
this is strange when I do a merge with SLICE-randomRemoval I get an emtpy list. Were SLICE-UnimplementedCallsFix1-NorbertHartl.1 and randomRemoval the same? Should I close SLICE-randomRemoval?
Stef
On Jun 25, 2008, at 8:52 AM, Stéphane Ducasse wrote:
Hi all
I got some funny unpublished packages and I'm a bit confused. So could you check what I did. I was harvesting MVC removal + norbert cleaning SLICE- UnimplementedCallsFix1-NorbertHartl.1
I have to find some time (argh) to improve the process and the tools. because this is far too much manual.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Jun 25, 2008 at 1:00 PM, Norbert Hartl <norbert@hartl.name> wrote:
On Wed, 2008-06-25 at 12:52 +0200, Damien Cassou wrote:
On Wed, Jun 25, 2008 at 11:05 AM, Norbert Hartl <norbert@hartl.name> wrote:
On Wed, 2008-06-25 at 10:55 +0200, Damien Cassou wrote:
On Wed, Jun 25, 2008 at 10:50 AM, Norbert Hartl <norbert@hartl.name> wrote:
- removed unnecessary columns Difficulty and Priority from Issue
Should I remove them completely from the issue tracking system?
Fixed = Developer made requested changes, QA should verify Verified = QA has verified that the fix worked Invalid = This was not a valid issue report Duplicate = This report duplicates an existing issue WontFix = We decided to not take action on this issue Closed = The fix has been treated and issue is closed
I don't understan. I removed the columns in the view as they are only disturbing. What do you mean by showing the list of statusses?
I meant:
Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement Type-Task = Work item that doesn't change the code or docs Type-Patch = Source code patch for review Type-Other = Some other kind of issue Priority-High = Strongly want to resolve in the specified milestone Priority-Medium = Normal priority Priority-Low = Might slip to later milestone Difficulty-VeryEasy = Anybody can fix that in a few seconds Difficulty-Easy = Only little knowledge and time required Difficulty-Medium = Knowledge and time required Difficulty-Hard = Requires more than one expert
Why you want to remove them? Now they are only visible in the admin area where to don't disturb anyone. But do as you think is best.
They can still be set at the bottom of bug raeporats. Just click in the text-fields -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
participants (3)
-
Damien Cassou -
Norbert Hartl -
Stéphane Ducasse