based on decision made by PSC [1], the GRASS GIS source code will be
moved from SVN hosted by OSGeo to Git hosted by GitHub.com. More
details at [2].
It's also planned to move open issues from trac to GitHub issue
system. In this regard I would like to ask you for ASSISTANCE. All
tickets with milestone 7.0 [3], 7.2 [4] should be reviewed and either
to be closed or milestone changed to 7.4 (or 7.6/7.8/8.0). Only
tickets with milestone 7.4+ will be migrated. We are assuming that 7.0
and 7.2 reached EOL. Our goal: to have open tickets only with
milestone 7.4.5+.
When this part will be done the migration can start, see draft [5].
In this regard I would like to ask you for ASSISTANCE. All
tickets with milestone 7.0 [3], 7.2 [4] should be reviewed and either
to be closed or milestone changed to 7.4 (or 7.6/7.8/8.0).
do we have some date until when tickets should be reviewed?
po 6. 5. 2019 v 12:10 odesílatel Helmut Kudrnovsky <hellik@web.de> napsal:
> In this regard I would like to ask you for ASSISTANCE. All
>tickets with milestone 7.0 [3], 7.2 [4] should be reviewed and either
>to be closed or milestone changed to 7.4 (or 7.6/7.8/8.0).
do we have some date until when tickets should be reviewed?
ASAP, we would like to finish migration in reasonable time. Ma
On Mon, May 6, 2019 at 11:41 AM Martin Landa <landa.martin@gmail.com> wrote:
Dear all,
based on decision made by PSC [1], the GRASS GIS source code will be
moved from SVN hosted by OSGeo to Git hosted by GitHub.com. More
details at [2].
[...migration of tickets ...]
When this part will be done the migration can start, see draft [5].
Why wait for that with the source code migration?
Please let's start with it. The tickets can follow in a second step.
This also prevents us from being overloaded.
based on decision made by PSC [1], the GRASS GIS source code will be
moved from SVN hosted by OSGeo to Git hosted by GitHub.com. More
details at [2].
[…migration of tickets …]
When this part will be done the migration can start, see draft [5].
Why wait for that with the source code migration?
Please let’s start with it. The tickets can follow in a second step.
+1!
Say, if source code migration starts tomorrow, how long it would take? Then set that day (+2 or 3 if you want) as deadline for tickets revision, then migrate tickets, done
po 6. 5. 2019 v 22:49 odesílatel Markus Neteler <neteler@osgeo.org> napsal:
Why wait for that with the source code migration?
Please let's start with it. The tickets can follow in a second step.
This also prevents us from being overloaded.
my idea to do migration in one step comes from assumption that new git
commits can be referenced to github issues. Issue migration needs to
be also done on private repository. This would require to set up empty
private repo, migrate tickets and than transfer ticket using GitHub
API to public repo. This complicates procedure a bit. I would still
prefer to do source code and issues migration together even it will
take some time.
po 6. 5. 2019 v 23:06 odesílatel Veronica Andreo <veroandreo@gmail.com> napsal:
Say, if source code migration starts tomorrow, how long it would take? Then set that day (+2 or 3 if you want) as deadline for tickets revision, then migrate tickets, done
source code migration will take a few hours. See my notes in previous mail. Ma
Say, if source code migration starts tomorrow, how long it would take? Then set that day (+2 or 3 if you want) as deadline for tickets revision, then migrate tickets, done
source code migration will take a few hours. See my notes in previous mail.
I’d suggest then to set a deadline for ticket review by reporters, eg: this Sunday (or any other date before the planned code sprint in Berlin)
El mar., 7 may. 2019 a las 16:20, Veronica Andreo (<
veroandreo@
>)
escribió:
El mar., 7 may. 2019 a las 11:54, Martin Landa (<
landa.martin@
>)
escribió:
Hi,
út 7. 5. 2019 v 11:14 odesílatel Veronica Andreo <
veroandreo@
>
napsal:
> I'd suggest then to set a deadline for ticket review by reporters, eg:
this Sunday (or any other date before the planned code sprint in Berlin)
could work. Till Sunday I will have also time to test issue migration
a bit more. Then migration could happen in beginning of next week
(Mon/Tue).
Any other opinion/objection? Shall I post on FB and Twitter then? New
announcement here with deadline?
Vero
+1!
Vero
_______________________________________________
grass-dev mailing list
See Martin’s original mail and links. The tickets that need to be reviewed are those with milestone 7.0.7 and 7.2.4, as to know if they are still valid and milestone should be moved to 7.6.2
Tickets with milestone 7.8 will be migrated anyway…
See Martin's original mail and links. The tickets that need to be >reviewed
are those with milestone 7.0.7 and 7.2.4, as to know if >they are still
valid and milestone should be moved to 7.6.2
IMHO when I go through the tickets for 7.0.7 and 7.2.4, an additional check
with trunk (Python 3) could be done at the same time and may save resources
later on to decide if a fix should go to 7.6 /7.8 or maybe only to 7.8 cause
of a different code base (py2 vs py3) and/or focus on 7.8 only
so far I couldn't find a solution for the winGRASS trunk regression
út 7. 5. 2019 v 10:26 odesílatel Martin Landa <landa.martin@gmail.com> napsal:
commits can be referenced to github issues. Issue migration needs to
be also done on private repository. This would require to set up empty
private repo, migrate tickets and than transfer ticket using GitHub
API to public repo. This complicates procedure a bit. I would still
prefer to do source code and issues migration together even it will
take some time.
back to this topic, I added to trac an alternative scenario based on
two steps (source code and issues migration separated) [1]. Opinions
welcome. We are very close to day D.
On Fri, May 10, 2019 at 4:03 PM Helmut Kudrnovsky <hellik@web.de> wrote:
Markus Neteler wrote
> On Fri, May 10, 2019 at 1:12 PM Helmut Kudrnovsky <
>> so far I couldn't find a solution for the winGRASS trunk regression
>
> The only way I see is to revert the change and see if it works again.
> If yes, break this big commit into chunks and try further.
as there were many encoding related commits in the last time, anyone any
idea where to start?
On Fri, May 10, 2019 at 5:06 PM Martin Landa <landa.martin@gmail.com> wrote:
Hi,
út 7. 5. 2019 v 10:26 odesílatel Martin Landa <landa.martin@gmail.com> napsal:
> commits can be referenced to github issues. Issue migration needs to
> be also done on private repository. This would require to set up empty
> private repo, migrate tickets and than transfer ticket using GitHub
> API to public repo. This complicates procedure a bit. I would still
> prefer to do source code and issues migration together even it will
> take some time.
back to this topic, I added to trac an alternative scenario based on
two steps (source code and issues migration separated) [1]. Opinions
welcome. We are very close to day D.
Excellent.
IMHO the separate migration of source code and issues is the way to go.
Like that we can already work with the then completed migration next
weekend in Berlin and define workflows.
On Fri, May 10, 2019 at 5:06 PM Martin Landa <landa.martin@gmail.com> wrote:
Hi,
út 7. 5. 2019 v 10:26 odesílatel Martin Landa <landa.martin@gmail.com> napsal:
commits can be referenced to github issues. Issue migration needs to
be also done on private repository. This would require to set up empty
private repo, migrate tickets and than transfer ticket using GitHub
API to public repo. This complicates procedure a bit. I would still
prefer to do source code and issues migration together even it will
take some time.
back to this topic, I added to trac an alternative scenario based on
two steps (source code and issues migration separated) [1]. Opinions
welcome. We are very close to day D.
Excellent.
IMHO the separate migration of source code and issues is the way to go.
Like that we can already work with the then completed migration next
weekend in Berlin and define workflows.
+1
I think we just need to get the ball rolling. There will certainly be some transition pain, but if we try to prepare everything to perfection it will never happen
