winetest: build & publishing
Hi folks, I've checked the build this morning on SF, and it looks beautiful! So let's review the possible problems still outstanding: 1. Build Info Feri want to move that in the resources, with good reason. This will probably affect you very little, but needs to be done. We can still keep it in the .zip file (it is tiny) as it's a lot easier accessible for others. However, if we do that, the file will need to use DOS line ends, as this file will probably be viewed by folks on Windows boxes. Anyway, from your point of view it will probably mean a 'unix2dos' and a 'cp' before the build. 2. Uploading to SF This works nice now, but I'm afraid it may not when we have more than one person doing it. Namely, a release needs to be created, will that not fail if it already exists? Can we check that? If that's a problem, how are we going to deal with it? Kevin, can you please try to see if what happens if you upload two files (with differents sfutils invocations) into the same release? 3. Downloading from SF I just realized there is a time delay for the uploads to be propagated to the mirrors. What URL are we going to use for downloading? How long are we going to allow for the propagation to happen? Anyone has experience with this? 4. Release lifetime It would be nice to have the "WineTest Files" package visible on SF. I have made it so for testing purposes now. However, it will become ugly soon, because we don't hide the old releases. We can hide the entire package, and that would solve the ugliness problem, but it would be much nicer to have an automatic way of hiding old releases, and having just the latest releases visible. Can we maybe modify the sfutils to do this for us? We are very close on this front. I'm very happy with the state of things right now, I hope we can resolve these in a few days. -- Dimi.
Dimitrie O. Paun wrote:
2. Uploading to SF This works nice now, but I'm afraid it may not when we have more than one person doing it. Namely, a release needs to be created, will that not fail if it already exists? Can we check that? If that's a problem, how are we going to deal with it? Kevin, can you please try to see if what happens if you upload two files (with differents sfutils invocations) into the same release?
Can you also upload the exe? Ferenc touched this issue slightly - if we want to point (maybe very novice) users to a way to contribute to Wine - commandline option may be hard to understand. A zipped file can also be an obstacle. It's very neat just to click "open" on an exe compared to unpacking a zip. regards, Jakob
Jakob Eriksson <jakov(a)vmlinux.org> writes:
Dimitrie O. Paun wrote:
2. Uploading to SF This works nice now, but I'm afraid it may not when we have more than one person doing it. Namely, a release needs to be created, will that not fail if it already exists? Can we check that? If that's a problem, how are we going to deal with it? Kevin, can you please try to see if what happens if you upload two files (with differents sfutils invocations) into the same release?
Can you also upload the exe?
Ferenc touched this issue slightly - if we want to point (maybe very novice) users to a way to contribute to Wine - commandline option may be hard to understand. A zipped file can also be an obstacle. It's very neat just to click "open" on an exe compared to unpacking a zip.
Yes, I think it's a valid concern. I can implement an option in winetest to dump the build info or whatever; this way a upx-packed .exe could serve well while being totally transparent. -- Feri.
On April 23, 2004 10:01 pm, Ferenc Wagner wrote:
Yes, I think it's a valid concern. I can implement an option in winetest to dump the build info or whatever; this way a upx-packed .exe could serve well while being totally transparent.
I think it's a valid thing as well, but please let's wait a bit until we eliminate all this variability we have before we go ahead and introduce yet another potential problem. Meanwhile, maybe Kevin can also upload to SF a non zipped .exe for people that just want to test occasionally. Once the dust settles, and we get a handle on the new system, we can gradually introduce changes in a more controlled manner. -- Dimi.
Dimitrie O. Paun wrote:
On April 23, 2004 10:01 pm, Ferenc Wagner wrote:
Yes, I think it's a valid concern. I can implement an option in winetest to dump the build info or whatever; this way a upx-packed .exe could serve well while being totally transparent.
I think it's a valid thing as well, but please let's wait a bit until we eliminate all this variability we have before we go ahead and introduce yet another potential problem. Meanwhile, maybe Kevin can also upload to SF a non zipped .exe for people that just want to test occasionally. Once the dust settles, and
This is what I'm mostly after, could you please Kevin? regards, Jakob
On Saturday 24 April 2004 09:14 am, Jakob Eriksson wrote:
I think it's a valid thing as well, but please let's wait a bit until we eliminate all this variability we have before we go ahead and introduce yet another potential problem. Meanwhile, maybe Kevin can also upload to SF a non zipped .exe for people that just want to test occasionally. Once the dust settles, and
This is what I'm mostly after, could you please Kevin?
As of last night, my build includes a non-zipped exe
On Friday 23 April 2004 10:55 am, Dimitrie O. Paun wrote:
1. Build Info Feri want to move that in the resources, with good reason. This will probably affect you very little, but needs to be done. We can still keep it in the .zip file (it is tiny) as it's a lot easier accessible for others. However, if we do that, the file will need to use DOS line ends, as this file will probably be viewed by folks on Windows boxes. Anyway, from your point of view it will probably mean a 'unix2dos' and a 'cp' before the build.
No big deal, I'll make this change once there is a method in place
2. Uploading to SF This works nice now, but I'm afraid it may not when we have more than one person doing it. Namely, a release needs to be created, will that not fail if it already exists? Can we check that? If that's a problem, how are we going to deal with it? Kevin, can you please try to see if what happens if you upload two files (with differents sfutils invocations) into the same release?
Creating a release that already exists will not result in an error, for example when I was first working on this the release creation worked, but the file upload did not..once this was fixed I ran again, and the release was simply overwritten but as no files were already attached, I'm not sure if it will simply add files or replace them..I'll check on this later
3. Downloading from SF I just realized there is a time delay for the uploads to be propagated to the mirrors. What URL are we going to use for downloading? How long are we going to allow for the propagation to happen? Anyone has experience with this?
My only experience with automated downloads from sourceforge are from Portage in Gentoo..they handle it using a url like mirror://sourceforge/project/filename and use some method of randomly determing a mirror to attempt, if that fails it tries another mirror, etc until success
4. Release lifetime It would be nice to have the "WineTest Files" package visible on SF. I have made it so for testing purposes now. However, it will become ugly soon, because we don't hide the old releases. We can hide the entire package, and that would solve the ugliness problem, but it would be much nicer to have an automatic way of hiding old releases, and having just the latest releases visible. Can we maybe modify the sfutils to do this for us?
When publishing with sfutils its possible to flag the release as hidden, but I'm not sure if you can flag an existing release without overwriting it..I'll look into this as well
participants (5)
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Ferenc Wagner -
Jakob Eriksson -
Kevin Koltzau