Hi,
2014-04-21 16:51 GMT+02:00 Markus Neteler nete...@osgeo.org:
well, my preference would be to move all PSC pages from mediawiki
(user space) to trac wiki (project management, development). Martin
Sure, would make sense. Just the trac-wiki is so ugly :-) Maybe one
I took liberty to move
Hi,
2014-04-20 13:42 GMT+02:00 Martin Landa landa.mar...@gmail.com:
BTW, I think that better place for RFC's would be Trac wiki rather
than API manual (it's duplicated for G6 and G7). What do you think?
[1] http://trac.osgeo.org/grass/wiki/RfcList
I took liberty to copy RFC1 from Programmers
On Tue, Jun 10, 2014 at 10:37 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2014-04-20 13:42 GMT+02:00 Martin Landa landa.mar...@gmail.com:
BTW, I think that better place for RFC's would be Trac wiki rather
than API manual (it's duplicated for G6 and G7). What do you think?
[1]
On Tue, Jun 10, 2014 at 5:18 AM, Markus Neteler nete...@osgeo.org wrote:
Afterwards do you prefer to simply remove `rfc` directory from source
code or to replace content of files with link to Trac?
Removal is probably fine. We just need to catch the link elsewhere
(mainly Wiki + CMS) and
Hi,
2014-04-21 16:44 GMT+02:00 Markus Neteler nete...@osgeo.org:
The duplication is certainly dangerous here. Trac seems like a proper place
(although this does not completely fit to the Trac wiki rules I proposed
because it does not fit anywhere).
Any objections to move RFC from API manual
On Mon, Apr 21, 2014 at 10:48 AM, Martin Landa landa.mar...@gmail.comwrote:
Hi,
2014-04-21 16:44 GMT+02:00 Markus Neteler nete...@osgeo.org:
The duplication is certainly dangerous here. Trac seems like a proper
place
(although this does not completely fit to the Trac wiki rules I
On Mon, Apr 21, 2014 at 10:51 AM, Markus Neteler nete...@osgeo.org wrote:
On Mon, Apr 21, 2014 at 4:48 PM, Martin Landa landa.mar...@gmail.com
wrote:
...
well, my preference would be to move all PSC pages from mediawiki
(user space) to trac wiki (project management, development). Martin
Hi Vaclav,
2014-04-01 17:20 GMT+02:00 Vaclav Petras wenzesl...@gmail.com:
Probably yes. Does PSC have to vote on this?
I would say yes.
We put the proposal to Trac wiki (1), so we can track changes into it. In
future it can go to (Doxygen) documentation but not now.
I would say that this
On Sun, Apr 20, 2014 at 7:42 AM, Martin Landa landa.mar...@gmail.comwrote:
We put the proposal to Trac wiki (1), so we can track changes into it. In
future it can go to (Doxygen) documentation but not now.
I would say that this proposal should be defined as RFC4 [1]. Are you
willing to
Hi all,
2014-04-01 17:30 GMT+02:00 Yann Chemin yche...@gmail.com:
Maybe we should have a call to PSC members?
there interesting discussion on GDAL ML [1]. Martin
[1] http://lists.osgeo.org/pipermail/gdal-dev/2014-April/038835.html
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On Mon, Mar 31, 2014 at 11:40 AM, Vaclav Petras wenzesl...@gmail.com
wrote:
I find that 6 months is a fairly long period to maintain a bugfix-only
branch. I would rather propose to either branch later, or to allow more
than just bugfixes into the release branch for 4-5 months before going
On Mon, Mar 31, 2014 at 11:09 PM, Yann Chemin yche...@gmail.com wrote:
Should we finalize this policy and implement it?
Probably yes. Does PSC have to vote on this?
We put the proposal to Trac wiki (1), so we can track changes into it. In
future it can go to (Doxygen) documentation but not
On 29/03/14 21:56, Vaclav Petras wrote:
Inspired by what code sprint people were saying, I put together my
proposal. It counts with release once a year and a half year bugfixing
(feature freeze) period before the release. I expect comments and
criticism and I would be glad to compare this
Hi Vasek,
your proposal is identical to my opinion. Taking into account number of
developers of GRASS GIS, the proposal seems to me as best solution to avoid
recurrence of current state when GRASS 7 has become used as stable by many
users as consequence of many years of development
On Mon, Mar 31, 2014 at 4:35 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 29/03/14 21:56, Vaclav Petras wrote:
Inspired by what code sprint people were saying, I put together my
proposal. It counts with release once a year and a half year bugfixing
(feature freeze) period
Hi all,
2014-03-31 20:07 GMT+02:00 Luca Delucchi lucadel...@gmail.com:
On 31 March 2014 17:40, Vaclav Petras wenzesl...@gmail.com wrote:
First, the lengths of time periods. First question is how often we want to
release MAJOR.MINOR version. Once a year looks good for me but I have no
special
It looks like we all want to see version numbers move on a yearly basis
with periods of branching and periods of releasing...
Should we finalize this policy and implement it?
On 31 March 2014 23:54, Martin Landa landa.mar...@gmail.com wrote:
Hi all,
2014-03-31 20:07 GMT+02:00 Luca
It counts with release once a year and a half year bugfixing (feature
freeze) period before the release.
+1 for release once a year and your proposal; maybe some fine tuning is
needed to follow the KISS-strategy ... for users and devs!
-
best regards
Helmut
--
View this message in
18 matches
Mail list logo
