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=20140620T12&p0=1440&msg=QGIS+2.4+Release
>
> --
> Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13 Fax. +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
