Re: [Qgis-developer] Post-release period of portable commits only?
Nightly builds (or weekly snapshots for that matter) are very different
from a publicized, pre-release preview build. With a prepared pre-release
preview, users are at least expecting that basic functioning will work,
that's something the nightly builds simply can't guarantee by the nature
of what those are. Very few average user will install a nightly development
build, but you get an higher chance of getting a broader number of people
(that interacts with QGIS in different ways) to test out your product
before it's released.
It also helps channel what your describing as noise (i.e. users running
into problems) into a better managed call for people to test and report.
The noise will happen no matter what. But it might make some sense to
trigger some of that noise (valid bugs and invalid RTFM cases) _before_
you release your final version via a pre-release social media and news site
try this pre-release build :)
It's really more a matter of presentation to the users than of actual work.
As you point out Jef, you guys already have the infrastructure that
produces weekly standalone builds, and daily packages.
Math
On Mon, Feb 24, 2014 at 2:40 PM, Jürgen E. j...@norbit.de wrote:
Hi Mathieu,
On Mon, 24. Feb 2014 at 09:17:11 +0700, Mathieu Pellerin wrote:
That reminds me of someone mentioning in a ticket of a 2.0 issue resolved
against qgis 2.1 that he'd wait (angrily?) having fix backported into a
(mythical) 2.0.x update rather than him moving to 2.2 and having to deal
with possible regressions. I was thinking at the time that this sounds to
me like a flawed behavior by some QGIS users, an egg or chicken
situation.
How are regressions fixed if users are not doing their parts in
uncovering
and reporting them.
That led me to think there might be a very low-cost, high reward behavior
QGIS could adopt: 4, or 2, weeks before the release date, {beta,release
candidate,tech preview,etc.} builds (from master, no need to branch out
really) are pushed out to osgeo4w linux and quite loudly advertised
(blog
posts, social media, etc.) to get as many users as possible to test drive
it. The users' feedback would enrich the 4-weeks period when developers
are
to be focused on bug-fixing only.
Thoughts? Was that already suggested and declined?
What's the difference to the nightly builds and the weekly standalone
snapshot
for Windows - except for the noise of course?
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] Post-release period of portable commits only?
-but you get an higher chance of getting a broader number of people (that
interacts with QGIS in different ways) to test out your product before it's
released.
+but you get an higher chance of getting a broader number of people (that
interacts with QGIS in different ways) to test out your product before it's
released *with an official beta/preview build*.
:)
On Mon, Feb 24, 2014 at 3:42 PM, Mathieu Pellerin nirvn.a...@gmail.comwrote:
Nightly builds (or weekly snapshots for that matter) are very different
from a publicized, pre-release preview build. With a prepared pre-release
preview, users are at least expecting that basic functioning will work,
that's something the nightly builds simply can't guarantee by the nature
of what those are. Very few average user will install a nightly development
build, but you get an higher chance of getting a broader number of people
(that interacts with QGIS in different ways) to test out your product
before it's released.
It also helps channel what your describing as noise (i.e. users running
into problems) into a better managed call for people to test and report.
The noise will happen no matter what. But it might make some sense to
trigger some of that noise (valid bugs and invalid RTFM cases) _before_
you release your final version via a pre-release social media and news site
try this pre-release build :)
It's really more a matter of presentation to the users than of actual
work. As you point out Jef, you guys already have the infrastructure that
produces weekly standalone builds, and daily packages.
Math
On Mon, Feb 24, 2014 at 2:40 PM, Jürgen E. j...@norbit.de wrote:
Hi Mathieu,
On Mon, 24. Feb 2014 at 09:17:11 +0700, Mathieu Pellerin wrote:
That reminds me of someone mentioning in a ticket of a 2.0 issue
resolved
against qgis 2.1 that he'd wait (angrily?) having fix backported into a
(mythical) 2.0.x update rather than him moving to 2.2 and having to deal
with possible regressions. I was thinking at the time that this sounds
to
me like a flawed behavior by some QGIS users, an egg or chicken
situation.
How are regressions fixed if users are not doing their parts in
uncovering
and reporting them.
That led me to think there might be a very low-cost, high reward
behavior
QGIS could adopt: 4, or 2, weeks before the release date, {beta,release
candidate,tech preview,etc.} builds (from master, no need to branch out
really) are pushed out to osgeo4w linux and quite loudly advertised
(blog
posts, social media, etc.) to get as many users as possible to test
drive
it. The users' feedback would enrich the 4-weeks period when developers
are
to be focused on bug-fixing only.
Thoughts? Was that already suggested and declined?
What's the difference to the nightly builds and the weekly standalone
snapshot
for Windows - except for the noise of course?
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] Post-release period of portable commits only?
Hi Mathieu, On Mon, 24. Feb 2014 at 15:42:19 +0700, Mathieu Pellerin wrote: Nightly builds (or weekly snapshots for that matter) are very different from a publicized, pre-release preview build. With a prepared pre-release preview, users are at least expecting that basic functioning will work, that's something the nightly builds simply can't guarantee by the nature of what those are. Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? Very few average user will install a nightly development build, but you get an higher chance of getting a broader number of people (that interacts with QGIS in different ways) to test out your product before it's released. Why should it matter if we call it weekly snapshot, nightly build or prerelease? It's the same thing, just the tag is different. And installation is essential as easy as installing the stable release. It also helps channel what your describing as noise (i.e. users running into problems) into a better managed call for people to test and report. The noise will happen no matter what. But it might make some sense to trigger some of that noise (valid bugs and invalid RTFM cases) _before_ you release your final version via a pre-release social media and news site try this pre-release build :) It's really more a matter of presentation to the users than of actual work. Exactly. And that's what I meant with noise: tada, there's a new weekly snapshot/prerelease/nightly build - not users running into problems. Because I see that as the only significant difference to what we already have. 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] Post-release period of portable commits only?
Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? I think it's a perception thing. Nightly build in my mind always means bleeding edge may or may not work, use at own risk. I'm aware that doesn't always mean *it will crash your computer, burn down your house, and spend your life savings on questionable drugs*, but it's certainly not what I see as a synonym for stable either. Every time I see a nightly, it always comes with a big scary caveat (QGIS does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This trains users not to use them. Taking one of the nightlies and re-branding it to something more amicable would get more folks to test it. Just copy and paste it and rename the file. :-) Cheers, Jonathan Very few average user will install a nightly development build, but you get an higher chance of getting a broader number of people (that interacts with QGIS in different ways) to test out your product before it's released. Why should it matter if we call it weekly snapshot, nightly build or prerelease? It's the same thing, just the tag is different. And installation is essential as easy as installing the stable release. It also helps channel what your describing as noise (i.e. users running into problems) into a better managed call for people to test and report. The noise will happen no matter what. But it might make some sense to trigger some of that noise (valid bugs and invalid RTFM cases) _before_ you release your final version via a pre-release social media and news site try this pre-release build :) It's really more a matter of presentation to the users than of actual work. Exactly. And that's what I meant with noise: tada, there's a new weekly snapshot/prerelease/nightly build - not users running into problems. Because I see that as the only significant difference to what we already have. 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 -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
How about making a formal announcement (mailing list, website, wiki etc) telling the users that QGIS version 2.X is in feature freeze and therefore is sufficiently stable to be tested by end users? This may increase the number of testers. As an end user that uses QGIS for production, this is the only time I work with QGIS Master. On Mon, Feb 24, 2014 at 2:17 PM, Jonathan Moules jonathanmou...@warwickshire.gov.uk wrote: Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? I think it's a perception thing. Nightly build in my mind always means bleeding edge may or may not work, use at own risk. I'm aware that doesn't always mean *it will crash your computer, burn down your house, and spend your life savings on questionable drugs*, but it's certainly not what I see as a synonym for stable either. Every time I see a nightly, it always comes with a big scary caveat (QGIS does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This trains users not to use them. Taking one of the nightlies and re-branding it to something more amicable would get more folks to test it. Just copy and paste it and rename the file. :-) Cheers, Jonathan Very few average user will install a nightly development build, but you get an higher chance of getting a broader number of people (that interacts with QGIS in different ways) to test out your product before it's released. Why should it matter if we call it weekly snapshot, nightly build or prerelease? It's the same thing, just the tag is different. And installation is essential as easy as installing the stable release. It also helps channel what your describing as noise (i.e. users running into problems) into a better managed call for people to test and report. The noise will happen no matter what. But it might make some sense to trigger some of that noise (valid bugs and invalid RTFM cases) _before_ you release your final version via a pre-release social media and news site try this pre-release build :) It's really more a matter of presentation to the users than of actual work. Exactly. And that's what I meant with noise: tada, there's a new weekly snapshot/prerelease/nightly build - not users running into problems. Because I see that as the only significant difference to what we already have. 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 This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ 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] Post-release period of portable commits only?
Slightly deviating from the topic, but I'm quite fond of the GeoServer release process; they're revamping a little to offer better Long Term Support: http://geoserver.org/display/GEOS/GSIP+107+-+Extended+Release+Schedule I feel a similar system would solve most of QGIS' release problems: - Bugfix releases - LTS (if/when required) - Predictable releases (though now fixed by QGIS) - Clear test releases (betas and release candidates) In comparison the QGIS release system feels... haphazard I guess is the best word. I know the common complaint is a lack of a resources, but QGIS has far more resources than GeoServer - both in number of developers and the existence of a general fund. Just thought I'd put it out there. Cheers, Jonathan On 24 February 2014 14:41, Filipe Dias filipesd...@gmail.com wrote: How about making a formal announcement (mailing list, website, wiki etc) telling the users that QGIS version 2.X is in feature freeze and therefore is sufficiently stable to be tested by end users? This may increase the number of testers. As an end user that uses QGIS for production, this is the only time I work with QGIS Master. On Mon, Feb 24, 2014 at 2:17 PM, Jonathan Moules jonathanmou...@warwickshire.gov.uk wrote: Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? I think it's a perception thing. Nightly build in my mind always means bleeding edge may or may not work, use at own risk. I'm aware that doesn't always mean *it will crash your computer, burn down your house, and spend your life savings on questionable drugs*, but it's certainly not what I see as a synonym for stable either. Every time I see a nightly, it always comes with a big scary caveat (QGIS does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This trains users not to use them. Taking one of the nightlies and re-branding it to something more amicable would get more folks to test it. Just copy and paste it and rename the file. :-) Cheers, Jonathan Very few average user will install a nightly development build, but you get an higher chance of getting a broader number of people (that interacts with QGIS in different ways) to test out your product before it's released. Why should it matter if we call it weekly snapshot, nightly build or prerelease? It's the same thing, just the tag is different. And installation is essential as easy as installing the stable release. It also helps channel what your describing as noise (i.e. users running into problems) into a better managed call for people to test and report. The noise will happen no matter what. But it might make some sense to trigger some of that noise (valid bugs and invalid RTFM cases) _before_ you release your final version via a pre-release social media and news site try this pre-release build :) It's really more a matter of presentation to the users than of actual work. Exactly. And that's what I meant with noise: tada, there's a new weekly snapshot/prerelease/nightly build - not users running into problems. Because I see that as the only significant difference to what we already have. 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 This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have
Re: [Qgis-developer] Post-release period of portable commits only?
Hi Jonathan, On Mon, 24. Feb 2014 at 14:17:44 +, Jonathan Moules wrote: Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? I think it's a perception thing. Nightly build in my mind always means bleeding edge may or may not work, use at own risk. I'm aware that doesn't always mean *it will crash your computer, burn down your house, and spend your life savings on questionable drugs*, but it's certainly not what I see as a synonym for stable either. Sure, but that doesn't change that it's a misperception. It more like This is what we're going to release soon - it's not too bad and it's getting better every day, but if you don't try it and report problems, it's your responsibility if the release later eats your kids. ;) Every time I see a nightly, it always comes with a big scary caveat (QGIS does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This trains users not to use them. Taking one of the nightlies and re-branding it to something more amicable would get more folks to test it. Just copy and paste it and rename the file. :-) Or just remove all those wimpy warnings. It's in the smallprint (GPL) anyway. The users can not tests all they want, we still can't even be made responsible if the release does not eat kids. ;) Ok, seriously, I should probably emphasize in the freeze announcement, that it's mainly the users that are supposed to test the daily prereleases and weekly release candidates and report problems, while the developers work on reproducing and fixing already known or newly reported bugs. And the warnings on the download page should be changed to say, that testing nightly builds in the development phase are different thing than the daily prereleases in the freeze phase. 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] Post-release period of portable commits only?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, seriously, I should probably emphasize in the freeze announcement, that it's mainly the users that are supposed to test the daily prereleases and weekly release candidates and report problems, while the developers work on reproducing and fixing already known or newly reported bugs. And the warnings on the download page should be changed to say, that testing nightly builds in the development phase are different thing than the daily prereleases in the freeze phase. Jürgen Jürgen, at first thank you for your work as a developer and RM. Time based releases are very good decision. I think that clear separation of nightly builds after a feature freeze from regular nightly builds (even if they are technically same) followed by loud public announcements will surely help to catch more bugs. Even if there is a no man power to maintain bugfix releases, please support people to commit backported fixes to release branches. I think many people realized importance of these bug releases and will offer a hand. I vote for Sandro's work flow - if there is at least one commit from latest minor release and at least 14 days of silence - release just a source code. Other things will follow upon volunteer base. - -- Ivan Minčík ivan.min...@gmail.com GPG: 0x79529A1E http://imincik.github.io/0x79529A1E.key ivan.min...@gista.skGPG: 0xD714B02C http://imincik.github.io/0xD714B02C.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC3IbAAoJEPfdLsR5Upoee0AIAI/zVrB5YiEV4dqR/BUx5/HF YX7ml6wNL+utmALAH+w06Ilzkem/4fLHk4IdWgjuTH/goSkypQeZF6vchrphc/zC frSpoSdQ3/ls+CemTQQv2aRkE3R3y91qMlx4mVrI0/i3WobjEsSvjWOEyjcaoG+b 9lBpY+6jHyrUpRP+fu0tE2fE0dE3+i660YpWYNeGHX66uFNEBfVhDhkDXdkuGxXV 25F+g32fD3C+koeA1ynqpht2tcrzOYnnAmmoerH5Z9cS1f+SwoomAjJGmnrnED1D VDfvS3mWKAaOpjy7N0FSrAyAQ7tLnOXuY3AQriokI3eBivjQ+uRfAUFgp+FQtDI= =BmOT -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
Hi, On Mon, Feb 24, 2014 at 7:41 AM, Filipe Dias filipesd...@gmail.com wrote: How about making a formal announcement (mailing list, website, wiki etc) telling the users that QGIS version 2.X is in feature freeze and therefore is sufficiently stable to be tested by end users? This may increase the number of testers. As an end user that uses QGIS for production, this is the only time I work with QGIS Master. On Mon, Feb 24, 2014 at 8:54 AM, Jürgen E. j...@norbit.de wrote: -- 8--snip Ok, seriously, I should probably emphasize in the freeze announcement, that it's mainly the users that are supposed to test the daily prereleases and weekly release candidates and report problems, while the developers work on reproducing and fixing already known or newly reported bugs. And the warnings on the download page should be changed to say, that testing nightly builds in the development phase are different thing than the daily prereleases in the freeze phase. I think those two posts really do sum it up. The project just needs to communicate better with the user community that the weeks between the feature freeze and release are their chance to make a difference, by testing the 'release candidate' (or whatever it going to be called), or be prepared to wait 4 months. +1 I'm all for these changes. I don't think the idea I proposed in the original post is any better, excepting the inclusion of a larger user base, which still doesn't mean better testing, though. If the majority of users 'know' that they have several weeks every 4 months to directly affect change/bugs right before a release, that should be good enough. Also, would be good to list that right on the Roadmap schedule [0], e.g.: WEEK DATE EVENT 21 23.02.3 freeze begins, release candidate [0] http://qgis.org/en/site/getinvolved/development/index.html#road-map Regards, Larry ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
Hi Larry, On Sat, 22. Feb 2014 at 14:33:11 -0700, Larry Shaffer wrote: How about for a set period of time, only commits that devs think can readily be ported to the 2.2.0 branch are 'allowed' on master? With any code changes, which would make porting changes/fixes over to the 2.2.0 branch difficult, submitted via pull requests. Maybe for two weeks? I think if code is committed to core that steamrolls over the means of providing a reasonably timed bug-fix update, it becomes that much harder to do so. I also think much user frustration may stem from that vicious cycle, and we have an opportunity to fix that *right now*. Don't get me wrong. I like the new release schedule. Just looking for ways to make it as beneficial for users as it is for devs/packagers. Our agreement was to not do point releases. And not because stable release are a bad thing, but just acknowleding the fact that we don't have the resources to do everything. The more we wasted on releases, the more we loose on feature work. Maybe we should just emphasize more that the four weeks before the release are not a pure developer thing. If users want good releases, they should verify that master is ok before it get released - and not start testing right after the release. Of course all testing is welcome, but testing after the release only contributes to the next release. So blocking development for another two weeks to backport stuff to a branch that - unless in the undesired event that something severe wasn't spotted in the four weeks before the release - won't ever be released, doesn't make sense to me. The next release is 117[1] days away. That might sound far away, but I bet it's sooner than we think. Jürgen [1] http://www.timeanddate.com/countdown/generic?iso=20140620T12p0=1440msg=QGIS+2.4+Release -- 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] Post-release period of portable commits only?
On Sun, Feb 23, 2014 at 08:36:07AM +1100, Nyall Dawson wrote: On 23/02/2014 7:33 am, Larry Shaffer lar...@dakotacarto.com wrote: How about for a set period of time, only commits that devs think can readily be ported to the 2.2.0 branch are 'allowed' on master? With any code changes, which would make porting changes/fixes over to the 2.2.0 branch difficult, submitted via pull requests. Maybe for two weeks? As much as I'd love to see the multithreaded rendering branch land asap, I'm in favour of Larry's proposal. Needless to say, I'm also in favour of it. It would be interesting to look at the bug tracker to check how many bugs are reported affecting 2.1.0 in a week. Speaking of which, there's no 2.1.0 field to pick for the Affected version field in a new ticket. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
That reminds me of someone mentioning in a ticket of a 2.0 issue resolved
against qgis 2.1 that he'd wait (angrily?) having fix backported into a
(mythical) 2.0.x update rather than him moving to 2.2 and having to deal
with possible regressions. I was thinking at the time that this sounds to
me like a flawed behavior by some QGIS users, an egg or chicken situation.
How are regressions fixed if users are not doing their parts in uncovering
and reporting them.
That led me to think there might be a very low-cost, high reward behavior
QGIS could adopt: 4, or 2, weeks before the release date, {beta,release
candidate,tech preview,etc.} builds (from master, no need to branch out
really) are pushed out to osgeo4w linux and quite loudly advertised (blog
posts, social media, etc.) to get as many users as possible to test drive
it. The users' feedback would enrich the 4-weeks period when developers are
to be focused on bug-fixing only.
Thoughts? Was that already suggested and declined?
Math
On Sun, Feb 23, 2014 at 5:06 PM, Jürgen E. j...@norbit.de wrote:
Hi Larry,
On Sat, 22. Feb 2014 at 14:33:11 -0700, Larry Shaffer wrote:
How about for a set period of time, only commits that devs think can
readily
be ported to the 2.2.0 branch are 'allowed' on master? With any code
changes,
which would make porting changes/fixes over to the 2.2.0 branch
difficult,
submitted via pull requests. Maybe for two weeks?
I think if code is committed to core that steamrolls over the means of
providing a reasonably timed bug-fix update, it becomes that much harder
to
do so. I also think much user frustration may stem from that vicious
cycle,
and we have an opportunity to fix that *right now*.
Don't get me wrong. I like the new release schedule. Just looking for
ways
to make it as beneficial for users as it is for devs/packagers.
Our agreement was to not do point releases. And not because stable
release are
a bad thing, but just acknowleding the fact that we don't have the
resources to
do everything. The more we wasted on releases, the more we loose on
feature
work.
Maybe we should just emphasize more that the four weeks before the release
are
not a pure developer thing. If users want good releases, they should
verify
that master is ok before it get released - and not start testing right
after
the release. Of course all testing is welcome, but testing after the
release
only contributes to the next release.
So blocking development for another two weeks to backport stuff to a branch
that - unless in the undesired event that something severe wasn't spotted
in
the four weeks before the release - won't ever be released, doesn't make
sense
to me.
The next release is 117[1] days away. That might sound far away, but I bet
it's sooner than we think.
Jürgen
[1]
http://www.timeanddate.com/countdown/generic?iso=20140620T12p0=1440msg=QGIS+2.4+Release
--
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] Post-release period of portable commits only?
On 24. 02. 14 03:17, Mathieu Pellerin wrote:
QGIS could adopt: 4, or 2, weeks before the release date,
{beta,release candidate,tech preview,etc.} builds (from master, no
need to branch out really) are pushed out to osgeo4w linux and quite
loudly advertised (blog posts, social media, etc.) to get as many
users as possible to test drive it
+1
I always thought there is not enough publicity made to encourage testing
the master build.
Advertising for beta and release candidate sounds like a good idea.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
Just to be clear, I don't think QGIS can handle more than one pre release.
The list of terminologies was just there as a pick one name you like :)
On 24 Feb 2014 13:22, Denis Rouzaud denis.rouz...@gmail.com wrote:
On 24. 02. 14 03:17, Mathieu Pellerin wrote:
QGIS could adopt: 4, or 2, weeks before the release date, {beta,release
candidate,tech preview,etc.} builds (from master, no need to branch out
really) are pushed out to osgeo4w linux and quite loudly advertised (blog
posts, social media, etc.) to get as many users as possible to test drive it
+1
I always thought there is not enough publicity made to encourage testing
the master build.
Advertising for beta and release candidate sounds like a good idea.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
Hi Mathieu,
On Mon, 24. Feb 2014 at 09:17:11 +0700, Mathieu Pellerin wrote:
That reminds me of someone mentioning in a ticket of a 2.0 issue resolved
against qgis 2.1 that he'd wait (angrily?) having fix backported into a
(mythical) 2.0.x update rather than him moving to 2.2 and having to deal
with possible regressions. I was thinking at the time that this sounds to
me like a flawed behavior by some QGIS users, an egg or chicken situation.
How are regressions fixed if users are not doing their parts in uncovering
and reporting them.
That led me to think there might be a very low-cost, high reward behavior
QGIS could adopt: 4, or 2, weeks before the release date, {beta,release
candidate,tech preview,etc.} builds (from master, no need to branch out
really) are pushed out to osgeo4w linux and quite loudly advertised (blog
posts, social media, etc.) to get as many users as possible to test drive
it. The users' feedback would enrich the 4-weeks period when developers are
to be focused on bug-fixing only.
Thoughts? Was that already suggested and declined?
What's the difference to the nightly builds and the weekly standalone snapshot
for Windows - except for the noise of course?
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] Post-release period of portable commits only?
Hi, I have a suggestion with regards to addressing bugs and supporting the concept of a 2.2.1 bug-fix release for stability's sake. How about for a set period of time, only commits that devs think can readily be ported to the 2.2.0 branch are 'allowed' on master? With any code changes, which would make porting changes/fixes over to the 2.2.0 branch difficult, submitted via pull requests. Maybe for two weeks? I think if code is committed to core that steamrolls over the means of providing a reasonably timed bug-fix update, it becomes that much harder to do so. I also think much user frustration may stem from that vicious cycle, and we have an opportunity to fix that *right now*. Don't get me wrong. I like the new release schedule. Just looking for ways to make it as beneficial for users as it is for devs/packagers. Best regards, Larry ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
On 23/02/2014 7:33 am, Larry Shaffer lar...@dakotacarto.com wrote: How about for a set period of time, only commits that devs think can readily be ported to the 2.2.0 branch are 'allowed' on master? With any code changes, which would make porting changes/fixes over to the 2.2.0 branch difficult, submitted via pull requests. Maybe for two weeks? As much as I'd love to see the multithreaded rendering branch land asap, I'm in favour of Larry's proposal. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
