On Thu, Mar 30, 2023, 06:45 Jacek Caban via Mingw-w64-public <
mingw-w64-public@lists.sourceforge.net> wrote:
> On 3/20/23 16:44, مهدي شينون wrote:
> > Hi everyone,
> >
> >
> > Could you please consider migrating your project to another host other
> > than sourcefoge where people could file bugs, propose changes and
> > discuss things (like GitHub ot GitLab).
> >
> > Using mailing-list for that is a way that's not suitable for young
> > generation (including me).
> >
> > Many people try to report bugs or propose changes but ended up ignored
> > because of this insist on using this outdated technology!
>
>
> We had similar talks in Wine for years and we finally decided decided to
> migrate to Gitlab last year. I think it was a good choice. We had it
> running parallel to ML as an experiment first, here is the summary:
>
> https://www.winehq.org/pipermail/wine-devel/2022-June/220008.html
>
> I think most of it would apply to mingw-w64 as well. I'd like to
> especially point CI: Gitlab makes it easy to set up CI and mingw-w64
> could really use one. It's esp. nice for reviewers: by the time you look
> at the patch, you already know that it doesn't break the build.
>
The use of a hosted solution vs making lists for patches is orthogonal to
not using SF. We could use any of the many services SF offers, and I pushed
this hard over the years, but people like mailing list patches. Part of it
is old habits, part of it is accessibility. Patch commenting on a website
with markdown is neat and useful, but not very accessible.
As for CI, remember that to have effective CI for us requires building the
whole toolchain. We used to do this daily with a buildbot service set up by
Mook and me, served by ReactOS, and run on donated hardware. Mook left,
react stopped giving us the server, and donors stopped donating.
I'm working with MJW to get a builder running on the SW BB. That should
take care of this requirement, but mind you that native builds can take
days to finish.
Wine uses self-hosted Gitlab instance, which solves the problem of
> dependence on third party host. Having its own self-hosted instance just
> for mingw-w64 would probably be too much overhead for mingw-w64 project,
> so if we decided to migrate, we'd need to pick one of externally hosted
> solutions.
BTW, SF mailing lists are especially not friendly for patches with its
> automatic footer messing inline patches and some attachments being
> silently dropped, depending on their extensions.
That's configurable. If there's a mime type that needs adding, I can add it.
That combined with
> other controversies (see https://en.wikipedia.org/wiki/SourceForge
> Controversies paragraph) makes me think that SF is not an optimal host
> for the project.
>
That's very old news, and has since been rectified. The reality is that the
SF administrative staff has been incredibly helpful to us over the years,
they are easily reachable, and they believe in what we do.
> Could you also port the project to a better buildsystem, like cmake or
> > meson.
> >
> > Autotools is not a buildsystem to choose to develop for Windows.
>
> The honest true is that autotools work well for a number of people,
> mostly those who cross compile mingw-w64. This does not seem to be true
> when building natively on Windows. I don't have experience with building
> on Windows (so I'm one of those for whom it works well), but I think
> that if there is anything we can do to improve native experience, we
> should seriously consider it. Windows support should obviously be
> important for the project. I'd be open to discuss changing build system,
> but the bottom line is that it's a lot of work, it's not something we
> can do easily.
>
As I pointed out previously, the use of auto tools by mingw-w64 doesn't
stop anyone from using whatever they want in their own project. If you're
building mingw-w64, you're building gcc anyway, so what difference does it
make? You need a GNU environment (that's the G in our name after all!), so
running a configure script isn't really an additional requirement. Whereas
cmake would absolutely be a new requirement.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
