Re: [Qgis-developer] Four month cycle too fast
On 06/18/2014 11:34 PM, Andreas Neumann wrote: Hi, At the Swiss QGIS user meeting yesterday there were some discussions whether people can cope with the 4 month release schedule and there were a number of users who said that this way too fast for them. By the time they could properly test a release, the next release is already there. Bigger organizations (government organizations and bigger companies) have to test a release, package it with IT, test again. They often can't install QGIS themselves (don't have installation privileges) but have to ask IT to do it for them. This is a time-consuming process. I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. PostgreSQL has a yearly release cycle and it works really well I think - both for them as a project and for us as customers. Andreas Except Postgis does bugfix releases and doesn't cram as many new features. As discussed in great length in previous threads, it's the pace of new features that makes bugfix releases somewhat inplausible. I'm not saying that 4 months is right, what about alternating stable/experimental like GRASS? So that big orgs only think about every 8 months? Really a big org can decide to skip a release if they want. Every 6 is also possible, the key is timing, right now is a very good time to release to be ready for FOSS4g. Thanks for the feedback, since this the first attempt at the 4 month it's good to get some information from users. Thanks, Alex ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi, again +1 with Andreas. Alex, big corps are real people, trying to do their best to test qgis like every other community member, and also having to do support, training, packaging, deploying inside their corp. We often do not have teams of plenty members on QGIS. Skipping a version for user deployement is an option, but does not change anything in the fact that we have to closely follow every version and test it. If not, we have the load reported on next version. A too fast release cycle leads to the fact that qgis community looses those testers and contributors because they can't follow that.. Not sure we can afford that. 6 months or 8 months, with a longer Release candidate period is a good compromise to me. Also, rc period should not fall during holiday periods. For France, we have august, christmas and sometimes May to avoid. How about others? Maybe access stats of the internet site could give us an global view of those period of unactivity? Cheers, Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Four-month-cycle-too-fast-tp5146648p5146684.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Il 19/06/2014 10:32, Régis Haubourg ha scritto: Alex, big corps are real people, trying to do their best to test qgis Hi all. I acknowledge the problem, and I understand well its implications. I think a proper solution is not having longer release cycles (we had them before, without major improvements over the current situation), but backporting fixes over to a stable version, having more tests and QA. IMHO, this effort should be covered by big corps, who have the power and the interest to do it. I'm available to help organizing this if someone is interested. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
I'm going to learn more towards a longer dev cycle. 4 months open, 2 month feature freeze. Of course I'm also pro stable release but there is less need if you have more time to fix bugs. - Nathan On Thu, Jun 19, 2014 at 6:37 PM, Paolo Cavallini cavall...@faunalia.it wrote: Il 19/06/2014 10:32, Régis Haubourg ha scritto: Alex, big corps are real people, trying to do their best to test qgis Hi all. I acknowledge the problem, and I understand well its implications. I think a proper solution is not having longer release cycles (we had them before, without major improvements over the current situation), but backporting fixes over to a stable version, having more tests and QA. IMHO, this effort should be covered by big corps, who have the power and the interest to do it. I'm available to help organizing this if someone is interested. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Il 19/06/2014 10:51, Nathan Woodrow ha scritto: I'm going to learn more towards a longer dev cycle. 4 months open, 2 month feature freeze. we had that long ago, and it didn't work well. Of course I'm also pro stable release but there is less need if you have more time to fix bugs. late bugs will always be found, regardless of the time frame for testing. the only stable solution is maintaining stable branches with backporting, for which we need additional manpower (= money). All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
On Thu, Jun 19, 2014 at 11:00:45AM +0200, Paolo Cavallini wrote: Il 19/06/2014 10:51, Nathan Woodrow ha scritto: I'm going to learn more towards a longer dev cycle. 4 months open, 2 month feature freeze. we had that long ago, and it didn't work well. Of course I'm also pro stable release but there is less need if you have more time to fix bugs. late bugs will always be found, regardless of the time frame for testing. Agreed. Bugs are found by users, and users of an official release are a lot lot more than users of a development snapshot. Also, users of a stable release are a usually more than users of new releases. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi Andreas, On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote: I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. But the short release cycle is there to avoid the need of bugfix releases - because we learned in the past that we don't have enough (interested and skilled) people to maintain the backports and we also miss a scheme to test them before we apply them. And IMHO a year too long to wait for new features in a release anyway. Four months is a compromise between avoiding bugfix releases and getting new features released. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
I'm not sure I really like the just make new releases and avoid bug fixe releases kind of thinking. There are some places that can't roll out a whole new release due to possible bugs from major new features, and given how fast we move this can cause some real issues. We don't even have to bug fix until next release just do it for a short (1 month) period after the release, so you're dev cycle is like this: 6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. This means any bugs that might come up can be fixed, and we patch then we move on. There is really no need to make 2.x.5 releases, just one would normally be enough. I think the main thing is keeping the bug fix patches small so you don't affect to much code and is easier to spot where there might be issues. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. - Nathan On Jun 19, 2014 7:18 PM, Jürgen E. j...@norbit.de wrote: Hi Andreas, On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote: I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. But the short release cycle is there to avoid the need of bugfix releases - because we learned in the past that we don't have enough (interested and skilled) people to maintain the backports and we also miss a scheme to test them before we apply them. And IMHO a year too long to wait for new features in a release anyway. Four months is a compromise between avoiding bugfix releases and getting new features released. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
On Thu, Jun 19, 2014 at 07:32:17PM +1000, Nathan Woodrow wrote: I think the main thing is keeping the bug fix patches small so you don't affect to much code and is easier to spot where there might be issues. Agreed. When I spot a bug during development I often first fix it in the stable branches and than forward-port to master, to keep the bugfix isolated from the new feature. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi all, I really think we are going blind here about the bugfix or not bugfix release ! At present, it depends completely of the package maintainers. For example: * Under Windows : no bugfix * Under Debian : bug-fixed via branch release-2_2 * Ubuntugis-unstable : not bugfxied * opensuze : bugfixed I think * Mac OX : I do not know etc. NB: I may be wrong for some, please correct me :) And please note I really do not blame any packager. I know time is not a unlimited resource. I really think it is a pity not to have a bug fix release for some users, but to have it for others. I personaly tried the last week to create the build architecture under Windows 7, and almost suceeded (but still have some build errors..). I think once you have the architecture set up, it must not be so manpower demanding to run a bash script under Windows, Ubuntu, etc. and create a bug fix packages (but maybe I am wrong) ? For example, a Windows build is created automatically every week. I think the script can be used once every 4 months (or 6 ) to build the bugfix release, for example for release-2_2. Perhaps we need more documentation on how-to build pacakges for the main Linux distributions, Mac and Windows. It could be great to have a dedicated documentation repository on Github about building QGIS. The INSTALL file is a good start entry, but does not (yet) describe all the possibilities, and has no images, etc. What about having a packagers squad for each main OS, and not rely only on unique volonteers per OS ? I think the manpower is more lacking about documentation, bugfix release announce, communication about it, etc. Michael 2014-06-19 11:36 GMT+02:00 Sandro Santilli s...@keybit.net: On Thu, Jun 19, 2014 at 07:32:17PM +1000, Nathan Woodrow wrote: I think the main thing is keeping the bug fix patches small so you don't affect to much code and is easier to spot where there might be issues. Agreed. When I spot a bug during development I often first fix it in the stable branches and than forward-port to master, to keep the bugfix isolated from the new feature. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
I just want to clarify one thing about this discussion: we are not speaking about delaying the 2.4 release, which users are expecting in the next 48 hours, right? The current state of QGIS master could probably be better, but it's not worse than 2.2 (of course, that's a perception based on my workflows). So, please :), whether the release cycle needs to to be adjusted, or not, it shouldn't be decided and change within 48 hours of a publicly known release date. As much as bugs are a big issue for end users, being consistent with the user base is also pretty important. Math On Thu, Jun 19, 2014 at 1:34 PM, Andreas Neumann a.neum...@carto.net wrote: Hi, At the Swiss QGIS user meeting yesterday there were some discussions whether people can cope with the 4 month release schedule and there were a number of users who said that this way too fast for them. By the time they could properly test a release, the next release is already there. Bigger organizations (government organizations and bigger companies) have to test a release, package it with IT, test again. They often can't install QGIS themselves (don't have installation privileges) but have to ask IT to do it for them. This is a time-consuming process. I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. PostgreSQL has a yearly release cycle and it works really well I think - both for them as a project and for us as customers. Andreas ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi Nathan, On Thu, 19. Jun 2014 at 19:32:17 +1000, Nathan Woodrow wrote: I'm not sure I really like the just make new releases and avoid bug fixe releases kind of thinking. There are some places that can't roll out a whole new release due to possible bugs from major new features, and given how fast we move this can cause some real issues. I said compromise. I'm sure that I don't like it. It implies that it's not optimal. But I didn't have a better idea - and apparently I also miss all the new stuff in this discussion - feels like a dejavu. We don't even have to bug fix until next release just do it for a short (1 month) period after the release, so you're dev cycle is like this: That means packaging again and again - and that's what I want to avoid. But I thought about an automated release build when there are new commits in the release branch and a automated bugfix release after a some given period of time without any new commits. That period should be long enough to make it likely that potentially newly introduced issues by the bugfix are spotted and fixed (thereby restarting the period) before its over. And that without further doing except for the backported commit. But I didn't find time to do that yet. 6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. 7 months is not good as that would move the schedule into undesireable areas (like holidays) over time. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi, I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. This means that more developers will be able to work on paid bugfixing (e.g. 3-4 devs working each 1-2 weeks for each release). I think that this will help a lot to raise the quality. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Andreas Am 19.06.2014 09:18, schrieb Jürgen E. Fischer: Hi Andreas, On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote: I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. But the short release cycle is there to avoid the need of bugfix releases - because we learned in the past that we don't have enough (interested and skilled) people to maintain the backports and we also miss a scheme to test them before we apply them. And IMHO a year too long to wait for new features in a release anyway. Four months is a compromise between avoiding bugfix releases and getting new features released. Jürgen ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. The above mentioned resources could be used for maintaining a stable branch, and backporting. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Agreed fully: that's what Blocker category is for. All the best, and thanks for this important discussion. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. 7 months is not good as that would move the schedule into undesireable areas (like holidays) over time. I understand. Then why not go with 4 (1 month freeze) 1 month post release freeze. There only adds the extra month on the end to fix anything that might come up after that is bad. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) Of course I don't want to create heaps of more work for people but if cutting a release is a hard process then it really creates a sticky point in all this. We need to be able to release as easy as possible. What are the main problems/stoppers with having it fully automated? Do we need resources, VMs for each platform, etc? - Nathan Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hey Jurgen, 6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. 7 months is not good as that would move the schedule into undesireable areas (like holidays) over time. I understand. We could go with 4 (1 month freeze) 1 month post release freeze. There only adds the extra month on the end to fix anything that might come up after that is bad. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) Of course I don't want to create heaps of work for people but if cutting a release is a hard process then it really creates a sticky point in all this. We need to be able to release as easy as possible when ever we need, be that be weekly, monthly, yearly. It really should just be 1) point at branch 2) package. Even if the website lags behind. What are the main problems/stoppers with having it fully automated? Do we need resources, VMs for each platform, etc? - Nathan Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer On Thu, Jun 19, 2014 at 8:11 PM, Jürgen E. j...@norbit.de wrote: Hi Nathan, On Thu, 19. Jun 2014 at 19:32:17 +1000, Nathan Woodrow wrote: I'm not sure I really like the just make new releases and avoid bug fixe releases kind of thinking. There are some places that can't roll out a whole new release due to possible bugs from major new features, and given how fast we move this can cause some real issues. I said compromise. I'm sure that I don't like it. It implies that it's not optimal. But I didn't have a better idea - and apparently I also miss all the new stuff in this discussion - feels like a dejavu. We don't even have to bug fix until next release just do it for a short (1 month) period after the release, so you're dev cycle is like this: That means packaging again and again - and that's what I want to avoid. But I thought about an automated release build when there are new commits in the release branch and a automated bugfix release after a some given period of time without any new commits. That period should be long enough to make it likely that potentially newly introduced issues by the bugfix are spotted and fixed (thereby restarting the period) before its over. And that without further doing except for the backported commit. But I didn't find time to do that yet. 6 month dev (including ~1 month freeze) - release - 1 month post release freeze - release a bug fix release if needed - move on. 7 months is not good as that would move the schedule into undesireable areas (like holidays) over time. Packaging for each platform is up to that maintainer but that should be automated as much as possible really otherwise making releases is too hard. Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work Exactly. There is no point having a release if people can't use it. It will leave a bad taste, especially if it's rolled out to organizations. Nothing will ever be perfect but any blockers (provided that they are) need to be fixed before release. There was one the other day where you couldn't add a new column which is pretty major. - Nathan Andreas Am 19.06.2014 09:18, schrieb Jürgen E. Fischer: Hi Andreas, On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote: I would propose to try a six month release cycle with two months feature freeze for testing (see also my previous mail about a request for more time for testing/bug fixing). Even a yearly release cycle would be fine, if there could be a bug-fix release. But the short release cycle is there to avoid the need of bugfix releases - because we learned in the past that we don't have enough (interested and skilled) people to maintain the backports and we also miss a scheme to test them before we apply them. And IMHO a year too long to wait for new features in a release anyway. Four months is a compromise between avoiding bugfix releases and getting new features released. Jürgen ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Good to hear that there are organizations putting money into QA. Thanks a lot. I think there are different categories of users, experimental early adopters and organizations going for stability at the expense of waiting longer for new features. To get the best for both, LTS releases may be a good option. One LTS branch every 8 or 12 months which gets fixes backported and 1 or 2 other releases in between which work the way we currently have it. Advantages are New features get tested in the in-between releases (they will get used because they are not called experimental or testing or rc). Big organizations use the same LTS release (in comparison to the general advice of take every second release which will bring one org to use the Jun release and the other one the Feb release) and can collaborate with bugfixing Backports of bugfixes have always to be done for one specific/defined version. (In comparison: if a company skips release 2.6 they are still with 2.4 in the 2.7 period, and nobody will backport to 2.4 at that stage) Best, Matthias On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote: Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. The above mentioned resources could be used for maintaining a stable branch, and backporting. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Agreed fully: that's what Blocker category is for. All the best, and thanks for this important discussion. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi, I also think 4 months is too frequent (users on gis.stackexchange are still reporting on 2.0 release!), but think anything longer than 6 months may be too long. What about this scenario (building upon Nathan's suggestion)? 1) 4 full months of development on master branch (currently is only 3 months) 2) 1 month of testing RC (during feature freeze) 3) Tag release (e.g. 2.6.0), do NOT create a release branch; then, package and release 4) 1 month (minus previous packaging/release time) of users testing release and devs working on fixes directly to master branch (still in feature freeze) 5) Tag bug fix release (e.g. 2.6.1), create new branch for 'release-2_6'; then, package and do single bugfix release 6) Repeat from 1), with any new fixes backported to 'release-2_6' branch, when resources/funding allow This allows for a decent amount of development time for new features, and a good amount of time for testing (both as a RC and after the public release). The 'stable' branch is not created until the bugfix release, thereby keeping all devs/testers focused on fixes directly to master branch. Essentially, it is a 6-month release cycle with a single bugfix release (if needed) guaranteed to happen 1 month after initial release. The release branch remains open to backported fixes, but packagers should only expect/schedule to do one 'official' followup bugfix release. Any further bugfix releases would be at the packagers discretion. IMO, this may increase dev work on stability, while not detracting from the forward momentum of development and not forcing maintenance of multiple branches, unless sponsors step up to provide such help. It will also show due diligence on the part of the dev team to focus on user-reported bug fixes directly after the public release. Regards, Larry On Thu, Jun 19, 2014 at 4:44 AM, Matthias Kuhn matthias.k...@gmx.ch wrote: Good to hear that there are organizations putting money into QA. Thanks a lot. I think there are different categories of users, experimental early adopters and organizations going for stability at the expense of waiting longer for new features. To get the best for both, LTS releases may be a good option. One LTS branch every 8 or 12 months which gets fixes backported and 1 or 2 other releases in between which work the way we currently have it. Advantages are New features get tested in the in-between releases (they will get used because they are not called experimental or testing or rc). Big organizations use the same LTS release (in comparison to the general advice of take every second release which will bring one org to use the Jun release and the other one the Feb release) and can collaborate with bugfixing Backports of bugfixes have always to be done for one specific/defined version. (In comparison: if a company skips release 2.6 they are still with 2.4 in the 2.7 period, and nobody will backport to 2.4 at that stage) Best, Matthias On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote: Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. The above mentioned resources could be used for maintaining a stable branch, and backporting. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Agreed fully: that's what Blocker category is for. All the best, and thanks for this important discussion. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi Nathan, On Thu, 19. Jun 2014 at 20:34:00 +1000, Nathan Woodrow wrote: Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows maintainers and they all agree with me - I think they already have don't a good job to automated it a good deal, but it's still not fully automated and therefore they are not comfortable with doing it again and again. ;) Of course I don't want to create heaps of more work for people but if cutting a release is a hard process then it really creates a sticky point in all this. We need to be able to release as easy as possible. You realize that I was just talking about me. I'm doing all of that - and that's also why I became RM - because I did't a lot of the release (namely packaging) anyway. I just don't do OSX and the non-deb linux distributions. And it's also not like a package is a huge amount of work and has tons of manual steps. I already automated it a great deal (otherwise I would probably not stand a chance) - but you still have to manually checkout new branches, wait for builds, wait for the uploads, on multiple platforms and machines - and not of all of that works flawlessly (sometimes this, sometimes that and always something new - you know...) and sometimes something is brought up that the nightly builds didn't show. Same with the nightly builds, most of the time they works nicely, but every now and again there's something going wrong that you didn't predict. Some stuff was improved however - like the disk space issues on our osgeo vm that made building the debian/ubuntu packages a pain (move to a new host). I also finally came to setup a single VM to do the windows (nightly) building (before I had it one two separate machines). But didn't find the time to setup nightly release builds in case of news on the release branch. Neither for osgeo4w nor for a not yet existing debian repository. What are the main problems/stoppers with having it fully automated? Do we need resources, VMs for each platform, etc? See above. Essentially it's just time (some larger chunks and a lot of small ones). Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
I think that LTS is kind of a really good idea. At some extent, it's what Sourcepole is doing with its QGIS enterprise. If we have enough companies paying for such bugfixes QA, that would be easily feasible, but someone should be in charge of handling this. Then, the cycle is another discussion. It could be either 2 or 3 releases a year, with 1 over 2 or 3 being LTS. But I would definitely investigate the idea of the LTS. Greetings, Denis On 19.06.2014 12:44, Matthias Kuhn wrote: Good to hear that there are organizations putting money into QA. Thanks a lot. I think there are different categories of users, experimental early adopters and organizations going for stability at the expense of waiting longer for new features. To get the best for both, LTS releases may be a good option. One LTS branch every 8 or 12 months which gets fixes backported and 1 or 2 other releases in between which work the way we currently have it. Advantages are New features get tested in the in-between releases (they will get used because they are not called experimental or testing or rc). Big organizations use the same LTS release (in comparison to the general advice of take every second release which will bring one org to use the Jun release and the other one the Feb release) and can collaborate with bugfixing Backports of bugfixes have always to be done for one specific/defined version. (In comparison: if a company skips release 2.6 they are still with 2.4 in the 2.7 period, and nobody will backport to 2.4 at that stage) Best, Matthias On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote: Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new release introduces more and different bugs. The above mentioned resources could be used for maintaining a stable branch, and backporting. We users need bug-free software more than a predictable release date. We don't need QGIS at an exact specific time. But we cannot accept that some features are broken that are key to our work. Agreed fully: that's what Blocker category is for. All the best, and thanks for this important discussion. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
If I could chime in as a Non-developer. I might be more of a non-standard user (given with all the things I'm trying to do with QGIS). I tried to keep up with all the thoughts in this email chain - The joys of sleeping in the GMT-5 timeszone (or is it +)...anyway.. I look at QGIS has having four operating systems it supports: Linux (debian and ubuntu because I am familiar with those), mac, windows, android: * The linux releases only seem to get release once with no bug fixes. Really that depends on the distro though...but for Ubuntu I think that is correct. * The windows release (using osgeo) is absolutely great - it seems to be getting bugfixes all the time. * I've only installed QGIS on a MAC twice - but from what I can tell it might be getting bugfixes between releases * Android - I have no clue. Of course I have no clue how long it takes to release - I compiled QGIS once and that was an all day thing for me (adding libraries and things). I'm not a developer although I have dreams. A 5 to 6 month release cycle would be fine for a user (at least for me) if there were bugfixes in between. In 2.0 there was a problem with spatialite - there was no fix until the next release. It seems (if memory serves me ) there was a fix that rolled out on the OSGEO side in windows at some point. I went against what I normally do and have been running 2.3 for production and it's great (at least from my standpoint). I've tried to respond in with reports and what not. Really I say all of that and I think we (users) are good with whatever as long as you guys are happy with it. It seems like this email stirred up some uneasiness among your guys for release. Any user (in his right mind) isn't sitting there with everything waiting on 2.4 coming out in 48 hours. You guys are the experts - make yourselves happy. Happy developers = better QGIS release. If I could only add one thing - solidify the releases. Make each one mimic the other. Make Linux the same as windows the same as Mac. That's the joy of QGIS - it runs everywhere. Right now I thing the osgeo windows version (because mostly of sid and ecw support) is the best version released. I run xubuntu 14.04 on my main workstation and I think QGIS solid - but QGIS on windows seems to edge that one out just a bit. Maybe it's because most of the world runs on windows and mac and there's a few of use linux users out and about. Anyway - my 2 cents worth. Thank you for the work you are doing. Randy - Randal Hale North River Geographic Systems, Inc http://www.northrivergeographic.com 423.653.3611 tel:423.653.3611 rjh...@northrivergeographic.com mailto:rjh...@northrivergeographic.com twitter:rjhale http://about.me/rjhale On 06/19/2014 08:33 AM, Denis Rouzaud wrote: I think that LTS is kind of a really good idea. At some extent, it's what Sourcepole is doing with its QGIS enterprise. If we have enough companies paying for such bugfixes QA, that would be easily feasible, but someone should be in charge of handling this. Then, the cycle is another discussion. It could be either 2 or 3 releases a year, with 1 over 2 or 3 being LTS. But I would definitely investigate the idea of the LTS. Greetings, Denis On 19.06.2014 12:44, Matthias Kuhn wrote: Good to hear that there are organizations putting money into QA. Thanks a lot. I think there are different categories of users, experimental early adopters and organizations going for stability at the expense of waiting longer for new features. To get the best for both, LTS releases may be a good option. One LTS branch every 8 or 12 months which gets fixes backported and 1 or 2 other releases in between which work the way we currently have it. Advantages are New features get tested in the in-between releases (they will get used because they are not called experimental or testing or rc). Big organizations use the same LTS release (in comparison to the general advice of take every second release which will bring one org to use the Jun release and the other one the Feb release) and can collaborate with bugfixing Backports of bugfixes have always to be done for one specific/defined version. (In comparison: if a company skips release 2.6 they are still with 2.4 in the 2.7 period, and nobody will backport to 2.4 at that stage) Best, Matthias On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote: Il 19/06/2014 12:19, Andreas Neumann ha scritto: I'd like to add to the discussion that there will be more organizations investing in bug-fixing in the future. Yesterday, a Swiss canton told me that they will invest 5000 CHF each year in QA/bugfixing in the future. I am pretty sure that more organizations will follow. Wonderful, this is the way to go IMHO. But it is important that we will provide bug-fix releases and that there is a reasonable time available for testing. The short releases do not help at all for organizations - because each new
Re: [Qgis-developer] Four month cycle too fast
On Thu, Jun 19, 2014 at 4:29 PM, Randal Hale rjh...@northrivergeographic.com wrote: A 5 to 6 month release cycle would be fine for a user (at least for me) if there were bugfixes in between. +1 for me, too. In 2.0 there was a problem with spatialite - there was no fix until the next release. It seems (if memory serves me ) there was a fix that rolled out on the OSGEO side in windows at some point. In Qgis 1.8 there was a blocking bug and thus it would require a 1.8.1, never released, I think, because for the switch from SVN to GIT. This bug was the impossibility to split a feature stored in a postgis table, because QGIS tried to duplicate the primary key. So we remained to QGIS 1.7.4 and now we are still at 2.0 (but we will migrate to 2.4 if it is all OK). ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
On Thu, Jun 19, 2014 at 04:36:47PM +0200, Luca Manganelli wrote: In Qgis 1.8 there was a blocking bug and thus it would require a 1.8.1, never released, I think, because for the switch from SVN to GIT. This bug was the impossibility to split a feature stored in a postgis table, because QGIS tried to duplicate the primary key. So we remained to QGIS 1.7.4 and now we are still at 2.0 (but we will migrate to 2.4 if it is all OK). I'm still in love with 1.7.4. No other release got so high in patch-level number :) --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi all, IMHO, I agree with the idea of having a LTS (maybe once a year) and intermediate releases for development. from my working experience, both with public institutions and privates, seems to be more comfortable not to shift from one version to the other very often; pretty appreciated is having one long lasting stable release. btw: thank you very much for the good job you do every day! Niccolò ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hi Randal, On Thu, 19. Jun 2014 at 10:29:32 -0400, Randal Hale wrote: * The linux releases only seem to get release once with no bug fixes. Really that depends on the distro though...but for Ubuntu I think that is correct. Depends on the ubuntu version you have - and if there are packaging related bugs. For instance the trusty package was uninstallable (at least the python support) as trusty (unreleased at the time of the qgis release) moved on and hence the package was referring to package versions that didn't exist anymore. To fix that there was a new build from the release branch to solve that using the current release branch at that point. Other Packages that didn't need to be rebuild, because they were for stable releases weren't. Debian itself also has 2.2 builds that get the backported fixes (and Bas also backports some fixes we didn't backport and maybe stuff we didn't fix at all - I believe). But I Debian will probably stay at 2.2 and skip some upcoming version. * The windows release (using osgeo) is absolutely great - it seems to be getting bugfixes all the time. The qgis 2.2 package wasn't rebuild there either (even when it/I switched from GDAL 1.10.1 to 1.11). If you're referring to the nightly builds, than the ubuntu/debian argument argument above doesn't stick as we also have nightly builds for those - that would also have the latest fixes. as long as you guys are happy with it. It seems like this email stirred up some uneasiness among your guys for release. Any user (in his right mind) isn't sitting there with everything waiting on 2.4 coming out in 48 hours. Only ~20hrs. Friday 12:00 UTC. Right now I thing the osgeo windows version (because mostly of sid and ecw support) is the best version released. 2.2 (or better put GDAL 1.10.1) in OSGeo4W currently doesn't have plugins for MrSid and ECW. The standalone installer was made from the same binaries, but at release time when GDAL 1.10.1 was still default and still has ECW and MrSid out of the box. The nightly build however uses GDAL 1.11 which has those plugins. And 2.4 will be built with current GDAL in OSGeo4W and therefore will also have ECW/MrSid support. A 5 to 6 month release cycle would be fine for a user (at least for me) if there were bugfixes in between. That's the point. For the packaging it doesn't matter if you build a new release or an old release with bugfixes (one or a dozen). The effort is essentially the same. It just about building one state for a number of platforms. The release or bugfixes are already done at that point. So a new release every four month w/o bugfix release between release is less effort than a new release every six month with 2 bugfix releases. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
Hey - thanks for the explanation. Like I said - this is just from my perspective - A user who might know more than the average user or might be completely delusional (I vote for delusional). Youcan see what impressions I get from things - right or wrong. I think whatever makes the most sense for the developers. The users are more or less along for the ride and all seem very happy with the software. I taught a class on QGIS last week and everyone was sitting there (these are all ESRI users) ecstatic that this previously unknown software exists. Whatever is decided - put it on the website. Just let people know and if it's a 5 month or 4 month or 6 month everyone should be happy - if they aren't ask for donations to speed it up. All of you are packing a tremendous amount of time and effort into this - it's not unnoticed. Again - Thanks for your efforts. Randy On 06/19/2014 12:00 PM, Jürgen E. Fischer wrote: Hi Randal, On Thu, 19. Jun 2014 at 10:29:32 -0400, Randal Hale wrote: * The linux releases only seem to get release once with no bug fixes. Really that depends on the distro though...but for Ubuntu I think that is correct. Depends on the ubuntu version you have - and if there are packaging related bugs. For instance the trusty package was uninstallable (at least the python support) as trusty (unreleased at the time of the qgis release) moved on and hence the package was referring to package versions that didn't exist anymore. To fix that there was a new build from the release branch to solve that using the current release branch at that point. Other Packages that didn't need to be rebuild, because they were for stable releases weren't. Debian itself also has 2.2 builds that get the backported fixes (and Bas also backports some fixes we didn't backport and maybe stuff we didn't fix at all - I believe). But I Debian will probably stay at 2.2 and skip some upcoming version. * The windows release (using osgeo) is absolutely great - it seems to be getting bugfixes all the time. The qgis 2.2 package wasn't rebuild there either (even when it/I switched from GDAL 1.10.1 to 1.11). If you're referring to the nightly builds, than the ubuntu/debian argument argument above doesn't stick as we also have nightly builds for those - that would also have the latest fixes. as long as you guys are happy with it. It seems like this email stirred up some uneasiness among your guys for release. Any user (in his right mind) isn't sitting there with everything waiting on 2.4 coming out in 48 hours. Only ~20hrs. Friday 12:00 UTC. Right now I thing the osgeo windows version (because mostly of sid and ecw support) is the best version released. 2.2 (or better put GDAL 1.10.1) in OSGeo4W currently doesn't have plugins for MrSid and ECW. The standalone installer was made from the same binaries, but at release time when GDAL 1.10.1 was still default and still has ECW and MrSid out of the box. The nightly build however uses GDAL 1.11 which has those plugins. And 2.4 will be built with current GDAL in OSGeo4W and therefore will also have ECW/MrSid support. A 5 to 6 month release cycle would be fine for a user (at least for me) if there were bugfixes in between. That's the point. For the packaging it doesn't matter if you build a new release or an old release with bugfixes (one or a dozen). The effort is essentially the same. It just about building one state for a number of platforms. The release or bugfixes are already done at that point. So a new release every four month w/o bugfix release between release is less effort than a new release every six month with 2 bugfix releases. Jürgen -- - Randal Hale North River Geographic Systems, Inc http://www.northrivergeographic.com 423.653.3611 rjh...@northrivergeographic.com twitter:rjhale http://about.me/rjhale ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Four month cycle too fast
I would like to add something else to the discussion, qgis is adding a lot of new features and enhancements and don't get me wrong I love them, but it seems bugs are not squashed at the same pace, I get that adding enhancements and new features is nice and desirable but I would like one release being just fixing bugs no enhancements and a release adding enhancements plus keep squashing bugs -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Four-month-cycle-too-fast-tp5146648p5146817.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
