[Qgis-developer] Release plans

Nathan Woodrow madmanwoo at gmail.com
Thu Jun 26 16:03:08 PDT 2014


I am aware it was a late email, I have been busy on non qgis jobs and
haven't been able to look side ways.

On Fri, Jun 27, 2014 at 2:03 AM, Paolo Cavallini <cavallini at faunalia.it>
wrote:

> 1. do not change anything in the relase schedule just one day before
> 2. announcements should be clear: (a) QGIS 2.4 is out, wait for packages;
> (b) package
> for {Debian|Ubuntu|whatever} is ready, go and download it from http://...
>

1. Surly it's not hard to build the package an two hours or so before the
release and have it ready go, even if this a last minute call. As much as
it pains people Windows is our biggest user base so they need to be there,
followed by Debian, then OS X.

2) There is no different for a user between a) and b) a "release" is a
binary release like I said.  Making it a two stage process is just
confusing and annoying to users.  Trying to make people understand the
"process" by doing this isn't really right IMO.  Users don't need to care
how packages are built or how long it takes, the people that know or need
too tend to be involved at the project level anyway. Users just need a
package to install on release day, a "source" release is like say "yay
release!....But no you can't have it because your just a user you have to
wait".

Jürgen,

Looks like announcing the (source) release on qgis-developer and announcing
> individual packages on qgis-user would solve that problem.


This will make no difference, people watch the dev list especially around
release time for news. Once you announce any kind of "release", source or
not, you have lost the ability to control where it will go and what people
expect. Just watch how quick it will hit twitter, and then watch as people
get confused why there is no download. It's mainly wording, it's all in the
wording.

People really like our software and some are super excited about the
release, to not have packages for download really looks bad IMO.

To me there's not much point in having master frozen, while everyone is just
> waiting for packages to be built.


That is why I said it would only be a day or so before release, it
shouldn't take more then day to build a package for any of the major
platforms and update the site. All we would have to do is branch the code a
day out, package, release.  If you push something non package related on
that last day before the release then it will just have to wait until next
release, or a patched release. People can't be pushing fixes last second as
that is just dangerous.

That was the first time - it might have come unexpected to the user.
>  They'll
> probably get used to it..


They shouldn't that is the point I'm making.  We don't expect that with
other things.  If I see a new release of Python is out and I go to the site
and don't see a binary package it will be a long while before I go back I
have other things to be doing.

I rather get the (source) release done, get my packages done (a good share
> of
> the above) and then get back to master...


I understand, just don't call it a "release". Branch it today and call it a
"call for packages" (don't use the word "out" or "release"), wait a few
days then binary release. You and I know what a source release is, users
don't care.  We really need some stats on our user base so we know what
platforms are our major target ones.

This raises the question how quickly are you expecting to have major
packages done?  If we source release tonight but don't have packages ready
by Monday, Tuesday, there is 4 days of people hitting our site with no way
to download the packages and this looks really bad.

Why not call for packages today, let people get sorted over the weekend,
update the site, release on Monday, Tuesday?

I know it sounds like a rant, because it kind of is, but I really enjoy
working on the project, the package is great, the people are great, but I
find this current release process stressful and I'm not one calling the
release.  Stressful because I know we have a lot of users who love our
stuff but can't get it when we say it's "out".

If you don't want to change it for this release, OK, but I think we need to
review it for the next release so everyone is on the same page.  There are
are other large projects we can steal the process from.

- Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140627/23f92329/attachment-0001.html>


More information about the Qgis-developer mailing list