>> >> This is nice, but far from enough. There should be clear policy who from >> the team is responsible for release management, how often (approx.) you >> plan to release (e.g. 2 times a year or every month), if there is any >> public RC (and for how long before the planned final release), so >> community can test the RCs and take some testing off your shoulders etc. >> >> Community cannot help you if your process is unclear and/or does not >> offer >> any points where it can involve in an effective way. > > Well, this is exactly the point I want to come to. But to change > things need time and efforts. So I would welcome any contributor, > which wants to do packaging and pre-build release managing. > Volunteers are most welcome. We have to maintainers actually, which > are respnsible for that - at least they are claim for this - but > indeed I must admit that here some help would be greatly appreachated.
All right, as (almost) always on (almost) any open-source project :-) So I will try to take the glove from the floor: I am willing to participate on it to some degree (few hours a week, I have another job so this is 'just' hobby) if the team and community finds it beneficial. In my eyes the main problem is the difference between (large portion of) mingw-w64 users and mingw-w64 hackers and their view of "release". * Hackers want sources and be able to play with it and/or actively contribute. For them the "release" is a set of patches to gcc, binutils plus the W32API SDK headers and import libs. * Then there is a group of cross-compiling users who stand between and who generally cannot expect prebuilt toolchain (too many platforms) but want be able to get it as easily as possibly from the sources. For them the release is probably small set of packages which can be easily built. * A lot of mingw-w64 users who want to build for Windows from Windows (Actually it includes cross-compiling from w32 to w64 or vice versa but you get the point) or perhaps other platforms important enough to have pre-built binaries. For these, the release is the "zip"/"tgz"/"bz2" they can unpack and build their project. So if you accept my offer, I would see these as my main goals: (1) Help to find out (and possibly maintain or co-maintain) a release process and policies which would be acceptable for all groups, especially making it better for the group of "native builders" (as I am one of them so I understand them more). (2) Help in (re)organizing the directory structure of the download area and making it more accessible for newcomers. (3) If the time allows, help with packaging/maintaining Windows packages. (Depends how much time (1) and (2) would take and if you find it useful). Just something about me: I am professional developer, working mostly for other-then-Windows OSes in my work (usually Unix and unix-like), but with no or very limited cross-compiling experience. For my few hobby Windowish projects I was using mingw, then combination of mingw and mingw-w64 and today exclusively mingw-w64 for few years. Most of the project were small things for my own use, there is also mCtrl project hosted here on sourceforge (http://sourceforge.net/projects/mctrl/). (I recently did not have much time to work on it since I change my employer, but I am now returning to it again so no, it is not an abandoned project ;-). More about me can be found on linkedin: http://www.linkedin.com/profile/view?id=88607525 Regards Martin ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
