Hi,
My BFAV was working under 3.8alpha on windows (3.7.1 VM).
It is now dead.
1. -- If I install BFAV from SqueakMap into a fresh 3.8 image (6297) and then open the BFAV client I get: Last BFAV update failed: FileDoesNotExistException: 'D:\Squeak\38\email-file-repository\bfav.squeakfoundation.org\listing'
There is however a listing.zip in that directory.
2. -- If I manually extract the listing file and try to 'load updates...', I get
Last BFAV update failed: MessageNotUnderstood: UndefinedObject>><
3. -- If I then click on a post, I get:
Couldn't find email file with id 24928
Help !
Brent
Try exitting BFAV (within the image) then closing the image. Delete the listing.zip file and then restart the image and then BFAV. If that doesn't work let me know or find me on #squeak on irc.freenode.net and I'll see what I can do.
Ken
On Mon, 2004-10-04 at 11:40, Brent Pinkney wrote:
Hi,
My BFAV was working under 3.8alpha on windows (3.7.1 VM).
It is now dead.
-- If I install BFAV from SqueakMap into a fresh 3.8 image (6297) and then open the BFAV client I get: Last BFAV update failed: FileDoesNotExistException: 'D:\Squeak\38\email-file-repository\bfav.squeakfoundation.org\listing'
There is however a listing.zip in that directory.
-- If I manually extract the listing file and try to 'load updates...', I get
Last BFAV update failed: MessageNotUnderstood: UndefinedObject>><
-- If I then click on a post, I get:
Couldn't find email file with id 24928
Help !
Brent
We published a faulty update 6281Zip-extract-folder. This has now been removed from the unstable stream. So you need to re-update a 3.8a-unstable with an update number smaller than 6281 to get a working version.
Marcus
Am 04.10.2004 um 18:40 schrieb Brent Pinkney:
Hi,
My BFAV was working under 3.8alpha on windows (3.7.1 VM).
It is now dead.
-- If I install BFAV from SqueakMap into a fresh 3.8 image (6297) and then open the BFAV client I get: Last BFAV update failed: FileDoesNotExistException: 'D:\Squeak\38\email-file-repository\bfav.squeakfoundation.org\listing'
There is however a listing.zip in that directory.
-- If I manually extract the listing file and try to 'load updates...', I get
Last BFAV update failed: MessageNotUnderstood: UndefinedObject>><
-- If I then click on a post, I get:
Couldn't find email file with id 24928
Help !
Brent
On Mon, 4 Oct 2004 18:56:18 +0200, Marcus Denker denker@iam.unibe.ch wrote:
We published a faulty update 6281Zip-extract-folder. This has now been removed from the unstable stream. So you need to re-update a 3.8a-unstable with an update number smaller than 6281 to get a working version.
Ok - updated from 3.7 (6987).
Still get:
Last BFAV update failed: MessageNotUnderstood: UndefinedObject>><
Thanks
Brent
"Marcus" == Marcus Denker denker@iam.unibe.ch writes:
Marcus> We published a faulty update 6281Zip-extract-folder. This has Marcus> now been removed from the unstable stream. So you need to Marcus> re-update a 3.8a-unstable with an update number smaller than Marcus> 6281 to get a working version.
Marcus,
could you please add a new update which *reverts* the previous one? The update stream should not be modified afterwards except if a change broke the ability to update itself.
As far as I am concerned, I have tons of things in my image and I cannot revert to a previous update number as easily, and I suspect I'm not the only one.
Sam
Am 04.10.2004 um 19:50 schrieb Samuel Tardieu:
"Marcus" == Marcus Denker denker@iam.unibe.ch writes:
Marcus> We published a faulty update 6281Zip-extract-folder. This has Marcus> now been removed from the unstable stream. So you need to Marcus> re-update a 3.8a-unstable with an update number smaller than Marcus> 6281 to get a working version.
Marcus,
could you please add a new update which *reverts* the previous one? The update stream should not be modified afterwards except if a change broke the ability to update itself.
As far as I am concerned, I have tons of things in my image and I cannot revert to a previous update number as easily, and I suspect I'm not the only one.
You should not be updating from the unstable stream, then. We *will* modify it. For example, the best way to get a couple of additions in that we missed when grabbing the Squeakland changes is to just insert them in the right place a hundred updates back.
- Bert -
"Bert" == Bert Freudenberg bert@impara.de writes:
Bert> You should not be updating from the unstable stream, then. We Bert> *will* modify it. For example, the best way to get a couple of Bert> additions in that we missed when grabbing the Squeakland changes Bert> is to just insert them in the right place a hundred updates Bert> back.
Well, it depends of what you (harvesters) want. I use the unstable stream because this way, while I do my development, I can easily test the latest enhancements made to the image, review fixes and fix bugs when I want to distract myself from "serious" work. Restarting from an empty 3.8alpha and reloading the updates and reinstall the latest version of the tools I use to fix bugs is likely to be much less frequent if it is not in my work environment.
Moreover, after having been developing free software for about 13 years now, I strongly believe that the best software you can deliver is the one you use yourself for your daily work.
Also, if I find a bug for which I can find a workaround easily while working in a stable image, I am likely to use this workaround rather than fixing the bug if I am in a hurry because it may have already been fixed in an unstable update already that is not installed in my image.
I understand that this may be easier to remove the update or to fix the update stream back in time as of today, but this makes it very hard for other people to follow it. I do not know the harvesting process so I cannot comment on its effectiveness, but maybe it would be a good idea to stop for a few days and concentrate on a way to ease the harvester's hard job to allow them to create a new update from a changeset in one click or so (doesn't that exist already?).
To make it clear: my request for successive unmodified updates is not a rant, this is a plea for better development practices :)
Sam
The idea of the unstable stream was to have a stream were we can fix bugs easily by changing the changesets that are that stream. If we are not able to do that, we don't need an unstable update stream. Then we would just need the 3.8a stream.
Please keep in mind that the idea was that the unstable stream is synced back every week or two. The situation we have now (with >300 updates in unstable) is not normal and really needs to be fixed.
Marcus
Am 05.10.2004 um 00:21 schrieb Samuel Tardieu:
"Bert" == Bert Freudenberg bert@impara.de writes:
Bert> You should not be updating from the unstable stream, then. We Bert> *will* modify it. For example, the best way to get a couple of Bert> additions in that we missed when grabbing the Squeakland changes Bert> is to just insert them in the right place a hundred updates Bert> back.
Well, it depends of what you (harvesters) want. I use the unstable stream because this way, while I do my development, I can easily test the latest enhancements made to the image, review fixes and fix bugs when I want to distract myself from "serious" work. Restarting from an empty 3.8alpha and reloading the updates and reinstall the latest version of the tools I use to fix bugs is likely to be much less frequent if it is not in my work environment.
Moreover, after having been developing free software for about 13 years now, I strongly believe that the best software you can deliver is the one you use yourself for your daily work.
Also, if I find a bug for which I can find a workaround easily while working in a stable image, I am likely to use this workaround rather than fixing the bug if I am in a hurry because it may have already been fixed in an unstable update already that is not installed in my image.
I understand that this may be easier to remove the update or to fix the update stream back in time as of today, but this makes it very hard for other people to follow it. I do not know the harvesting process so I cannot comment on its effectiveness, but maybe it would be a good idea to stop for a few days and concentrate on a way to ease the harvester's hard job to allow them to create a new update from a changeset in one click or so (doesn't that exist already?).
To make it clear: my request for successive unmodified updates is not a rant, this is a plea for better development practices :)
Sam
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam
Samuel Tardieu sam@rfc1149.net wrote:
Marcus> We published a faulty update 6281Zip-extract-folder. This has Marcus> now been removed from the unstable stream. So you need to Marcus> re-update a 3.8a-unstable with an update number smaller than Marcus> 6281 to get a working version.
Marcus,
could you please add a new update which *reverts* the previous one? The update stream should not be modified afterwards except if a change broke the ability to update itself.
As far as I am concerned, I have tons of things in my image and I cannot revert to a previous update number as easily, and I suspect I'm not the only one.
The update modifies only one method so it's quite simple to revert that back to the previous version and things work as they should again. Karl
The update modifies only one method so it's quite simple to revert that back to the previous version and things work as they should again. Karl
Yes karl this is true. but this means creating a cs, fixing its name, connecting to the ftp, editing the list, uploading.... while Sam can fix its image in one revert click. So if someone provide a cs I can do it but I'm terribly busy now and dead tired.
Stef
"Stéphane" == stéphane ducasse ducasse@iam.unibe.ch writes:
Stéphane> So if someone provide a cs I can do it
Just did it :)
Thanks in advance Stéphane.
Sam
Am 05.10.2004 um 00:44 schrieb Samuel Tardieu:
"Stéphane" == stéphane ducasse ducasse@iam.unibe.ch writes:
Stéphane> So if someone provide a cs I can do it
Just did it :)
Thanks in advance Stéphane.
But to be clear: We will *not* garentee anything about the unstable update stream. It is unstable, not fixed, can result in a crashed image, contains changesets that will be removed a minute, a day or a week later.
It makes no sense to treat the unstable update stream as a stable update stream. Not.
Marcus
"Marcus" == Marcus Denker denker@iam.unibe.ch writes:
Marcus> It makes no sense to treat the unstable update stream as a Marcus> stable update stream. Not.
As I understood it, the unstable update stream was a stream where errors may slip in because more people can put things into it but can be corrected by further updates easily as several people have write access to it (as is Debian unstable). I didn't understand from previous threads that it was a stream where things may change back in time, but I believe you if you say that I have overlooked them.
Let's face the obvious consequence of this: it means that even aventurous people should not use the unstable update stream for a basis of their work, as they will have to reload their own workset in it every time it is desynched -- if only they notice it. Which means that the unstable version will not receive much testing with real applications being developed or deployed, which isn't good in my opinion as the probability that bugs slip in and don't get noticed until very late (if they do) are very high -- the work to stabilize the final product will be much more important and the result will probably be of a lower quality than a constantly tested unstable branch.
Sam
I think Marcus said it best that the main problem right now is that there has been a long time with the unstable stream getting updates and nothing moving to the stable stream just yet. If things moved to the stable stream every week or few days, you could probably just follow the stable stream and be able to contribute bug reports reasonably.
I'm not sure that being able to replace updates in place was necessarily the main point of the unstable stream. (I think the main point is just that it's quite unstable.) But I think the policy that updating-in-place is allowed in the unstable stream, and not allowed in the stable stream, is reasonable.
Anyway, I've mostly just let the update stream loose so that various harvesters are adding their updates directly. (I haven't had much time to contribute in the last couple weeks.) Naturally the big changes of m17n have required quite a bit of time to settle down. I'm basically waiting for word from somebody that the unstable stream feels reasonably stable enough to move everything to the stable stream... I think we should do this soon even if it's not super-stable.
- Doug
On Monday, October 4, 2004, at 07:54 PM, Samuel Tardieu wrote:
"Marcus" == Marcus Denker denker@iam.unibe.ch writes:
Marcus> It makes no sense to treat the unstable update stream as a Marcus> stable update stream. Not.
As I understood it, the unstable update stream was a stream where errors may slip in because more people can put things into it but can be corrected by further updates easily as several people have write access to it (as is Debian unstable). I didn't understand from previous threads that it was a stream where things may change back in time, but I believe you if you say that I have overlooked them.
Let's face the obvious consequence of this: it means that even aventurous people should not use the unstable update stream for a basis of their work, as they will have to reload their own workset in it every time it is desynched -- if only they notice it. Which means that the unstable version will not receive much testing with real applications being developed or deployed, which isn't good in my opinion as the probability that bugs slip in and don't get noticed until very late (if they do) are very high -- the work to stabilize the final product will be much more important and the result will probably be of a lower quality than a constantly tested unstable branch.
Sam
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam
2 - Sure, but that still doesn't imply 1. If you make it scary enough (don't guarantee you wont rm -r /), you will have as few users of the unstable stream as you want. Why not go for a compromise?
Maybe something along the lines of - 1. Unstable *can* have back changesets changed. This is the solution for update-load-breaking stuff, and it might also be used for other things that should stop being in the stream (like something that deletes people's Flaps). 2. Where simple and provided, a harmless changeset for reverting a bad previous update can be added to the stream as usual, if this helps people just update forward.
Daniel
Marcus Denker denker@iam.unibe.ch wrote: [1]
But to be clear: We will *not* garentee anything about the unstable update stream.
... [2]
It makes no sense to treat the unstable update stream as a stable update stream. Not.
hi samuel
now that I slept I do not understand if it makes sense to put your fixes in unstable: because you fixed your problems and other persons just have to load your fix. Else I would have to put it for a short amount of time and remove it. Am I correct?
Stef
On 5 oct. 04, at 00:44, Samuel Tardieu wrote:
"Stéphane" == stéphane ducasse ducasse@iam.unibe.ch writes:
Stéphane> So if someone provide a cs I can do it
Just did it :)
Thanks in advance Stéphane.
Sam
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam
"Stéphane" == stéphane ducasse ducasse@iam.unibe.ch writes:
Stéphane> I do not understand if it makes sense to put your fixes in Stéphane> unstable: because you fixed your problems and other persons Stéphane> just have to load your fix. Else I would have to put it for Stéphane> a short amount of time and remove it. Am I correct?
No: you can let this in the update stream forever, as:
- it will revert the bogus version installed by the bogus patch for people who caught it
- it will not change anything for people who didn't install the bogus patch, as the version of the concerned method is the same as before the bogus patch
Sam
stéphane ducasse wrote:
The update modifies only one method so it's quite simple to revert that back to the previous version and things work as they should again. Karl
Yes karl this is true. but this means creating a cs, fixing its name, connecting to the ftp, editing the list, uploading.... while Sam can fix its image in one revert click.
I think this is a question in principle: if many people are using the update stream, then there a many reverts of them in this case. And they have to know in advance, *what* to revert. And this is just the most easy case.
For me the question is, should I update to 3.8alpha unstable or just 3.8alpha for productive work? To leave at the bleeding edge and help a little with implicit testing.
If there would be an error in the unstable update stream from time to time, which will be reverted after a small time, then this wouldn't be a problem. But to work with the unstable stream, and always to be forced - to follow the ML very detailed, to know, *when* I have to (incrementally) generate a new image; - to generate a new image for each buggy update (which is very slow at the moment from 3.8alpha to 3.8alpha unstable) is frightend for me.
I think there is a tradeoff: - many unstable testers with more work for the unstable maintainers, or - less unstable testers with less work for the unstable maintainers.
Greetings Stephan
So if someone provide a cs I can do it but I'm terribly busy now and dead tired.
Stef
Am 05.10.2004 um 00:46 schrieb Stephan Rudlof:
For me the question is, should I update to 3.8alpha unstable or just 3.8alpha for productive work? To leave at the bleeding edge and help a little with implicit testing.
You should not use 3.8-unstable for productive work. Or if you do, you need to live with the consequences.
marcus
"Marcus" == Marcus Denker denker@iam.unibe.ch writes:
Marcus> You should not use 3.8-unstable for productive work. Or if you Marcus> do, you need to live with the consequences.
The consequences of 3.8-unstable need not be to jump backward in time. There can be a broken update from time to time, this is perfectly ok for bleeding edge software, which would then be corrected later by a new cumulative update.
Sam
Samuel Tardieu sam@rfc1149.net wrote:
"Marcus" == Marcus Denker denker@iam.unibe.ch writes:
Marcus> You should not use 3.8-unstable for productive work. Or if you Marcus> do, you need to live with the consequences.
The consequences of 3.8-unstable need not be to jump backward in time. There can be a broken update from time to time, this is perfectly ok for bleeding edge software, which would then be corrected later by a new cumulative update.
I agree with Sam here, the unstable stream could have cumulative updates etc. Avoiding having to start all over would be good for all cases where it's not a major bug that has no other possible solution but to start over again.
Karl
hi guys
I see the two faces of the problem. I work with unstable too but I save often and I have several images and I save my code on SqueakSource regularly too ;)
We should find the right way of doing things.
- First people responsible of the next version :) should start to move items in the stable stream.
- Second let me know what is the best for you for this particular fix.
- Third I think that this is difficult to have solution that works in all cases. So in general this would be easier not to be cumulative because this implies and order in changes that can be a pain to fix (believe in KCP this is nearly always the case and quite painful).
We need user of 3.8 unstable and I know that this is difficult.
Stef
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Brent Pinkney -
danielv＠tx.technion.ac.il -
Doug Way -
karl.ramberg＠chello.se -
Ken Causey -
Marcus Denker -
Samuel Tardieu -
Stephan Rudlof -
stéphane ducasse