[RFC] gitlab migration plan

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[RFC] gitlab migration plan

Bryce Harrington-3
Thank you everyone for considering the options and rasing good points
and concerns, including:

  * Gaining contributors is a motivation here

  * Performance might be problematic with gitlab

  * FOSS options fit Inkscape values, and we should prefer to support
    FOSS projects, but not if it inhibits us too badly

  * Other choices do exist besides just github vs. gitlab

A lot of people are voicing preference for gitlab, perhaps a majority,
but we're certainly not at a full consensus.  I sense that we need some
actual experience under our belts, and we should plan to reassess our
decision as we get into it.

Performance is, at least, something we can test.  If gitlab has severe
performance issues, then that should be obvious and likely measurable if
we just try it.

Github certainly would give us more visibility, however there's no
guarantee this would translate into more contributors.  Will Entriken
made a good point that being on github would enable more drive-by
contributions based on general experience in various small/medium
projects, however Mc makes a strong counter-argument that what we are
really after are dedicated contributors, and with Inkscape already
having a fairly widespread profile those folks will find us just fine
regardless of the popularity of the hosting platform.  Perhaps a
separate outreach effort to recruit contributors after the git migration
has been done would be more likely to generate good results?


So given the above, I'd like to propose a migration to githab but with
several checkpoints, according to the following plan:

1.  Migrate inkscape_web.

    + Keep a particular eye on performance.
    + Evaluate code review UX
    + Evaluate CI
    + Experiment with other features

2,  Once 0.92.1 is released, we'll have a first checkpoint
    Checkpoint for inkscape_web.

    + Make recommendations for utilization of code review, CI, and other
      gitlab functionality.
    + Was performance a hinderance?  Is the
      user experience acceptable?  In general do the inkscape_web
      participants still feel as supportive of gitlab?
    + What concerns or issues remain, that should be watched during our
      initial migration?
    + We'll ask everyone involved in inkscape_web for a thumb's up or
      down.  If there are thumb's down, we'll halt and re-evaluate.

3.  Migrate inkscape to gitlab.

    + All bzr committers are eligible for gitlab commit access,
      but will need to place a request for access
    + At least one dry run should be done, to ensure that revision
      history, branches, tags, etc. are successfully converted.
    + Issues encountered with gitlab will be recorded, either in a
      dedicated bug tracker or just a simple 'complaints' web page.
    + Transition of wiki pages can start as desired
      (see separate plan proposal).
    + Bugs stay on LP for now

4.  Outreach effort to bring in contributors

    + Leverage our release marketing procedures and contacts
    + Coordinate with GSoC, releases, hackfests
    + Ensure we have reviewers/mentors on hand

5.  Following the 0.93.0 release is a second checkpoint.

    + Review the recorded issues encountered.  Collect further
      feedback.
    + How has use of gitlab affected contribution levels to the Inkscape
      codebase?  If contribution levels have not grown then we need to
      reassess.
    + All active users of the service are asked to give thumbs up/down
      on their experience using gitlab.  If most everyone gives thumb's
      up, we will proceed and stick with gitlab at least until 1.0.0.
      Otherwise, we need to re-evaluate our plans.
    + Plan follow-on work to investigate/address top issues.

6.  Following the 1.0.0 release, we have another reassessment of all
    project technologies and services.  cmake, git, gitlab, C++11, gtk3,
    and so on.  We should then plan transitions from those to whatever
    is next, over the course of several 1.x releases.

If you've read this far - thanks!  Feedback is most appreciated.

Bryce

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] gitlab migration plan

Marc Jeanmougin
On 01/17/2017 08:51 AM, Bryce Harrington wrote:

> 3.  Migrate inkscape to gitlab.
>
>     [...]

Just as a remark, there will be bugs linked to the transition from bzr
to git itself: some build parts are linked to "bzr revno" for instance,
so some cmake code will have to be fixed just after the code migration,
and we'll also have to decide what to put in the about screen instead of
the revno. Probably the best option might be the git commit hash and/or
datetime if it's easily extractable from git.

"Inkscape 0.92+devel (2017-01-18 17:38:31)" might be more readable than
"Inkscape 0.92+devel f0e47570d3776c373066cc61595b1ba14fa9b366"

--
Marc

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] gitlab migration plan

Bryce Harrington-3
On Wed, Jan 18, 2017 at 05:42:19PM +0100, Marc Jeanmougin wrote:

> On 01/17/2017 08:51 AM, Bryce Harrington wrote:
>
> > 3.  Migrate inkscape to gitlab.
> >
> >     [...]
>
> Just as a remark, there will be bugs linked to the transition from bzr
> to git itself: some build parts are linked to "bzr revno" for instance,
> so some cmake code will have to be fixed just after the code migration,
> and we'll also have to decide what to put in the about screen instead of
> the revno. Probably the best option might be the git commit hash and/or
> datetime if it's easily extractable from git.
>
> "Inkscape 0.92+devel (2017-01-18 17:38:31)" might be more readable than
> "Inkscape 0.92+devel f0e47570d3776c373066cc61595b1ba14fa9b366"

Another option might be:

"Inkscape 0.92+devel (2017-01-18 f0e47570)"

The first 8 chars of the SHA are usually always adequate to uniquely
identify the commit, and will be more manageable than the full SHA in
this case.

I do think showing the (partial) SHA is what we want, as the purpose of
showing the revno is to assist in identifying where a regression
occurred, and since a number of git commands work with SHAs so listing
it here will eliminate an extra step that bug triagers would need to do
anyway.

Showing the date is handy too since it'll communicate to users the
relative age of the build (which SHA's don't communicate in the way that
bzr's revno's do.)  We have a few different options for what date to
show:  The commit date of the patch, the author date of the patch, and
the build date.  Guessing the commit date would be most logical here but
I'm not actually sure.

Mc, could you start collecting issues like these?  Maybe file bugs in LP
and tag them 'gitlab-migration' or something so we can find them.  I
think they should be pretty straightforward to rig up in git, and I'll
make sure we get them addressed as we migrate.

Bryce

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] gitlab migration plan

Tobias Ellinghaus
Am Mittwoch, 18. Januar 2017, 09:35:31 CET schrieb Bryce Harrington:

> On Wed, Jan 18, 2017 at 05:42:19PM +0100, Marc Jeanmougin wrote:
> > On 01/17/2017 08:51 AM, Bryce Harrington wrote:
> > > 3.  Migrate inkscape to gitlab.
> > >
> > >     [...]
> >
> > Just as a remark, there will be bugs linked to the transition from bzr
> > to git itself: some build parts are linked to "bzr revno" for instance,
> > so some cmake code will have to be fixed just after the code migration,
> > and we'll also have to decide what to put in the about screen instead of
> > the revno. Probably the best option might be the git commit hash and/or
> > datetime if it's easily extractable from git.
> >
> > "Inkscape 0.92+devel (2017-01-18 17:38:31)" might be more readable than
> > "Inkscape 0.92+devel f0e47570d3776c373066cc61595b1ba14fa9b366"
>
> Another option might be:
>
> "Inkscape 0.92+devel (2017-01-18 f0e47570)"
>
> The first 8 chars of the SHA are usually always adequate to uniquely
> identify the commit, and will be more manageable than the full SHA in
> this case.
>
> I do think showing the (partial) SHA is what we want, as the purpose of
> showing the revno is to assist in identifying where a regression
> occurred, and since a number of git commands work with SHAs so listing
> it here will eliminate an extra step that bug triagers would need to do
> anyway.
Ack. A nice way of getting such a version string is

git describe --tags --dirty

which will tell the last tag, whether there are changes to the checkout (the
--dirty), the short hash of the last commit and also the number of commits
since the tag. For darktable that looks like this:

release-2.3.0-266-gfefb0204e-dirty

It's not too hard to clean up the tag name (remove "release-") and add the
commit date.

> Showing the date is handy too since it'll communicate to users the
> relative age of the build (which SHA's don't communicate in the way that
> bzr's revno's do.)  We have a few different options for what date to
> show:  The commit date of the patch, the author date of the patch, and
> the build date.  Guessing the commit date would be most logical here but
> I'm not actually sure.

I'd also use the commit date. Author date can be arbitrarily far in the past.

[...]

> Bryce

Tobias
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] gitlab migration plan

Krzysztof Kosiński
Regarding gitlab, there's a developing story today:

https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/

Basically, they did not bother to validate restoring from backups,
which does not inspire confidence...

2017-01-18 10:08 GMT-08:00 Tobias Ellinghaus <[hidden email]>:

> Am Mittwoch, 18. Januar 2017, 09:35:31 CET schrieb Bryce Harrington:
>> On Wed, Jan 18, 2017 at 05:42:19PM +0100, Marc Jeanmougin wrote:
>> > On 01/17/2017 08:51 AM, Bryce Harrington wrote:
>> > > 3.  Migrate inkscape to gitlab.
>> > >
>> > >     [...]
>> >
>> > Just as a remark, there will be bugs linked to the transition from bzr
>> > to git itself: some build parts are linked to "bzr revno" for instance,
>> > so some cmake code will have to be fixed just after the code migration,
>> > and we'll also have to decide what to put in the about screen instead of
>> > the revno. Probably the best option might be the git commit hash and/or
>> > datetime if it's easily extractable from git.
>> >
>> > "Inkscape 0.92+devel (2017-01-18 17:38:31)" might be more readable than
>> > "Inkscape 0.92+devel f0e47570d3776c373066cc61595b1ba14fa9b366"
>>
>> Another option might be:
>>
>> "Inkscape 0.92+devel (2017-01-18 f0e47570)"
>>
>> The first 8 chars of the SHA are usually always adequate to uniquely
>> identify the commit, and will be more manageable than the full SHA in
>> this case.
>>
>> I do think showing the (partial) SHA is what we want, as the purpose of
>> showing the revno is to assist in identifying where a regression
>> occurred, and since a number of git commands work with SHAs so listing
>> it here will eliminate an extra step that bug triagers would need to do
>> anyway.
>
> Ack. A nice way of getting such a version string is
>
> git describe --tags --dirty
>
> which will tell the last tag, whether there are changes to the checkout (the
> --dirty), the short hash of the last commit and also the number of commits
> since the tag. For darktable that looks like this:
>
> release-2.3.0-266-gfefb0204e-dirty
>
> It's not too hard to clean up the tag name (remove "release-") and add the
> commit date.
>
>> Showing the date is handy too since it'll communicate to users the
>> relative age of the build (which SHA's don't communicate in the way that
>> bzr's revno's do.)  We have a few different options for what date to
>> show:  The commit date of the patch, the author date of the patch, and
>> the build date.  Guessing the commit date would be most logical here but
>> I'm not actually sure.
>
> I'd also use the commit date. Author date can be arbitrarily far in the past.
>
> [...]
>
>> Bryce
>
> Tobias
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] gitlab migration plan

Martin Owens-2
I was following it closely since I have a number of code repositories
there.

Someone basically hacked their system (hacked in the sense they used
GitLab for hosting live streams instead of for code, not hacked as in
broke into their computers)

So the admins took action and that action included deleting the whole
database by accident. Then they had failure after failure getting the
database backups in place.

I expect they'll be spending a few months with a sore forehead sorting
the issues out. But I'm going to monitor the situation.

It was good seeing the transparency, even a livestream of the computer
doing the database restore.

Best Regards, Martin Owens

On Wed, 2017-02-01 at 13:51 -0800, Krzysztof Kosiński wrote:
> Regarding gitlab, there's a developing story today:
>
> https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/
>
> Basically, they did not bother to validate restoring from backups,
> which does not inspire confidence...

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] gitlab migration plan

Krzysztof Kosiński
In reply to this post by Bryce Harrington-3
2017-01-16 23:51 GMT-08:00 Bryce Harrington <[hidden email]>:

> 3.  Migrate inkscape to gitlab.
>
>     + All bzr committers are eligible for gitlab commit access,
>       but will need to place a request for access
>     + At least one dry run should be done, to ensure that revision
>       history, branches, tags, etc. are successfully converted.
>     + Issues encountered with gitlab will be recorded, either in a
>       dedicated bug tracker or just a simple 'complaints' web page.
>     + Transition of wiki pages can start as desired
>       (see separate plan proposal).
>     + Bugs stay on LP for now

Note: I have a script that fixes up several discrepant author names
and e-mails in the Bazaar history. The result of this script is here:
https://github.com/tweenk/inkscape/
The script has a bunch of e-mail addresses in it, so it would probably
be best to share it privately.

> 4.  Outreach effort to bring in contributors
>
>     + Leverage our release marketing procedures and contacts
>     + Coordinate with GSoC, releases, hackfests
>     + Ensure we have reviewers/mentors on hand
>
> 5.  Following the 0.93.0 release is a second checkpoint.
>
>     + Review the recorded issues encountered.  Collect further
>       feedback.
>     + How has use of gitlab affected contribution levels to the Inkscape
>       codebase?  If contribution levels have not grown then we need to
>       reassess.
>     + All active users of the service are asked to give thumbs up/down
>       on their experience using gitlab.  If most everyone gives thumb's
>       up, we will proceed and stick with gitlab at least until 1.0.0.
>       Otherwise, we need to re-evaluate our plans.
>     + Plan follow-on work to investigate/address top issues.
>
> 6.  Following the 1.0.0 release, we have another reassessment of all
>     project technologies and services.  cmake, git, gitlab, C++11, gtk3,
>     and so on.  We should then plan transitions from those to whatever
>     is next, over the course of several 1.x releases.
>
> If you've read this far - thanks!  Feedback is most appreciated.
>
> Bryce
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] gitlab migration plan

Martin Owens-2
On Wed, 2017-02-01 at 14:28 -0800, Krzysztof Kosiński wrote:
> The script has a bunch of e-mail addresses in it, so it would
> probably be best to share it privately.

We have a private keys repository if you'd like to use that. Or you can
email the board members an email privately.

Thanks KK

Martin,

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] gitlab migration plan

Bryce Harrington-3
On Wed, Feb 01, 2017 at 07:12:57PM -0500, Martin Owens wrote:
> On Wed, 2017-02-01 at 14:28 -0800, Krzysztof Kosiński wrote:
> > The script has a bunch of e-mail addresses in it, so it would
> > probably be best to share it privately.
>
> We have a private keys repository if you'd like to use that. Or you can
> email the board members an email privately.

+1

Also, as a side remark, I've been tinkering with git-crypt (in relation
to needs of the X.org project).  If we have data like that which needs
to be shared but kept private that may be another option to consider,
once we convert to git.

Bryce

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] gitlab migration plan

Tobias Ellinghaus
Am Mittwoch, 1. Februar 2017, 23:50:14 CET schrieb Bryce Harrington:

> On Wed, Feb 01, 2017 at 07:12:57PM -0500, Martin Owens wrote:
> > On Wed, 2017-02-01 at 14:28 -0800, Krzysztof Kosiński wrote:
> > > The script has a bunch of e-mail addresses in it, so it would
> > > probably be best to share it privately.
> >
> > We have a private keys repository if you'd like to use that. Or you can
> > email the board members an email privately.
>
> +1
>
> Also, as a side remark, I've been tinkering with git-crypt (in relation
> to needs of the X.org project).  If we have data like that which needs
> to be shared but kept private that may be another option to consider,
> once we convert to git.
You are aware that the commits themselves are public and that all those email
addresses that are used so far are therefore public, too? Just saying.

Apart from that, I still don't understand why anyone would change the mail
addresses from old commits. It's part of the history.

> Bryce

Tobias
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Loading...