Hi Luigi,
On Wed, 06. Sep 2017 at 22:26:41 +0200, Luigi Pirelli wrote:
> FYI in QGIS dev world we still not have found a clear and complete way
> to migrate tracker from redmine to GH or GitLab.
That's implies that we want to switch bugtracking to github. There never was
consensus about that and
>> I was thinking trac/git integration might be another possibility
>> though it sounds from this page, the performance might not be there yet.
> FYI: Trac can already be integrated with GIT.
> You can see it in action with GEOS:
> https://trac.osgeo.org/geos/browser/git
> The repo being bro
On Mon, Sep 25, 2017 at 04:56:02AM -0400, Regina Obe wrote:
> Sandro already did a proof of concept with GEOS though he didn't officially
> move the tickets off of trac.
This was the result of last "import" from trac, if you're curious:
https://git.osgeo.org/gogs/strk/geos-migration-test/issues
(
On Mon, Sep 25, 2017 at 03:55:43PM +0200, Sandro Santilli wrote:
> On Mon, Sep 25, 2017 at 02:10:46PM +0200, Even Rouault wrote:
> > As far as I can see, only GEOS has
> > migrated to https://git.osgeo.org/gogs
>
> Librttopo has its official home there too:
> https://git.osgeo.org/gogs/rttopo/li
On Mon, Sep 25, 2017 at 02:10:46PM +0200, Even Rouault wrote:
> Hi Sandro,
>
> Thanks for your feedback.
>
> > It is still Gogs.
> > The plan is to switch to Gitea (http://gitea.io)
>
> There's some irony that gitea.io points to github.com for their own code. Not
> particularly
> reassuring re
Hi Sandro,
Thanks for your feedback.
> It is still Gogs.
> The plan is to switch to Gitea (http://gitea.io)
There's some irony that gitea.io points to github.com for their own code. Not
particularly
reassuring regarding the maturity of the solution.
>
> > gogs/gitea tries to replicate most g
> 1) migrate to git, and remain within the OSGeo infrastructure. This is for
example the case of
> GEOS which uses the Trac git plugin and the GOGS (or is gitea?) git
hosting (https://
> git.osgeo.org/gogs/geos/geos.git). gogs/gitea tries to replicate most
github functionalities,
> but feature pa
On Wed, Sep 06, 2017 at 03:14:26PM +0200, Even Rouault wrote:
> 1) migrate to git, and remain within the OSGeo infrastructure. This is for
> example the case of
> GEOS which uses the Trac git plugin and the GOGS (or is gitea?) git hosting
> (https://
> git.osgeo.org/gogs/geos/geos.git).
It is
Whatever option we go with, I agree that it is important to maintain the
full history of code and tickets. In addition to the "svn blame" example
that Even gave, being able to track the provenance of each line of code
is also good practice for legal reasons.
Daniel
On 2017-09-06 2:40 PM, Eve
On 9 September 2017 at 17:27, Even Rouault wrote:
> On samedi 9 septembre 2017 07:29:23 CEST Kurt Schwehr wrote:
>
>> I have a bunch of svn based scripts that I use daily, but I would be
>> happily trash my current work flow for github.
>> I would prefer option 3, but option 2 would be okay too.
>
On samedi 9 septembre 2017 07:29:23 CEST Kurt Schwehr wrote:
> I have a bunch of svn based scripts that I use daily, but I would be
> happily trash my current work flow for github.
>
> I would prefer option 3, but option 2 would be okay too.
>
> I think that the utility of github pull requests is
I have a bunch of svn based scripts that I use daily, but I would be
happily trash my current work flow for github.
I would prefer option 3, but option 2 would be okay too.
I think that the utility of github pull requests is just too valuable to go
with option 1.
I really need to rewatch the cla
FYI in QGIS dev world we still not have found a clear and complete way
to migrate tracker from redmine to GH or GitLab.
More info and details can be asked to the key people that investigated
the problem... just asking in Dev list.
FYI we are still in a new updated redmine :/
Luigi Pirelli
***
I would also prefer to go for #3 if possible, though I don't have enough
experience how to make it happen.
Best regards,
Tamas
2017-09-06 15:14 GMT+02:00 Even Rouault :
> Hi,
>
>
>
> I've heard a few voices speaking/asking/begging for a git/github
> migration. At some point we'll certainly hav
On mercredi 6 septembre 2017 21:16:46 CEST Dmitry Baryshnikov wrote:
> Hi Even,
>
> I think this is great proposal. Github is modern tool for develop, code
> review and test software.
>
> I like idea to migrate code and tickets (3). Not sure we need to migrate
> closed tickets.
I'd wish closed t
On 6 September 2017 at 15:14, Even Rouault wrote:
> Hi,
>
> I've heard a few voices speaking/asking/begging for a git/github migration.
> At some point we'll certainly have to do it, as SVN vs git is beginning to
> feel more and more like CVS vs SVN 15 years ago.
>
> I can see different options :
Hi Even,
I think this is great proposal. Github is modern tool for develop, code
review and test software.
I like idea to migrate code and tickets (3). Not sure we need to migrate
closed tickets. Also it worth thinking to migrate only the 2.x code
tree. There are not so many releases in 2.x,
Hi,
I've heard a few voices speaking/asking/begging for a git/github migration. At
some point
we'll certainly have to do it, as SVN vs git is beginning to feel more and more
like CVS vs SVN
15 years ago.
I can see different options :
1) migrate to git, and remain within the OSGeo infrastruct
18 matches
Mail list logo
