Re: [GRASS-PSC] releases schedule
Hi, 2014-06-18 23:37 GMT+02:00 Martin Landa : [...] > I agree, if no objection I will remove `rfc` directory from SVN in the > next days. Martin done in all active branches. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Hi, 2014-06-10 11:18 GMT+02:00 Markus Neteler : > Removal is probably fine. We just need to catch the link elsewhere > (mainly Wiki + CMS) and update them. Will just be a few. I agree, if no objection I will remove `rfc` directory from SVN in the next days. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Hi, 2014-04-21 16:51 GMT+02:00 Markus Neteler : >> 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 all PSC pages from GRASS wiki http://grasswiki.osgeo.org/wiki/PSC http://grasswiki.osgeo.org/wiki/PSC_Agenda http://grasswiki.osgeo.org/wiki/PSC_election_2012 http://grasswiki.osgeo.org/wiki/Requesting_SVN_write_access to Trac wiki http://trac.osgeo.org/grass/wiki/PSC/RequestingSVNWriteAccess http://trac.osgeo.org/grass/wiki/PSC/Agenda http://trac.osgeo.org/grass/wiki/PSC/Election2012 http://trac.osgeo.org/grass/wiki/PSC Review is welcome of course:-) Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Hi, 2014-06-10 10:37 GMT+02:00 Martin Landa : > I took liberty to copy RFC1 from Programmers manual to Trac [1]. Any > comments or objections? Later I would copy rest of RFCs to Trac. > Afterwards do you prefer to simply remove `rfc` directory from source > code or to replace content of files with link to Trac? I finished moving RFCs to Trac. http://grass.osgeo.org/programming7/rfc1_psc.html -> http://trac.osgeo.org/grass/wiki/RFC/1_ProjectSteeringCommitteeGuidelines http://grass.osgeo.org/programming7/rfc2_psc.html -> http://trac.osgeo.org/grass/wiki/RFC/2_LegalAspectsOfCodeContributions http://grass.osgeo.org/programming7/rfc3_psc.html -> http://trac.osgeo.org/grass/wiki/RFC/3_PSCVotingProcedures http://grass.osgeo.org/programming7/psc_motions.html -> http://trac.osgeo.org/grass/wiki/PSC/Motions I would suggest to simply remove original pages from Programmers manual and probably to add links to RFC pages in the main doxygen page. Then we need to fix URLs in User wiki and website. Please could someone here review moved pages in Trac? Afterwards I can finish this procedure and update also doxygen. Thanks, Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Tue, Jun 10, 2014 at 5:18 AM, Markus Neteler 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 update them. Will just be a few. > Link in SUBMITTING to RFC at Trac wiki might be ideal (as Moritz suggested for SUBMITTING in another thread). ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On 10/06/14 10:37, Martin Landa wrote: Hi, 2014-04-20 13:42 GMT+02:00 Martin Landa : 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 manual to Trac [1]. Any comments or objections? +1 Moritz ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Tue, Jun 10, 2014 at 10:37 AM, Martin Landa wrote: > Hi, > > 2014-04-20 13:42 GMT+02:00 Martin Landa : >> 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 manual to Trac [1]. Any > comments or objections? Later I would copy rest of RFCs to Trac. Fine, thanks. > 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 update them. Will just be a few. Markus > Martin > > [1] http://trac.osgeo.org/grass/wiki/RFC/1_ProjectSteeringCommitteeGuidelines > > -- > Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa > ___ > grass-psc mailing list > grass-psc@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Hi, 2014-04-20 13:42 GMT+02:00 Martin Landa : > 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 manual to Trac [1]. Any comments or objections? Later I would copy rest of RFCs to Trac. Afterwards do you prefer to simply remove `rfc` directory from source code or to replace content of files with link to Trac? Martin [1] http://trac.osgeo.org/grass/wiki/RFC/1_ProjectSteeringCommitteeGuidelines -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Mon, Apr 21, 2014 at 10:51 AM, Markus Neteler wrote: > On Mon, Apr 21, 2014 at 4:48 PM, Martin Landa > wrote: > ... > > 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 > day we get at least a more recent version running... [1]. > Oh, I missed that email. I don't want to decide based on the CSS. My main concern is the cleanness of GRASS wiki (i.e. no proposals, no TODO pages) and jumping from one wiki to another. The fact is that the current situation is that all release news, repository, releasing are at Trac, so PSC may fit there. ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Mon, Apr 21, 2014 at 10:48 AM, Martin Landa wrote: > Hi, > > 2014-04-21 16:44 GMT+02:00 Markus Neteler : > >>> 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 to trac? Martin > > > > In general fine for me to move it out of the programmer's manual. > > But perhaps we use the GRASS Wiki since we already have several PSC > > related pages there? See > > > > http://grasswiki.osgeo.org/wiki/Category:PSC > > well, my preference would be to move all PSC pages from mediawiki > (user space) to trac wiki (project management, development). Martin > > This is the kind of pages I don't have clear opinion. One approach is development-related versus user-related but other approach is in-development versus state-of-art. The complication with the first is that user wants to script which is close to writing C code (e.g. ctypes) and hopefully in the future even close to GUI. This is my motivation for the "in-development versus state-of-art" rule. But RFC/PSC is unclear because it is state-of-are but user does not care even if he or she is writing C module. Hm, but he or she cares about RFC when the module is going to addons, so GRASS wiki then? Vaclav > -- > Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa > ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Mon, Apr 21, 2014 at 4:48 PM, Martin Landa wrote: ... > 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 day we get at least a more recent version running... [1]. Markus [1] http://trac.osgeo.org/osgeo/ticket/592 ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Hi, 2014-04-21 16:44 GMT+02:00 Markus Neteler : >>> 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 to trac? Martin > > In general fine for me to move it out of the programmer's manual. > But perhaps we use the GRASS Wiki since we already have several PSC > related pages there? See > > http://grasswiki.osgeo.org/wiki/Category:PSC well, my preference would be to move all PSC pages from mediawiki (user space) to trac wiki (project management, development). Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Mon, Apr 21, 2014 at 1:47 PM, Martin Landa wrote: > Hi all, > > 2014-04-21 4:57 GMT+02:00 Vaclav Petras : > > [...] > >>> 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? >> >> >> 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 to trac? Martin In general fine for me to move it out of the programmer's manual. But perhaps we use the GRASS Wiki since we already have several PSC related pages there? See http://grasswiki.osgeo.org/wiki/Category:PSC Markus ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Hi all, 2014-04-21 4:57 GMT+02:00 Vaclav Petras : [...] >> 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? > > > 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 to trac? Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Sun, Apr 20, 2014 at 7:42 AM, Martin Landa wrote: > > 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 work on it? > > I'm. Not right now, but in next weeks yes. I'm not sure what means work on it. I have to look at the other RFC what would be the appropriate format etc. Then I have to go through comments here but I guess more comments are needed but perhaps after I draft it first. > 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? > 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). Vaclav ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Hi Vaclav, 2014-04-01 17:20 GMT+02:00 Vaclav Petras : > 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 proposal should be defined as RFC4 [1]. Are you willing to work on it? 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 -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Thu, Apr 17, 2014 at 11:39 PM, Martin Landa wrote: > Hi all, > > 2014-04-01 17:30 GMT+02:00 Yann Chemin : >> Maybe we should have a call to PSC members? Just a remark: For this there should be more active developers in the PSC (in the past 20+ years, this kind of decision was usually taken in grass-dev). > there interesting discussion on GDAL ML [1]. Martin > > [1] http://lists.osgeo.org/pipermail/gdal-dev/2014-April/038835.html Indeed! Thanks for the pointer. Markus ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Hi all, 2014-04-01 17:30 GMT+02:00 Yann Chemin : > 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 ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Maybe we should have a call to PSC members? +1 to start with Vaclav's proposal. On 1 April 2014 20:50, Vaclav Petras wrote: > > On Mon, Mar 31, 2014 at 11:09 PM, Yann Chemin 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 now. > > (1) It does not completely fit into what I think Trac should be used for > but all other things about releases are there anyway. > -- ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Mon, Mar 31, 2014 at 11:09 PM, Yann Chemin 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 now. (1) It does not completely fit into what I think Trac should be used for but all other things about releases are there anyway. ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On Mon, Mar 31, 2014 at 11:40 AM, Vaclav Petras 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 into >> bugfix-only phase for the last month or two. During the first period new >> features can be ported to the release branch once they have had some >> testing in trunk. >> >> > Moritz, I believe that these are two different things. > > ... > > Second, committing features to both branches is what is taking the time > from us and creating uncertainty about what is where and what are the > branches for. I think that this is crucial point and the lengths of time > periods above should be decided based on this, not the other way around. > > On Mon, Mar 31, 2014 at 11:09 PM, Yann Chemin wrote: > It looks like we all want to see version numbers move on a yearly basis > with periods of branching and periods of releasing... We need to agree on the policy of committing to release branch(es). See my proposal [1] for details. [1] http://lists.osgeo.org/pipermail/grass-psc/2014-March/001150.html ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
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 wrote: > Hi all, > > 2014-03-31 20:07 GMT+02:00 Luca Delucchi : > > On 31 March 2014 17:40, Vaclav Petras 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 reasons for this. The length of period between fork and release > can > >> be probably anything from 1 month to 6 months. The length of period > after > >> release to next release should be the rest so from 6 month to 11. > >> > > > > +1 I think the same. > > For my point of view the length of period between fork and release > > could be reasonable between 2 and 4 months and the others 8-6 months > > after release > > I would strongly agree with such release policy. Martin > > -- > Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa > ___ > grass-psc mailing list > grass-psc@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-psc > -- ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
Hi all, 2014-03-31 20:07 GMT+02:00 Luca Delucchi : > On 31 March 2014 17:40, Vaclav Petras 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 reasons for this. The length of period between fork and release can >> be probably anything from 1 month to 6 months. The length of period after >> release to next release should be the rest so from 6 month to 11. >> > > +1 I think the same. > For my point of view the length of period between fork and release > could be reasonable between 2 and 4 months and the others 8-6 months > after release I would strongly agree with such release policy. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
On 31 March 2014 17:40, Vaclav Petras 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 reasons for this. The length of period between fork and release can > be probably anything from 1 month to 6 months. The length of period after > release to next release should be the rest so from 6 month to 11. > +1 I think the same. For my point of view the length of period between fork and release could be reasonable between 2 and 4 months and the others 8-6 months after release > > Vaclav > -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
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 before the release. I expect comments and >> criticism and I would be glad to compare this proposal with some other >> proposal. >> >> Vaclav >> >> >> Releasing and branch management should follow these steps: >> >> 1. have trunk >> 2. fork release branch , e.g. release_7_1 >> 3. only bugfixes to release branch, new features (additions, >> >> refactoring, documentation) only to trunk >> 4. release new version based on release branch, , e.g. 7.1.0 >> 5. only critical bugfixes go to release branch, release patched version >> >> if needed, e.g. 7.1.1, .7.1.2 >> 6. fork a new release branch (e.g. release_7_2), set old release branch >> >> to readonly and continue with point 3. >> >> It seems that release should be done every year. A new release branch >> should be forked half a year before planned release. >> > > 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 into > bugfix-only phase for the last month or two. During the first period new > features can be ported to the release branch once they have had some > testing in trunk. > > Moritz, I believe that these are two different things. 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 reasons for this. The length of period between fork and release can be probably anything from 1 month to 6 months. The length of period after release to next release should be the rest so from 6 month to 11. Second, committing features to both branches is what is taking the time from us and creating uncertainty about what is where and what are the branches for. I think that this is crucial point and the lengths of time periods above should be decided based on this, not the other way around. Vaclav > Moritz > ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
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 without any release. Periods of release cycle should be discussed. We also may modify them after few releases according to practical experience. Best Stepan " 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 proposal with some other proposal. Vaclav Releasing and branch management should follow these steps: 1. have trunk 2. fork release branch , e.g. release_7_1 3. only bugfixes to release branch, new features (additions, refactoring, documentation) only to trunk 4. release new version based on release branch, , e.g. 7.1.0 5. only critical bugfixes go to release branch, release patched version if needed, e.g. 7.1.1, .7.1.2 6. fork a new release branch (e.g. release_7_2), set old release branch to readonly and continue with point 3. It seems that release should be done every year. A new release branch should be forked half a year before planned release. As a consequence, there would be a new branch every year. A new branch is forked from trunk in its current state. Time of forking is specified, so doing larger changes can be postponed if necessary. Alternatively, particular commits can be reverted if necessary. After a half year of bugfixing the release branch (by backports from trunk) we release. In next half a year after release, subsequent patch releases will be provided in case of critical bugs. In this period, almost all changes are in trunk only since only critical bug fixes go to release branch. After this period, new release branch is forked again from trunk and cycle starts again. Semantic versioning (http://semver.org/(http://semver.org/)) will be used (MAJOR.MINOR.PATCH). New releases gets new MINOR if they are backwards compatible, MAJOR if they are not. Critical bugfixes of released version gets new PATCH. When a new development branch is forked, a release candidate (MAJOR.MINOR. PATCH-RC1) or some other pre-release version can be released. This can repeat during the half year of bugfixing of release branch (in random or exact intervals or based on fixed bugs). Larger experimental changes (e.g. storage format changes, things like temporal framework) should be done in a separate branch (or repository if more convenient). Then they should be committed to trunk and branch should be set to readonly. Ideal time for introducing new changes is after forking of a new release branch. Situation with some better, although perhaps experimental, branch and a completely separated release branch should be avoided. To make it clear, we should avoid situation when we are developing two versions of GRASS such as 6 and 7, and similarly we should not start development of GRASS 8 by forking branch devel_8. To be sure what we are doing, we should perhaps discuss what are backwards incompatible changes (cases for MAJOR version); we have the following interfaces: GUI, workspace file, GUI API, modules, C API (and ctypes), Python API (to modules and general) and vector, invoking GRASS from command line, raster, 3D raster and temporal database formats. On Sat, Mar 29, 2014 at 2:35 AM, Luca Delucchi mailto:lucadel...@gmail.com)> wrote: "Hi PSC, during the code sprint we spoke about releases schedule to improve the GRASS GIS's quality specially for "our" user experience. I have no a clear idea about a really good idea. During the code sprint we spoke about the possibility to release once a year and six month before put the release branch in freezing mode for testing and bug fixes. Could you find a good solution about this topic, I think this is crucial element for the future of GRASS Thanks Best regards -- ciao Luca http://gis.cri.fmach.it/delucchi/(http://gis.cri.fmach.it/delucchi/) www.lucadelu.org(http://www.lucadelu.org) ___ grass-psc mailing list grass-psc@lists.osgeo.org(mailto:grass-psc@lists.osgeo.org) http://lists.osgeo.org/mailman/listinfo/grass-psc (http://lists.osgeo.org/mailman/listinfo/grass-psc) " ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc";___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
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 proposal with some other proposal. Vaclav Releasing and branch management should follow these steps: 1. have trunk 2. fork release branch , e.g. release_7_1 3. only bugfixes to release branch, new features (additions, refactoring, documentation) only to trunk 4. release new version based on release branch, , e.g. 7.1.0 5. only critical bugfixes go to release branch, release patched version if needed, e.g. 7.1.1, .7.1.2 6. fork a new release branch (e.g. release_7_2), set old release branch to readonly and continue with point 3. It seems that release should be done every year. A new release branch should be forked half a year before planned release. 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 into bugfix-only phase for the last month or two. During the first period new features can be ported to the release branch once they have had some testing in trunk. Moritz ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
> 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 context: http://osgeo-org.1560.x6.nabble.com/releases-schedule-tp5131995p5132062.html Sent from the GRASS-PSC mailing list archive at Nabble.com. ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] releases schedule
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 proposal with some other proposal. Vaclav Releasing and branch management should follow these steps: 1. have trunk 2. fork release branch , e.g. release_7_1 3. only bugfixes to release branch, new features (additions, refactoring, documentation) only to trunk 4. release new version based on release branch, , e.g. 7.1.0 5. only critical bugfixes go to release branch, release patched version if needed, e.g. 7.1.1, .7.1.2 6. fork a new release branch (e.g. release_7_2), set old release branch to readonly and continue with point 3. It seems that release should be done every year. A new release branch should be forked half a year before planned release. As a consequence, there would be a new branch every year. A new branch is forked from trunk in its current state. Time of forking is specified, so doing larger changes can be postponed if necessary. Alternatively, particular commits can be reverted if necessary. After a half year of bugfixing the release branch (by backports from trunk) we release. In next half a year after release, subsequent patch releases will be provided in case of critical bugs. In this period, almost all changes are in trunk only since only critical bug fixes go to release branch. After this period, new release branch is forked again from trunk and cycle starts again. Semantic versioning (http://semver.org/) will be used (MAJOR.MINOR.PATCH). New releases gets new MINOR if they are backwards compatible, MAJOR if they are not. Critical bugfixes of released version gets new PATCH. When a new development branch is forked, a release candidate (MAJOR.MINOR.PATCH-RC1) or some other pre-release version can be released. This can repeat during the half year of bugfixing of release branch (in random or exact intervals or based on fixed bugs). Larger experimental changes (e.g. storage format changes, things like temporal framework) should be done in a separate branch (or repository if more convenient). Then they should be committed to trunk and branch should be set to readonly. Ideal time for introducing new changes is after forking of a new release branch. Situation with some better, although perhaps experimental, branch and a completely separated release branch should be avoided. To make it clear, we should avoid situation when we are developing two versions of GRASS such as 6 and 7, and similarly we should not start development of GRASS 8 by forking branch devel_8. To be sure what we are doing, we should perhaps discuss what are backwards incompatible changes (cases for MAJOR version); we have the following interfaces: GUI, workspace file, GUI API, modules, C API (and ctypes), Python API (to modules and general) and vector, invoking GRASS from command line, raster, 3D raster and temporal database formats. On Sat, Mar 29, 2014 at 2:35 AM, Luca Delucchi wrote: > Hi PSC, > > during the code sprint we spoke about releases schedule to improve the > GRASS GIS's quality specially for "our" user experience. > I have no a clear idea about a really good idea. During the code > sprint we spoke about the possibility to release once a year and six > month before put the release branch in freezing mode for testing and > bug fixes. > > Could you find a good solution about this topic, I think this is > crucial element for the future of GRASS > > Thanks > Best regards > > -- > ciao > Luca > > http://gis.cri.fmach.it/delucchi/ > www.lucadelu.org > ___ > grass-psc mailing list > grass-psc@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-psc > ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
[GRASS-PSC] releases schedule
Hi PSC, during the code sprint we spoke about releases schedule to improve the GRASS GIS's quality specially for "our" user experience. I have no a clear idea about a really good idea. During the code sprint we spoke about the possibility to release once a year and six month before put the release branch in freezing mode for testing and bug fixes. Could you find a good solution about this topic, I think this is crucial element for the future of GRASS Thanks Best regards -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
