Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?
On 10/28/2012 06:01, Erik van Pienbroek wrote: > Jacek Caban schreef op do 25-10-2012 om 14:51 [+0200]: >> A few more words about ensuring stability: We mostly know what risky >> changes have been made and we occasionally hear back from users when >> something breaks. I myself would know quickly if something really bad >> happened. I do Mozilla code base builds as cron nightly job and update >> mingw-w64 every few days on that box. It exercises headers and crt >> pretty heavily, so it's quite a compelling test. Now, if we had a few >> such projects (eg. regular Qt builds) that we can easily ensure to be >> working correctly before each release, that's a pretty good test case. >> Buildbot would be great for that, but so would be active >> users/developers that would test builds on regular basis, or at least >> after tagging for RC. Same for packagers, if it could be coordinated >> with them to ensure RC works for them, that's probably enough for release. > > Perhaps I can help in this area. In Fedora we currently have over 125 > different mingw packages and we are frequently pushing updated mingw-w64 > trunk snapshots to the Fedora development branch. I could try to write a > script which tries to mass rebuild all these packages against recent > mingw-w64 snapshots and report any breakage automatically. This script > could then be run periodically (say once every week) so regressions can > be spotted relatively soon. For this I need to find one or more machines > where this script can be executed periodically but that shouldn't be too > hard of a problem. > > Kind regards, > > Erik van Pienbroek Does that include several large C++ programs? I need to test a patch for trunk headers. If so, I can push in the less invasive change and hopefully it should not affect any builds. signature.asc Description: OpenPGP digital signature -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?
Jacek Caban schreef op do 25-10-2012 om 14:51 [+0200]: > A few more words about ensuring stability: We mostly know what risky > changes have been made and we occasionally hear back from users when > something breaks. I myself would know quickly if something really bad > happened. I do Mozilla code base builds as cron nightly job and update > mingw-w64 every few days on that box. It exercises headers and crt > pretty heavily, so it's quite a compelling test. Now, if we had a few > such projects (eg. regular Qt builds) that we can easily ensure to be > working correctly before each release, that's a pretty good test case. > Buildbot would be great for that, but so would be active > users/developers that would test builds on regular basis, or at least > after tagging for RC. Same for packagers, if it could be coordinated > with them to ensure RC works for them, that's probably enough for release. Perhaps I can help in this area. In Fedora we currently have over 125 different mingw packages and we are frequently pushing updated mingw-w64 trunk snapshots to the Fedora development branch. I could try to write a script which tries to mass rebuild all these packages against recent mingw-w64 snapshots and report any breakage automatically. This script could then be run periodically (say once every week) so regressions can be spotted relatively soon. For this I need to find one or more machines where this script can be executed periodically but that shouldn't be too hard of a problem. Kind regards, Erik van Pienbroek -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?
Kai Tietz schreef op wo 24-10-2012 om 21:19 [+0200]: > Hello everybody, > > I want to raise this discussion on public mailing-list, as mingw-w64's > release-cycle might be also of interest to some of our users. Right > now we do the major-release by gut feeling with a background plan > about features new version shall include. Now I got the request to > do major release like some other ventures - eg gcc, binutils - after a > fixed time-line. For example if we would decide for a one-year > release-cycle, it would Mean that we work about 6 - 8 months on new > features, then we switch to stabelizing phase for 3 months, and then > doing major-version branching and doing just bug-fixing on that > branch. > Another approach would be to do branching only if we are > feature-complete for one version. That of course means we should > switch from gut-feeling to more detailed feature-plan. > > So I would like to get your opinion. You might have complete > different opinion about planning mingw-w64's release-cycles, so don't > hesitate to tell us what you think about this subject. Hi, Before I start I would like to point out that the points mentioned below aren't meant as criticism, but they are areas which I think can potentially be improved. For the TL;DR variant, see the bottom of this mail for my conclusion >From my packager/distributor point of view I would like to vouch for the release-early-release-often strategy. This means more frequent releases. Version 2.0 of mingw-w64 was already released over a year ago. In the past year the v2 branch has seen several backports and several releases. However, the difficult thing is that these new releases aren't announced on the website or on the mailing list at all. This makes it hard for packagers and other users to find out if a new version of mingw-w64 is available. Also, if people want to know what has changed between releases then they have are forced to check the SVN repo history. Another thing that I consider is missing are unstable releases. In Fedora RPM packages always need to have a version number and a release number. For mingw-w64 releases based on the v2 branch this is simple (for example: version=2.0.7, release=1). However as there are no unstable mingw-w64 releases being created for the trunk branch (and we in Fedora want to provide packages based on the trunk branch) we had to invent our own version number in Fedora. We want to make sure that whenever users want to update from the current trunk version to the final 3.0 release (once it will be released) that RPM thinks that the final 3.0 release is more recent than the current trunk version and allows the update. Because of this reason we're currently building our mingw-w64 packages using version=2.0.999 and release=0.1.trunk.20121023. With this pattern users can see that we're using a trunk snapshot dated 20121023 and the upgrade path will work when mingw-w64 version 3.0 will be released. In the end this custom version number is confusing to end-users as on the mingw-w64 website there are no references to version 2.0.999. One way to solve this issue is to publish unstable releases from time to time. To sum it up I would like to propose the following: * Publish unstable releases (from the trunk branch) periodically (this can be time based) * Once the trunk has reached a certain level of stability/new set of features branch it and make a stable release * When regressions are detected in a stable branch publish a new stable release * Give more visibility to new releases on the website and the mailing list and include a global outline of the most important changes A potential versioning scheme for this could be the GNOME one. They're using uneven major version numbers to mark unstable releases (like 3.5.x) and even major version numbers to mark stable releases (like 3.6.x). Perhaps something similar can be used for mingw-w64 too Kind regards, Erik van Pienbroek -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major
On 10/27/2012 19:33, Corinna Vinschen wrote: > On Oct 26 21:11, Herb Thompson wrote: >> On 2012-10-26 1:35 PM, Earnie Boyd wrote: >>> On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem >>> wrote: Also, can someone clarify that you only need to be able to provider the source when asked for it vs providing it in some public place, which might not even be reachable everywhere in the world? > > Per GPLv2 and v3, this requires a *written* offer to provide the > source code when asked for. GPLv3 also restricts this right even > more, see > https://www.gnu.org/licenses/old-licenses/gpl-2.0.html, section 3b. > https://www.gnu.org/licenses/gpl.html, section 6c (and 6b). > > So, usually you provide source code in a public place. > > I'm still puzzled, though, why providing source code is such a hassle, > apparently. After all, this is called open source for a reason. > > Again, for the third time, Open Source is *not* made for the developer > in the first place. The idea is to grant the *user* the right to access > the source code of the application she's using, and the GPL is designed > this way to make sure that this right isn't conveniently forgotten along > the way, just because a developer is too lazy (and we devs *are* lazy, > isn't it?) to create a neat source package and to upload it in a > *visible* way to the same place as the object package. This. Unfortunately some developers too have some entitlement issues, too many think Free means do whatever you want, including enslaving the downstream users, not sharing the Freedom they received. Sure, other licenses have their uses in other areas, but with GPL, the beauty of it is that it does not allow such hypocrisy. signature.asc Description: OpenPGP digital signature -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major
On Oct 26 21:11, Herb Thompson wrote: > On 2012-10-26 1:35 PM, Earnie Boyd wrote: > > On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem > > wrote: > >> > >> Also, can someone clarify that you only need to be able to provider the > >> source when asked for it vs providing it in some public place, which might > >> not even be reachable everywhere in the world? Per GPLv2 and v3, this requires a *written* offer to provide the source code when asked for. GPLv3 also restricts this right even more, see https://www.gnu.org/licenses/old-licenses/gpl-2.0.html, section 3b. https://www.gnu.org/licenses/gpl.html, section 6c (and 6b). So, usually you provide source code in a public place. I'm still puzzled, though, why providing source code is such a hassle, apparently. After all, this is called open source for a reason. Again, for the third time, Open Source is *not* made for the developer in the first place. The idea is to grant the *user* the right to access the source code of the application she's using, and the GPL is designed this way to make sure that this right isn't conveniently forgotten along the way, just because a developer is too lazy (and we devs *are* lazy, isn't it?) to create a neat source package and to upload it in a *visible* way to the same place as the object package. > > AIUI, at least for v2 of the license, you need to be able to provide > > the source for the exact version the user has in possession via the > > same media that the binary was delivered when asked for it. It is > > easier if you just deliver the source and the same time you deliver > > the binary since you can tell the user he already has the source. > > > > Not that this thread needs yet another opinion, but this is an > interesting and important discussion. > > So two minor comments: > > (1) As I see it, the distinction between "distribute" and "provide" is > important. All of the major Linux distros I'm acquainted with (e.g. EL, > Suse, Ubuntu, etc) *distribute* libstdc++.so via ISO images that do not > include the source code, but *provide* the source code via some other > means (that isn't always very visible to the end user). > > (2) Depending on how one interprets "via the same media that the binary > was delivered", I'm not sure that all of the major distros would achieve > that. If for example I obtain a libstdc++.so via an Ubuntu ISO, I'm not > sure I could get the source code in the same form. GPLv2 is older than the Internet. At the time the idea of bulk data interchange was more or less restricted to physical media. Read section 3 of the "terms and conditions for copying" here: https://www.gnu.org/licenses/old-licenses/gpl-2.0.html Today a "medium customarily used for software interchange" is the Internet. If you pull the binary ISO from the Fedora project page, everything's ok if you also can pull the source packages from the same page. Or, FWIW, it's mirrors. Corinna -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
