Re: [GRASS-PSC] too many branches
On 29/03/14 07:04, Luca Delucchi wrote: Hi PSC, with the upcoming GRASS 7 release we have to many branches to maintain (releasebranch6, devbranch6, releasebranch7 and trunk). Can I ask you to take a decision about the future of all this branches? I could suggest something like: - keep releasebranch6 only for important bugfixes, no new feature and starting to forget it - put in reading mode or remove (after backport the differences with grass64) devbranch6 - releasebranch7 is the new stable release branch, so new features only when we are far from release a new version - trunk for new feature what do you think? The initial idea was to create a tech-preview release of grass7, not an official 7.0 release. Has that changed during the sprint ? If we only do a tech release, I don't think we really need a releasebranch. Just a short (max 2 weeks) commit freeze to trunk to make sure everything compiles and runs as expected (with known bugs) and then release. Concerning grass6, I agree that we should probably merge release and dev. Maybe - backport anything from dev to release that is stable enough for release (if there is anything left to backport) - publish grass6.4.4 - if there is anything in 6-dev which is not in trunk, then forward-port that if necessary/feasible - then, as you propose, abandon 6-dev and keep 6-release in maintenance mode Moritz ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
Dear PSC, 2014-03-31 4:30 GMT+02:00 Yann Chemin yche...@gmail.com: +1 to remove devbranch6 after appropriate transfer of the needed to releasebranch6. same here +1, maybe not to remove, just to set as read only Do we have a tentative time line to freeze Grass6 release branch (1 year?) You mean GRASS 7 I guess, I personally think that we could freeze the release branch in July and probably release GRASS 7 in September or so... It is just my personal opinion. Martin ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
On Mon, Mar 31, 2014 at 4:30 AM, Yann Chemin yche...@gmail.com wrote: In favour of giving the devbranch6 a prune, I cannot remember when I used grass6-dev last time... Obviously will maintain GRASS 6.4.x for more time, that's our LTS... +1 to remove devbranch6 after appropriate transfer of the needed to releasebranch6. I would speak about putting devbranch6 into read-only mode soon. There are still many changes not yet being backported to releasebranch64... a situation which I rather dislike. So devbranch6 should not be pruned but set to readonly. Markus ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
On Mon, Mar 31, 2014 at 10:24 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: The initial idea was to create a tech-preview release of grass7, not an official 7.0 release. Has that changed during the sprint ? No, this is what happened: beta1 (called like this to maintain consistency with previous pre-releases). See also (pls improve that page!): http://trac.osgeo.org/grass/wiki/Release/7.0.0beta-News If we only do a tech release, I don't think we really need a releasebranch. Just a short (max 2 weeks) commit freeze to trunk to make sure everything compiles and runs as expected (with known bugs) and then release. This is likely causing more work than it helps. but we can see how it evolves. Concerning grass6, I agree that we should probably merge release and dev. Maybe - backport anything from dev to release that is stable enough for release (if there is anything left to backport) There is a LOT left since some people only feed devbr6 and then don't backport to relbr6... I got a bit tired of comparing it (did so many times in the past). - publish grass6.4.4 Yes. Since we also fixed the r.li suite, it looks pretty good. - if there is anything in 6-dev which is not in trunk, then forward-port that if necessary/feasible Perhaps there is, not idea (see comment above). - then, as you propose, abandon 6-dev and keep 6-release in maintenance mode Yes. Markus ___ 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] too many branches
On 31/03/14 10:34, Markus Neteler wrote: On Mon, Mar 31, 2014 at 10:24 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: The initial idea was to create a tech-preview release of grass7, not an official 7.0 release. Has that changed during the sprint ? No, this is what happened: beta1 (called like this to maintain consistency with previous pre-releases). I did see that, but for me a beta release is a first version of what will be a final grass7.0 release. A tech-preview, in my understanding, is more of a snapshot of an ongoing development branch. But if the general feeling is that we can actually release a grass7.0 by the summer or early autumn, then let's do it. See also (pls improve that page!): http://trac.osgeo.org/grass/wiki/Release/7.0.0beta-News If we only do a tech release, I don't think we really need a releasebranch. Just a short (max 2 weeks) commit freeze to trunk to make sure everything compiles and runs as expected (with known bugs) and then release. This is likely causing more work than it helps. but we can see how it evolves. I think it creates more work during the short freeze, but avoids the need of multiplying branches. If the procedure is clear and the calendar is agreed upon and all devs collaborate then it shouldn't be too much trouble. 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 lucadel...@gmail.com (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 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
[GRASS-PSC] Sponsoring program
PSC, we have received a donation from a company where the donor expected to be listed at http://grass.osgeo.org/support/our-sponsors/ We (Martin and me) assumed that they donated for the Vienna Sprint (list of donors is on the Wiki page) but they expect to be mentioned on the main site. Since we do not communicate well who-goes-where, I suggest that we develop a sponsorship program like other OSGeo projects to (or OSGeo itself). We need to clearly communicate what a sponsor will get back at which amount. Suggestions are welcome, Markus -- GRASS PSC chair ___ 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 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 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
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 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 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
