Re: [GRASS-dev] GitHub backport label proposal
Le 22/11/2022 à 19:51, Nicklas Larsson a écrit : Looks like a clever little bot. In case that is the way the community choose to go then the label will have to be “backport releasebranch_8_2”, which is very long… I also wonder how useful it would be at the moment for GRASS, e.g. wide ranging indentation changes often causes conflicts between main and latest release branches. Sure the bot just tries to git cherry-pick commits, and if they don't apply cleanly, it obviously fails, with reports like https://github.com/qgis/QGIS/pull/50943#issuecomment-1322647971 -- http://www.spatialys.com My software is free, but my time generally not. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub backport label proposal
On Tue, 22 Nov 2022 at 14:54, Nicklas Larsson via grass-dev < grass-dev@lists.osgeo.org> wrote: > ...In case that is the way the community choose to go then the label will > have to be “backport releasebranch_8_2”, which is very long… > We could revisit the names of branches. The word branch seems unnecessary, esp. when the readability is questionable anyway due to the two separate words without any separator. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub backport label proposal
Looks like a clever little bot. In case that is the way the community choose to
go then the label will have to be “backport releasebranch_8_2”, which is very
long…
I also wonder how useful it would be at the moment for GRASS, e.g. wide ranging
indentation changes often causes conflicts between main and latest release
branches.
> On 22 Nov 2022, at 18:52, Even Rouault wrote:
>
> For the backport bot
> (https://github.com/OSGeo/gdal/blob/master/.github/workflows/backport.yml) to
> work, I believe the label must be exactly "backport {git_branch_name}"
>
> Le 22/11/2022 à 18:47, Nicklas Larsson via grass-dev a écrit :
>> I think this is a splendid idea!
>>
>> Would be good to keep the label as short as possible, perhaps:
>> - "backport 8.0"
>> - "backport 8.2”
>> ?
>>
>> At any rate, I have no strong opinion regarding the form, I fully support
>> the general idea.
>>
>> Best, Nicklas
>>
>>
>>> On 22 Nov 2022, at 12:00, Markus Neteler wrote:
>>>
>>> Hi devs,
>>>
>>> Our generic "backport" label seems to be mildly confusing (backport to
>>> which branch?).
>>>
>>> My suggestion is to adopt the approach of GDAL:
>>>
>>> - backport release 7.8
>>> - backport release 8.2
>>> ...
>>>
>>> Like this also multiple labels could be set.
>>>
>>> Opinions?
>>>
>>> cheers,
>>> Markus
>>>
>>> --
>>> Markus Neteler, PhD
>>> https://www.mundialis.de - free data with free software
>>> https://grass.osgeo.org
>>> https://courses.neteler.org/blog
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub backport label proposal
For the backport bot
(https://github.com/OSGeo/gdal/blob/master/.github/workflows/backport.yml)
to work, I believe the label must be exactly "backport {git_branch_name}"
Le 22/11/2022 à 18:47, Nicklas Larsson via grass-dev a écrit :
I think this is a splendid idea!
Would be good to keep the label as short as possible, perhaps:
- "backport 8.0"
- "backport 8.2”
?
At any rate, I have no strong opinion regarding the form, I fully support the
general idea.
Best, Nicklas
On 22 Nov 2022, at 12:00, Markus Neteler wrote:
Hi devs,
Our generic "backport" label seems to be mildly confusing (backport to
which branch?).
My suggestion is to adopt the approach of GDAL:
- backport release 7.8
- backport release 8.2
...
Like this also multiple labels could be set.
Opinions?
cheers,
Markus
--
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub backport label proposal
I think this is a splendid idea! Would be good to keep the label as short as possible, perhaps: - "backport 8.0" - "backport 8.2” ? At any rate, I have no strong opinion regarding the form, I fully support the general idea. Best, Nicklas > On 22 Nov 2022, at 12:00, Markus Neteler wrote: > > Hi devs, > > Our generic "backport" label seems to be mildly confusing (backport to > which branch?). > > My suggestion is to adopt the approach of GDAL: > > - backport release 7.8 > - backport release 8.2 > ... > > Like this also multiple labels could be set. > > Opinions? > > cheers, > Markus > > -- > Markus Neteler, PhD > https://www.mundialis.de - free data with free software > https://grass.osgeo.org > https://courses.neteler.org/blog > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub backport label proposal
Hi Markus, For the MapServer project, I enabled the following names, which seems to make sense, as it references the actual branch name (as in 'branch-8-0') in the label name, such as: backport branch-6-4 backport branch-7-4 backport branch-7-6 backport branch-8-0 This seems to work very well (no questions from the various devs). -jeff On 2022-11-22 7:00 a.m., Markus Neteler wrote: Hi devs, Our generic "backport" label seems to be mildly confusing (backport to which branch?). My suggestion is to adopt the approach of GDAL: - backport release 7.8 - backport release 8.2 ... Like this also multiple labels could be set. Opinions? cheers, Markus -- Jeff McKenna GatewayGeo: Developers of MS4W, MapServer Consulting and Training co-founder of FOSS4G http://gatewaygeo.com/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub backport label proposal
út 22. 11. 2022 v 14:24 odesílatel Markus Neteler napsal: > Our generic "backport" label seems to be mildly confusing (backport to > which branch?). > > My suggestion is to adopt the approach of GDAL: > > - backport release 7.8 > - backport release 8.2 > ... I like that. But maybe keeping just the last versions? E.g., once the current version of GRASS will be 8.7, it probably does not make sense to keep the label backport_release_8.2, right? (just to avoid having 50 labels just for backporting) ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GitHub backport label proposal
Hi devs, Our generic "backport" label seems to be mildly confusing (backport to which branch?). My suggestion is to adopt the approach of GDAL: - backport release 7.8 - backport release 8.2 ... Like this also multiple labels could be set. Opinions? cheers, Markus -- Markus Neteler, PhD https://www.mundialis.de - free data with free software https://grass.osgeo.org https://courses.neteler.org/blog ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Mini project 2023: Improving Single-Window GUI user experience
Hi GRASS community, I'm sending a link to the new mini-project that will be focused on some important improvements to Single-Window GUI: https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/ImprovingSingleWindowUX (https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/ImprovingSingleWindowUX) Some of the topics are based on your own ideas, some have come up from usability testing using an eye-tracking device which we conducted this year at Czech Technical University. The project is going to focus mainly on the redesign of the Console pane and on the implementation of the ability to undock and dock a map window which is needed for those of you who would like to still use GRASS as a Multi- Window in the future. If you would like to get involved and share your ideas and comments about the Console pane reorganization, you are welcome to write your ideas/comments here https://github.com/OSGeo/grass/issues (https://github.com/OSGeo/grass/issues/2585)/2585 (https://github.com/OSGeo/grass/issues/2585). I plan to set up a new PR for this topic soon. Additionally, the project plans to address the topic of saving Single-Window GUI layouts into workspaces. This functionality is the first step for managing user-defined layouts in GRASS. Please, if you have any questions, do not hesitate to ask. :-) Have you all a nice week, Linda ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
