roadmap

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

roadmap

pcav
Hi all.
I think not having a roadmap and a timeline can confuse both users and
packagers. How about establishing a plan for two major releases per year (plus
eventual minor, bugfix releases), with a fixed (with some flexibility of course)
calendar?
Something like:

- 1 August 2009 - 1.2 feature freeze
- 14 August - string freeze and call for translation updates
- 21 August - tag for release and call for packaging
- 31 August - release announcement

- eventual releases of minor versions (bugfix) when needed

- 1 February 2010 - 1.3 feature freeze
- 14 February - string freeze and call for translation updates
- 21 February - tag for release and call for packaging
- 31 February - release announcement

And so on. Just take it as an example - any different arrangement of dates would
be ok for me, I'm mainly interested in checking whether a similar schedule is
feasible, and if it makes sense.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: roadmap

Lorenzo Masini
On Wednesday 29 July 2009 20:48:50 Paolo Cavallini wrote:
> And so on. Just take it as an example - any different arrangement of dates
> would be ok for me, I'm mainly interested in checking whether a similar
> schedule is feasible, and if it makes sense.
> All the best.

In my opinion could be a good thing to release new qgis versions in fixed
dates, for example, every 6 months.
This should permit us to write a feature plan with some middle milestones.
What do you think about?

regards
Lorenzo
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: roadmap

enricoG
In reply to this post by pcav
Dear Paolo, hi list

> - 1 February 2010 - 1.3 feature freeze
> - 14 February - string freeze and call for translation updates
> - 21 February - tag for release and call for packaging
> - 31 February - release announcement

really good idea!

even if 31 February seems not so good as milestone
for users like me anxiously waiting for 1.3 release... :D


best regards, ciao

Enrico Gallo
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: roadmap

Tim Sutton-4
In reply to this post by Lorenzo Masini
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

Lorenzo Masini wrote:

> On Wednesday 29 July 2009 20:48:50 Paolo Cavallini wrote:
>> And so on. Just take it as an example - any different arrangement of dates
>> would be ok for me, I'm mainly interested in checking whether a similar
>> schedule is feasible, and if it makes sense.
>> All the best.
>
> In my opinion could be a good thing to release new qgis versions in fixed
> dates, for example, every 6 months.
> This should permit us to write a feature plan with some middle milestones.
> What do you think about?
>
> regards
> Lorenzo
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>

I also like this idea but we've tried it before and had problems. Since
we rely on people to work on stuff in their free time its very hard to
impose deadlines on anybody. The current system we have works very well
- - where we leave some time for open commits, send out a 'ok to release?'
email, and if everyone is happy plan a release schedule over the course
of the next month.

Perhaps things will be different now that we have a codebase that is
more stabilised and we are working in branches, so I am game to try
again since I would also like to see:

- - a yearly stable release that will have maintenance updates
- - several unstable releases for those who want to have the latest &
greatest


regards



- --

Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==============================================

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpynRgACgkQqk07qZdiYjcUVACfSNzsyqHH/k+B1OKPFxHsSC8k
H9UAoMzLhWJjqlRi+J1dY/UuSWBVEVbZ
=L2SJ
-----END PGP SIGNATURE-----
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Re: roadmap

Borys Jurgiel-2
In reply to this post by enricoG
Friday 31 of July 2009 09:02:07 Enrico Gallo napisał(a):

> Dear Paolo, hi list
>
> > - 1 February 2010 - 1.3 feature freeze
> > - 14 February - string freeze and call for translation updates
> > - 21 February - tag for release and call for packaging
> > - 31 February - release announcement
>
> really good idea!
>
> even if 31 February seems not so good as milestone
> for users like me anxiously waiting for 1.3 release... :D

Yes, it can never be released... :( 31 February is good for me, but what about
setting more feasible date?  :)

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: roadmap

pcav
In reply to this post by Tim Sutton-4
Tim Sutton ha scritto:

> I also like this idea but we've tried it before and had problems. Since
> we rely on people to work on stuff in their free time its very hard to
> impose deadlines on anybody. The current system we have works very well

Hi Tim.
This is the point: according to what I hear, the system is not working very
well, both for users (I often receive requests like "when will I be able to use
version 1.2? When will be feature yyy available to general public?) and for
packagers (we still miss proper official packages for Debian, and therefore also
for all derived distros). My suggestion came from their requests.

> - where we leave some time for open commits, send out a 'ok to release?'
> email, and if everyone is happy plan a release schedule over the course
> of the next month.
>
> Perhaps things will be different now that we have a codebase that is
> more stabilised and we are working in branches, so I am game to try
> again since I would also like to see:
>
> - a yearly stable release that will have maintenance updates
> - several unstable releases for those who want to have the latest &
> greatest

Don't you think an alternative approach is easier?
Since the code base is mostly quite stable (always compiling smoothly, only 3
critical bugs left), I think we can basically release any time, without major
issues. So why not deciding fixed times, and release the best code we have twice
a year?
Anyway, *you* are the release manager, and I respect your decision :)
I'm raising the point only to make users happy, and to have good packages,
especially for Debian and derivatives. This would also help preparing
documentation in time, I think.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: roadmap

Tim Sutton-4
Hi

On Sat, Aug 1, 2009 at 10:38 AM, Paolo Cavallini<[hidden email]> wrote:

> Tim Sutton ha scritto:
>
>> I also like this idea but we've tried it before and had problems. Since
>> we rely on people to work on stuff in their free time its very hard to
>> impose deadlines on anybody. The current system we have works very well
>
> Hi Tim.
> This is the point: according to what I hear, the system is not working very
> well, both for users (I often receive requests like "when will I be able to use
> version 1.2? When will be feature yyy available to general public?) and for
> packagers (we still miss proper official packages for Debian, and therefore also
> for all derived distros). My suggestion came from their requests.
>
>> - where we leave some time for open commits, send out a 'ok to release?'
>> email, and if everyone is happy plan a release schedule over the course
>> of the next month.
>>
>> Perhaps things will be different now that we have a codebase that is
>> more stabilised and we are working in branches, so I am game to try
>> again since I would also like to see:
>>
>> - a yearly stable release that will have maintenance updates
>> - several unstable releases for those who want to have the latest &
>> greatest
>
> Don't you think an alternative approach is easier?
> Since the code base is mostly quite stable (always compiling smoothly, only 3
> critical bugs left), I think we can basically release any time, without major
> issues.

Yes that is why we requested people to move feature development into
branches always - to keep svn trunk in a near release ready state.

>So why not deciding fixed times, and release the best code we have twice
> a year?

Like I said in the previous post I am happy to try doing fixed date
releases again.


> Anyway, *you* are the release manager, and I respect your decision :)
> I'm raising the point only to make users happy, and to have good packages,
> especially for Debian and derivatives. This would also help preparing
> documentation in time, I think.


To be honest I have given up trying to figure out the various arcane
requirements needed for debian packages. I understand the need for
quality control but most of the things they ask for are beyond my
understanding. If we are ever to meet their criteria I think we need a
bit more hand holding. Juergen has carried out their requests as they
have come up as best I can recall, but I think even his seemingly
limitless persistence must be wearing out by now.


Regards

Tim

> All the best.
> --
> Paolo Cavallini: http://www.faunalia.it/pc
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



--
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==============================================
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Plugin installer and unavailable repo

Maxim Dubinin
In reply to this post by Borys Jurgiel-2
Hello QGISers and especially Borys,

Experienced something stange today with Plugin installer. One of the
3rd party repos went offline (Barry's), but instead of gracefully
letting me now about this, Plugin installer kept showing this error
and as a result didn't work at all:

***************************************************************
Traceback (most recent call last):
  File "C:/OSGeo4W/apps/qgis-dev/./python/plugins\plugin_installer\installer_plugin.py", line 162, in run
    QMessageBox.warning(parent, QCoreApplication.translate("QgsPluginInstaller","QGIS Python Plugin Installer"), QCoreApplication.translate("QgsPluginInstaller","Error reading repository:") + u' %s\n%s' % (key,repositories.all()[key]["error"]))
TypeError: unsupported operand type(s) for +: 'QString' and 'unicode'
***************************************************************

My solution was to go in the code and comment a portion that
complained and after it finally was able to load up - remove Barry's repo (sorry
Barry). Then I restored the code to the original and everything back
to normal.

This might be something very specific, but may be worth looking into.

Maxim

Вы писали 31 июля 2009 г., 8:59:56:

BJ> Friday 31 of July 2009 09:02:07 Enrico Gallo napisał(a):

>> Dear Paolo, hi list
>>
>> > - 1 February 2010 - 1.3 feature freeze
>> > - 14 February - string freeze and call for translation updates
>> > - 21 February - tag for release and call for packaging
>> > - 31 February - release announcement
>>
>> really good idea!
>>
>> even if 31 February seems not so good as milestone
>> for users like me anxiously waiting for 1.3 release...  

BJ> Yes, it can never be released...   31 February is good for me, but what about
BJ> setting more feasible date?  :)

BJ> _______________________________________________
BJ> Qgis-developer mailing list
BJ> [hidden email]
BJ> http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Plugin installer and unavailable repo

Maxim Dubinin
it seems like this is not only Plugin installer
issue, I'm having the same type of error with fTools.

***********************************************************************
Traceback (most recent call last):
  File "C:\OSGeo4W\apps\qgis-1.1\python\plugins\fTools\tools\doGeoprocessing.py", line 180, in runFinishedFromThread
    + unicode( self.shapefileName ) + out_text + end_text, QMessageBox.Yes, QMessageBox.No, QMessageBox.NoButton )
TypeError: unsupported operand type(s) for +: 'QString' and 'unicode'
***********************************************************************

some changes introduced with new QT or my machine glitches?

Maxim

Вы писали 4 августа 2009 г., 12:13:39:

MD> Hello QGISers and especially Borys,

MD> Experienced something stange today with Plugin installer. One of the
MD> 3rd party repos went offline (Barry's), but instead of gracefully
MD> letting me now about this, Plugin installer kept showing this error
MD> and as a result didn't work at all:

MD> ***************************************************************
MD> Traceback (most recent call last):
MD>   File
MD> "C:/OSGeo4W/apps/qgis-dev/./python/plugins\plugin_installer\installer_plugin.py", line 162, in run
MD>     QMessageBox.warning(parent,
MD> QCoreApplication.translate("QgsPluginInstaller","QGIS Python
MD> Plugin Installer"),
MD> QCoreApplication.translate("QgsPluginInstaller","Error reading
MD> repository:") + u' %s\n%s' %
MD> (key,repositories.all()[key]["error"]))
MD> TypeError: unsupported operand type(s) for +: 'QString' and 'unicode'
MD> ***************************************************************

MD> My solution was to go in the code and comment a portion that
MD> complained and after it finally was able to load up - remove Barry's repo (sorry
MD> Barry). Then I restored the code to the original and everything back
MD> to normal.

MD> This might be something very specific, but may be worth looking into.

MD> Maxim

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer