Daniel Stonier schrieb:
I just added it:
(Sorry for the late reply.)
Feel free to remind me on starting a new release whenever you
> 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
think this is necessary.
As you have seen in the latest release, this might take a bit
longer than expected, but I currently don't see a way to speed
this up without sacrificing quality.
No, there currently no such thing. Of course there are some people
> 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?
taking more care of some packages than of other packages. But the
mailing list works quite well in that regard: The fastest person
will fix it.
I agree that an issue tracker might be sensible. However, hard issues
> 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.
like broken links should not be part of it. Instead, those have to
be fixed immediately, accompanied by a new release. That is, we'll
have to _fix_ the slowness rather than "managing" it.
So in the end, the issue tracker would mostly serve for reviewing
patches, and that already works quite well on the mailing list.
However, when the project grows and we have a lot more than 3 people
with push privileges, things will be different.
Indeed, that's the plan.
> 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?