Hi,
I think that the release plans for TDE are probably to rethink, or to do in another way.
As an example, most projects have their users use the stable releases, but in TDE, as R14.0.0 was not 100% up to what users expect, many of those switched up to Slavek's preliminary stable builds. This is not bad in itself to use unstable versions for testing purposes, but I do not think that it is the best idea to use it on a production system.
Also, as it is the case now, R14.0.2 is not said to be released, but you can see users complaining (with reasons) that it is very slow to update to R14.0.2., mostly because mirrors are not yet in sync with the main server.
I don't know enough about how software repos work, but I think that the new release should be blocked for a moment and then be available to users only when everything is ready and in sync on mirrors.
This would allow:
1. A more consistent release plan
2.Stop having to deal with users saying that they get kind-of error 404, or ultra slow download speed
3.Reduce Tim's bandwidth costs and load on its servers
What do you think?
Have a great day!
-Alexandre
On Wednesday 25 November 2015 13:19:22 Alexandre wrote:
Hi,
I think that the release plans for TDE are probably to rethink, or to do in another way.
As an example, most projects have their users use the stable releases, but in TDE, as R14.0.0 was not 100% up to what users expect, many of those switched up to Slavek's preliminary stable builds. This is not bad in itself to use unstable versions for testing purposes, but I do not think that it is the best idea to use it on a production system.
Also, as it is the case now, R14.0.2 is not said to be released, but you can see users complaining (with reasons) that it is very slow to update to R14.0.2., mostly because mirrors are not yet in sync with the main server.
I don't know enough about how software repos work, but I think that the new release should be blocked for a moment and then be available to users only when everything is ready and in sync on mirrors.
This would allow:
- A more consistent release plan
2.Stop having to deal with users saying that they get kind-of error 404, or ultra slow download speed
3.Reduce Tim's bandwidth costs and load on its servers
What do you think?
I don't see a problem! Slávek's stuff isn't "unstable". It is release ready, just not yet released.
Even a large project like Debian sometimes has mirror-syncing "problems".
The slowness problem has been solved as Slávek said. Which will also solve the syncing problem because the redirector will choose the mirror. The only problem is, as Slávek says on the user's list, that not everyone is yet using mirror.ppa.trinitydesktop.org as is now recommended. https://www.trinitydesktop.org/ https://wiki.trinitydesktop.org/DebianInstall (For Debian) (Mutatis mutandis.)
Lisi
Dne st 25. listopadu 2015 Alexandre napsal(a):
Hi,
I think that the release plans for TDE are probably to rethink, or to do in another way.
In summary, I would say: changes successfully underway.
As an example, most projects have their users use the stable releases, but in TDE, as R14.0.0 was not 100% up to what users expect, many of those switched up to Slavek's preliminary stable builds. This is not bad in itself to use unstable versions for testing purposes, but I do not think that it is the best idea to use it on a production system.
There is not much to say. There are three sources:
1) Stable release - there are many users who firmly holds only stable release.
2) Preliminary stable builds == source for maintenance releases - there is the number of users who use this resource, because it offers a good combination of stability and bug fixes. The principle here will always bug fixes faster than the stable releases. Likewise, there will always be faster support for new versions of the distributions.
3) Nightly builds == source for major releases - is especially useful for developers and testers.
This is already a time-proven model. I believe that there is no reason to change that.
Also, as it is the case now, R14.0.2 is not said to be released, but you can see users complaining (with reasons) that it is very slow to update to R14.0.2., mostly because mirrors are not yet in sync with the main server.
I don't know enough about how software repos work, but I think that the new release should be blocked for a moment and then be available to users only when everything is ready and in sync on mirrors.
This would allow:
- A more consistent release plan
2.Stop having to deal with users saying that they get kind-of error 404, or ultra slow download speed
3.Reduce Tim's bandwidth costs and load on its servers
What do you think?
There were important changes, for which I am hoping will have immediate benefits for R14.0.2. New redirector on mirror.ppa.trinitydesktop.org is prepared to deal with the usual problems in the release of a new version:
1) New version is offered for download at the moment when the package lists are updated on a mirror. This also relates with frequent error 404.
2) Overloaded line to the master server. On the new redirector is also local cache that is prefilled packages for most of the Debian/Ubuntu distributions. Thank to this, packages are available on quick line, even if they are not yet fully on the mirrors.
As it turned out, the problem remained for users who have in their apt sources stated original redirector on the master server. However, at present, together with Tim we are trying to treat this problem!
Have a great day!
-Alexandre
On Wed November 25 2015 10:12:02 Slávek Banko wrote:
As it turned out, the problem remained for users who have in their apt sources stated original redirector on the master server. However, at present, together with Tim we are trying to treat this problem!
Maybe have the old name give only an error/informational message and have the redirector send users to the master server when needed only under a new name for the master server?
--Mike
Dne st 25. listopadu 2015 Mike Bird napsal(a):
Maybe have the old name give only an error/informational message and have the redirector send users to the master server when needed only under a new name for the master server?
This would be difficult for several reasons. Users usually do not go to a redirector by browser, but automatically - apt, yum, etc. In addition on the master server are available sources that are not part of the mirror system.
With Tim we try to enhance original redirector to allow redirect users not only to the standard mirrors, but also to a new redirector - in order to take advantage of packages available in the local cache on a new redirector, instead of downloading them from the master server. This should enable to take advantage of new redirector, without causing complications to users.
-
Alexandre -
Lisi Reisz -
Mike Bird -
Slávek Banko