Re: [Mingw-cross-env-list] Broken Links

[Volker Grabsch]

Daniel Stonier schrieb:
> (http://www.willowgarage.com/pages/software/ros-platform). I've got
> this set up now and starting to get users.

That's great!

> However - in under a month,
> two broken download links (and I see the last version upgrade was also
> due to a broken link) have meant that the stable mingw-2.18 release is
> starting to look unusable. And I imagine this problem will grow with
> increasing frequency as more packages are being added to mingw_cross
> every week.

Yes, there are two which some package maintainers simply don't
get right:

a) providing permanent URLs to their releases

b) releasing a bugfix unter another version number or
   at least another filename as the already released version.

This doesn't happen too often, but it happens and I agree that
we have to cope with it.

> Currently the advised solution I see on email is just use the
> development branch.

I'm soory that this looked as it was meant to be a serious
solution. It isn't. It's just a quick workaround.

A better solution would be to release mingw-cross-env more
often. That's one thing we're working on.

Also, providing some kind of package mirror was already under
discussion, which would ensure that the tarballs are always
downloadable. Note that this already happens for most packages,
as we provide a secondary URL to mirrors that have proven to
be more stable than the original download source. This is
completely transparent to the user.

> But I need to
> be able to know that all our users are on the same code base (makes it
> easier to resolve problems)

This is what we want, too. Moreover, we ensure that we get
exactly those package tarballs we expect but checking their
SHA1 checksum.

> So, what's a practical way of dealing with this? Possibly:
> 
> 1) Bugfix broken download links in the stable release as soon as they
> happen rather than just pointing people to the development branch.

Such bugfixes require some time, as the new download URL will have
to be stable - otherwise we'd fix it over and over again, which
would quickly become a maintainance nightmare.

If you find some time to help out here, by all means please do so!

Nevertheless, we'll have to release more often, in particular
immediately after a broken link.

> 2) Have a repository for mingw that holds sources for packages that mingw 
> uses.

See above. This already happens by trying to find stable mirrors
for each package. We're currently quite good at that, but we don't
have it for all packages. So a new central mirror for at least
those packages might be helpful.

However, I think that having one big mirror for _all_ packages would
be overkill, because the requirement to upload everything to that
point would slow down releases. Also, big packages like Qt already
provide very fast and stable download sites.

Nevertheless, feel free to provide such a mirror in case you think
it is necessary for your project. :-)

> 3) I create binary snapshots for my users (hack because its only a
> partial solution as I can't do for all platforms and I don't know how
> many packages my users will want/need).

I also don't think this is a good idea in the long run.

> Can we find a practical resolution to make this better?

First of all, I fully agree that we need more timely "bugfix"
releases that fix download URLs etc.  Since those don't require
much testing, the only bottleneck is missing automatization.
Human intervention is mostly needed because

A) Freshmeat doesn't provide their automatic release
   API anymore,

B) an upload to Savannah takes up to 24 hours until it
   is available on all mirrors.

Here, point A) wouldn't be that bad if it didn't require
the waiting period introduced by B). For B), I'm still
looking for a good solution. [1]

In addition, we need more regular releases. However, those
require

C) a testing phase which can take anything between two days
   and two weeks.

Maybe we should rely more on Tony's extensive testing and
release immediately after he says okay. This would shorten
the release preparation time, but also increase the risk
that the release will fail on exotic systems and/or
configurations, which would require an extra release
and thus mean more work if that happens too often.

These are my thoughts so far.


Greets,
Volker



[1] Here's an example of how this would look like:
    https://bitbucket.org/vog/mingw-cross-env/downloads

    Unfortunately, there's seems to be no way to automate
    the upload. :-(

-- 
Volker Grabsch
---<<(())>>---