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

[Daniel Stonier]

Seems like would like to both streamline the bugfixing process for
broken links - excellent!

Just copying some of the relevant points from the discussion below.

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

A link for you! Eros (embedded ros): http://www.ros.org/wiki/eros

Even though its not really embedded, its cross-compiling, so that came
under the embedded subproject for ros.

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

I'm not too worried about how fast the uploads take to spread across
mirrors. 30mins or 24hrs, there is always going to be some period of
delay, and incorporating the time for the bugfix to float upwards from
discovery to mailing list to response to fix, I think that is
relatively ok. If needs be, I can apply patches in eros that can
handle things if a situation is pending for a while (as I am doing now
for libpng and postgresql). I just dont want to maintain these long
term and ideally, other users outside ros should benefit from these as
well.

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

That's not a bad idea, much better than thinking about trying to
supply binaries.

Some other thoughts...especially on being able to communicate problems
when they arise.

Is there an official package maintainer list for mingw_cross? I can't
find anything in the downloaded files, nor on the website. It would be
nice to be able to ping the maintainer along with the list as soon as
a problem comes up. Perhaps if the maintainer had an email address at
the top of the relevant .mk file?

Does mingw cross maintain an issue tracker? That would be really
useful in identifying what problems are current, what needs acting on,
what version it is relevant to etc without having to pore through the
mailing list. Especially with regards to broken link problems.

If broken link fixes are simply a matter of link location (i.e.
checksum hasn't changed), then I imagine we could shortcut these
bugfixes into the stable branch without a full test (as opposed to
those with version changes). Would this be feasible?

Cheers,
Daniel Stonier.

>> 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
> ---<<(())>>---
>
>



-- 
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin Robot: http://www.yujinrobot.com/
Embedded Ros : http://www.ros.org/wiki/eros
Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl