gitlab migration plan

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

gitlab migration plan

Bryce Harrington-3
Thanks everyone who provided feedback on the plan to migrate to gitlab.
I've updated the plan to incorporate all the feedback (see attached diff
for what changed).  With 0.92.1 now out the door, this seems like an
opportune time to proceed with Step 2 of the migration, if no one
objects?

So, Martin, Maren, jazzynico, and others who have been maintaining
inkscape-related products on gitlab, would you mind sharing your
experiences with gitlab, and whether you recommend for or against
migrating inkscape itself at this time?

Bryce

------------------------------------------------------------------------

[DONE] 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?
    + Retrospective on the 2/1/2017 hack + loss of backups
      - https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/
      - Issue itself is bad.  Transparency they showed is good.
      - It's been a month, have they adequately sorted things out?
    + Is gitlab's CI build system up to the task for Inkscape?  What
      provisions will we need to make (e.g. supplying our own build
      hosts)
    + 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
    + tweenk has a script to fix up discrepant author names and
      e-mails.  Can't be shared publically since has personal info (but
      could be passed to a board member via pgp encrypt).
    + At least one dry run should be done, to ensure that revision
      history, branches, tags, etc. are successfully converted.
    + Functionality that uses 'bzr revno' (like the about screen) will
      need modified to use git.
      - Formatting for about screen should be something resembling:
      "Inkscape 0.92+devel (2017-01-18 f0e47570)"
      - git describe --tags --dirty
      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.  It's not too hard to
        clean up the tag name (remove "release-") and add the commit
        date.
      - Use the commit date rather than the author date
    + Issues encountered with gitlab will be recorded in our bug tracker
      with the 'gitlab-migration' tag.
    + 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

    + Assemble an outreach/advocacy team
    + 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.


------------------------------------------------------------------------------
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: gitlab migration plan

Bryce Harrington-3
On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
> Thanks everyone who provided feedback on the plan to migrate to gitlab.
> I've updated the plan to incorporate all the feedback (see attached diff
> for what changed).

diff is attached now...

> With 0.92.1 now out the door, this seems like an
> opportune time to proceed with Step 2 of the migration, if no one
> objects?
>
> So, Martin, Maren, jazzynico, and others who have been maintaining
> inkscape-related products on gitlab, would you mind sharing your
> experiences with gitlab, and whether you recommend for or against
> migrating inkscape itself at this time?
>
> Bryce
>
> ------------------------------------------------------------------------
>
> [DONE] 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?
>     + Retrospective on the 2/1/2017 hack + loss of backups
>       - https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/
>       - Issue itself is bad.  Transparency they showed is good.
>       - It's been a month, have they adequately sorted things out?
>     + Is gitlab's CI build system up to the task for Inkscape?  What
>       provisions will we need to make (e.g. supplying our own build
>       hosts)
>     + 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
>     + tweenk has a script to fix up discrepant author names and
>       e-mails.  Can't be shared publically since has personal info (but
>       could be passed to a board member via pgp encrypt).
>     + At least one dry run should be done, to ensure that revision
>       history, branches, tags, etc. are successfully converted.
>     + Functionality that uses 'bzr revno' (like the about screen) will
>       need modified to use git.
>       - Formatting for about screen should be something resembling:
>       "Inkscape 0.92+devel (2017-01-18 f0e47570)"
>       - git describe --tags --dirty
>       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.  It's not too hard to
>         clean up the tag name (remove "release-") and add the commit
>         date.
>       - Use the commit date rather than the author date
>     + Issues encountered with gitlab will be recorded in our bug tracker
>       with the 'gitlab-migration' tag.
>     + 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
>
>     + Assemble an outreach/advocacy team
>     + 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.
>
>
> ------------------------------------------------------------------------------
> 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

migration_plan_v2.diff (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gitlab migration plan

Martin Owens-2
In reply to this post by Bryce Harrington-3
On Tue, 2017-02-28 at 19:12 -0800, Bryce Harrington wrote:
>
> So, Martin, Maren, jazzynico, and others who have been maintaining
> inkscape-related products on gitlab, would you mind sharing your
> experiences with gitlab, and whether you recommend for or against
> migrating inkscape itself at this time?

So far very happy with GitLab.

The issues tracker is working well for us with custom labels and Maren
has even used the CI builder to test the i18n repository for
correctness.

I've put all my scripting work up here for people to have a look at
lpout (getting things out of launchpad):

https://github.com/doctormo/lpout

It may be something we use to get milestones out, or we might consider
moving the issues tracker at some future point. I think this took (when
tested and finished) will provide the needed functionality for it.

Best Regards, Martin Owens

------------------------------------------------------------------------------
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: gitlab migration plan

maren
In reply to this post by Bryce Harrington-3
Am 01.03.2017 um 22:19 schrieb Bryce Harrington:
> On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
>> Thanks everyone who provided feedback on the plan to migrate to gitlab.
>> I've updated the plan to incorporate all the feedback (see attached diff
>> for what changed).

Thank you, Bryce (and sorry for delay - mail server issues...)

>> 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.

- It just worked as expected. The code review pages are very similar to
github's. To see the code that has changed (in a merge request) you need
to click on a tab at the bottom, and I didn't find it right away, but
it's just a different interface that one would need to get used to.

>>     + Was performance a hinderance?

- No. I know they currently have (or had? development is so fast) an
issue with issue threads that are too long slowing down the browser (and
were working on it), but ours don't pose a problem. The site loads fast
enough, and the command line interactions didn't seem to take longer or
shorter than those with github or launchpad.

>>      Is the
>>       user experience acceptable?  

- For me, it's fine - after Martin added a webhook that sends an email
with a diff on push events. I felt blind without that (but it seems to
be the norm, it's the same on github).

Their permission settings are very fine-grained. That's nice. Issues
work as expected, labels can replace the functionality of the missing
sorting options. Their issue boards (where one can create work lists
from labels) seem to be a nice addition. Comparison between branches is
easily accessible. Branches can be locked, and groups and single people
can be allowed access. There is no such concept as a team, only
projects, and overarching groups with multiple projects inside, and
people with different permissions on them. The online editor worked as
expected.

Martin used the Wiki for drafting a blueprint.

Accessing the code seems to be easy enough for new contributors,
inkscape-web already has a couple of forks, and we've had the same
number of regulars as usual (which is 3 - Sylvain joined us there, too.).

For setting up the 'view' permissions (yes, there are separate
permissions for just looking at different functionality), it was good
that su_v was already a long-time gitlab user and was able to help us
there. The phrasing of some of the options was a bit misleading. The
settings interface is currently being reworked, though. I assume that
setup is a one-time thing, so not a very relevant problem, once you know
what it means.

Setting up the translations repo for inkscape-web was straightforward,
and after permission issues were cleared up (make sure to check for
branch protections), as Martin already said, I even played with their
CI. With my level of knowledge and their documentation, it was easy
enough to set up a script that is run on each commit and checks if po
files compile.

New releases are frequent events (see blog archive for overview:
https://about.gitlab.com/blog/archives.html). Usually, there was no
noticable downtime. Gitlab development appears to be extremely active.

We didn't use milestones, release tags, any of the issue templates, push
rules, rules for merging (like: how many approvals are needed), hosting
of own container images at gitlab, and probably a lot more, but there
exists an unbelievable amount of possibilities.

>> In general do the inkscape_web
>>       participants still feel as supportive of gitlab?

- I do, yes.

>>     + Retrospective on the 2/1/2017 hack + loss of backups
>>       - https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/
>>       - Issue itself is bad.  Transparency they showed is good.
>>       - It's been a month, have they adequately sorted things out?

- It wasn't exactly a hack, more human error, plus nobody checking if
backups worked. Transparency was amazing, and still is (they're now
providing records of their team meetings online). Postmortem is here:
https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/

9 of 14 issues that were connected to the data loss (linked from the
postmortem) are closed now. I can't tell how important the respective
issues are. Some of the open ones didn't get an update within the last
two or three weeks, but work on all of them has been started.

(If I were a twitter user, I'd just have asked them for a general
overview of current backup state, but I'm not, and the issues themselves
are an unsuitable place for this.)


>>     + Is gitlab's CI build system up to the task for Inkscape?  What
>>       provisions will we need to make (e.g. supplying our own build
>>       hosts)

- It seems it's possible to upload one's own docker container images,
but not tested.

>>     + 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.

- Thumbs up from me. No issues with inkscape-web or inkscape-web-i18n on
gitlab.

Maren

>> 3.  Migrate inkscape to gitlab.
>>
>>     + All bzr committers are eligible for gitlab commit access,
>>       but will need to place a request for access
>>     + tweenk has a script to fix up discrepant author names and
>>       e-mails.  Can't be shared publically since has personal info (but
>>       could be passed to a board member via pgp encrypt).
>>     + At least one dry run should be done, to ensure that revision
>>       history, branches, tags, etc. are successfully converted.
>>     + Functionality that uses 'bzr revno' (like the about screen) will
>>       need modified to use git.
>>       - Formatting for about screen should be something resembling:
>>       "Inkscape 0.92+devel (2017-01-18 f0e47570)"
>>       - git describe --tags --dirty
>>       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.  It's not too hard to
>>         clean up the tag name (remove "release-") and add the commit
>>         date.
>>       - Use the commit date rather than the author date
>>     + Issues encountered with gitlab will be recorded in our bug tracker
>>       with the 'gitlab-migration' tag.
>>     + 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
>>
>>     + Assemble an outreach/advocacy team
>>     + 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.
>>
>>
>> ------------------------------------------------------------------------------
>> 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


------------------------------------------------------------------------------
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: gitlab migration plan

Christoffer Holmstedt
2017-03-02 3:12 GMT+01:00 maren <[hidden email]>:
>
> Am 01.03.2017 um 22:19 schrieb Bryce Harrington:
> > On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
> >> Thanks everyone who provided feedback on the plan to migrate to gitlab.
> >> I've updated the plan to incorporate all the feedback (see attached diff
> >> for what changed).
...cut...
> >>      Is the
> >>       user experience acceptable?
>
> - For me, it's fine - after Martin added a webhook that sends an email
> with a diff on push events. I felt blind without that (but it seems to
> be the norm, it's the same on github).
>
...cut...
>
> Maren
>

What do you mean with "push events"? Do you get an email with a diff for each commit to master?

Best regards
--
Christoffer Holmstedt

------------------------------------------------------------------------------
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: gitlab migration plan

Martin Owens-2
On Thu, 2017-03-02 at 19:44 +0100, Christoffer Holmstedt wrote:
> What do you mean with "push events"? Do you get an email with a diff
> for each commit to master?

Each push hits a http address with a json file. I have offered to
provide this in the website so it'll email all people in a given
special group every time there's an event from gitlab.

It's a way to get emails from GitLab for commits.

Best Regards, Martin Owens

------------------------------------------------------------------------------
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: gitlab migration plan

Maren Hachmann
In reply to this post by Christoffer Holmstedt
Am 02.03.2017 um 19:44 schrieb Christoffer Holmstedt:

> 2017-03-02 3:12 GMT+01:00 maren <[hidden email]
> <mailto:[hidden email]>>:
>>
>> Am 01.03.2017 um 22:19 schrieb Bryce Harrington:
>> > On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
>> >> Thanks everyone who provided feedback on the plan to migrate to gitlab.
>> >> I've updated the plan to incorporate all the feedback (see attached
> diff
>> >> for what changed).
> ...cut...
>> >>      Is the
>> >>       user experience acceptable?
>>
>> - For me, it's fine - after Martin added a webhook that sends an email
>> with a diff on push events. I felt blind without that (but it seems to
>> be the norm, it's the same on github).
>>
> ...cut...
>>
>> Maren
>>
>
> What do you mean with "push events"? Do you get an email with a diff for
> each commit to master?
- It's an email with a diff for the commits to any branch inside the
repo per 'git push'.

I don't know if commits that have been pushed together get a diff over
all commits (but I think so - only I don't have any that contain more
than one commit in my mail trash currently).

Email addresses for subscribers (currently) need to be added manually by
someone who has access to the settings.

Screenshot of one of the mails attached (no custom code needed to create
them, it's pre-made, just need to activate the option in the settings at
gitlab).

Regards,
 Maren

> Best regards
> --
> Christoffer Holmstedt
>
>
> ------------------------------------------------------------------------------
> 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

Bildschirmfoto_2017-03-02_20-15-57-fs8.png (28K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gitlab migration plan

Maren Hachmann
In reply to this post by Martin Owens-2
To reduce confusion:

Martin and I are talking about different options.
We're currently using the one I described (gitlab integration, sorry,
used the wrong term), which doesn't allow for people subscribing
themselves, but is ready-made.

The option Martin describes (webhook) would need to be set up on the
inkscape.org server, but would allow people to subscribe and unsubscribe
any time.

Maren

Am 02.03.2017 um 20:12 schrieb Martin Owens:

> On Thu, 2017-03-02 at 19:44 +0100, Christoffer Holmstedt wrote:
>> What do you mean with "push events"? Do you get an email with a diff
>> for each commit to master?
>
> Each push hits a http address with a json file. I have offered to
> provide this in the website so it'll email all people in a given
> special group every time there's an event from gitlab.
>
> It's a way to get emails from GitLab for commits.
>
> Best Regards, Martin Owens
>
> ------------------------------------------------------------------------------
> 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: gitlab migration plan

Tobias Ellinghaus
In reply to this post by Maren Hachmann
Am Donnerstag, 2. März 2017, 20:23:22 CET schrieb Maren Hachmann:

> Am 02.03.2017 um 19:44 schrieb Christoffer Holmstedt:
> > 2017-03-02 3:12 GMT+01:00 maren <[hidden email]
> >
> > <mailto:[hidden email]>>:
> >> Am 01.03.2017 um 22:19 schrieb Bryce Harrington:
> >> > On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
> >> >> Thanks everyone who provided feedback on the plan to migrate to
> >> >> gitlab.
> >> >> I've updated the plan to incorporate all the feedback (see attached
> >
> > diff
> >
> >> >> for what changed).
> >
> > ...cut...
> >
> >> >>      Is the
> >> >>      
> >> >>       user experience acceptable?
> >>
> >> - For me, it's fine - after Martin added a webhook that sends an email
> >> with a diff on push events. I felt blind without that (but it seems to
> >> be the norm, it's the same on github).
> >
> > ...cut...
> >
> >> Maren
> >
> > What do you mean with "push events"? Do you get an email with a diff for
> > each commit to master?
>
> - It's an email with a diff for the commits to any branch inside the
> repo per 'git push'.
>
> I don't know if commits that have been pushed together get a diff over
> all commits (but I think so - only I don't have any that contain more
> than one commit in my mail trash currently).
>
> Email addresses for subscribers (currently) need to be added manually by
> someone who has access to the settings.
Wouldn't it make sense to set up a mailing list where only the gitlab server
may send to, have gitlab send its push notifications there and allow people to
just subscribe? That would use the already existing mailing list
infrastructure and not require too much extra work.

> Screenshot of one of the mails attached (no custom code needed to create
> them, it's pre-made, just need to activate the option in the settings at
> gitlab).
>
> Regards,
>  Maren

Tobias

> > Best regards
> > --
> > Christoffer Holmstedt
> >
> >
> > --------------------------------------------------------------------------
> > ---- 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

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

Re: gitlab migration plan

Maren Hachmann
Am 03.03.2017 um 12:07 schrieb Tobias Ellinghaus:

<snip>

> Wouldn't it make sense to set up a mailing list where only the gitlab server
> may send to, have gitlab send its push notifications there and allow people to
> just subscribe? That would use the already existing mailing list
> infrastructure and not require too much extra work.

- Sounds like a very good idea to me, Tobias.

Martin, would that be easier to do for you than the webhook thing?

We wouldn't need to worry about any parsing of json, text or styling or
whatever, if we just use the mails that gitlab can already create. Only
need to make sure to allow html mails ;-)

Maren

>> Screenshot of one of the mails attached (no custom code needed to create
>> them, it's pre-made, just need to activate the option in the settings at
>> gitlab).
>>
>> Regards,
>>  Maren
>
> Tobias
>
>>> Best regards
>>> --
>>> Christoffer Holmstedt
>>>
>>>
>>> --------------------------------------------------------------------------
>>> ---- 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
>


------------------------------------------------------------------------------
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: gitlab migration plan

Martin Owens-2
On Fri, 2017-03-03 at 17:05 +0100, Maren Hachmann wrote:
> - Sounds like a very good idea to me, Tobias.
>
> Martin, would that be easier to do for you than the webhook thing?
>
> We wouldn't need to worry about any parsing of json, text or styling
> or whatever, if we just use the mails that gitlab can already create.
> Only need to make sure to allow html mails ;-)

Oye! mailing lists. Now there's a sore spot. Did you know that we're
still on sourceforge mailman2 because there's not an organisation in
the entire world that knows anything about mailing lists enough to help
us.

Our mailing lists in general need fixing, it's a good idea to have this
code detail mailing list, but we'll need to add it to the queue of
things we can do once we have found that mythical mailman supporting
organisation.

Best Regards, Martin Owens

------------------------------------------------------------------------------
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: gitlab migration plan

Bryce Harrington-3
On Fri, Mar 03, 2017 at 11:52:07AM -0500, Martin Owens wrote:

> On Fri, 2017-03-03 at 17:05 +0100, Maren Hachmann wrote:
> > - Sounds like a very good idea to me, Tobias.
> >
> > Martin, would that be easier to do for you than the webhook thing?
> >
> > We wouldn't need to worry about any parsing of json, text or styling
> > or whatever, if we just use the mails that gitlab can already create.
> > Only need to make sure to allow html mails ;-)
>
> Oye! mailing lists. Now there's a sore spot. Did you know that we're
> still on sourceforge mailman2 because there's not an organisation in
> the entire world that knows anything about mailing lists enough to help
> us.
>
> Our mailing lists in general need fixing, it's a good idea to have this
> code detail mailing list, but we'll need to add it to the queue of
> things we can do once we have found that mythical mailman supporting
> organisation.

Meanwhile, really no reason we couldn't set up another one at
sourceforge, if it helps with the git migration.

Mailman migration's on the todo list too but as you say, it's going to
take some concerted effort to sort out.

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: gitlab migration plan

Maren Hachmann
In reply to this post by Martin Owens-2
Am 03.03.2017 um 17:52 schrieb Martin Owens:

> On Fri, 2017-03-03 at 17:05 +0100, Maren Hachmann wrote:
>> - Sounds like a very good idea to me, Tobias.
>>
>> Martin, would that be easier to do for you than the webhook thing?
>>
>> We wouldn't need to worry about any parsing of json, text or styling
>> or whatever, if we just use the mails that gitlab can already create.
>> Only need to make sure to allow html mails ;-)
>
> Oye! mailing lists. Now there's a sore spot. Did you know that we're
> still on sourceforge mailman2 because there's not an organisation in
> the entire world that knows anything about mailing lists enough to help
> us.

- JFTR (it's not mailman3, so maybe too far from what you'd like):
Framasoft (French open source community) has a free service for Open
Source Projects:
https://framalistes.org/

They're using sympa, a mail server software I had never heard of before:
https://www.sympa.org/overview/features ,
https://en.wikipedia.org/wiki/Sympa

but which seems to be used by large organizations.

Maren

> Our mailing lists in general need fixing, it's a good idea to have this
> code detail mailing list, but we'll need to add it to the queue of
> things we can do once we have found that mythical mailman supporting
> organisation.
>
> Best Regards, Martin Owens
>


------------------------------------------------------------------------------
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: gitlab migration plan

Bryce Harrington-3
In reply to this post by maren
On Thu, Mar 02, 2017 at 03:12:42AM +0100, maren wrote:
> >>     + 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.
>
> - Thumbs up from me. No issues with inkscape-web or inkscape-web-i18n on
> gitlab.

Thanks Maren and Martin.  We discussed the migration at today's board
meeting, and will be proceeding with the next phase.  Expect further
details to be announced in the coming days with timing.

> >> 3.  Migrate inkscape to gitlab.
> >>
> >>     + All bzr committers are eligible for gitlab commit access,
> >>       but will need to place a request for access
> >>     + tweenk has a script to fix up discrepant author names and
> >>       e-mails.  Can't be shared publically since has personal info (but
> >>       could be passed to a board member via pgp encrypt).
> >>     + At least one dry run should be done, to ensure that revision
> >>       history, branches, tags, etc. are successfully converted.
> >>     + Functionality that uses 'bzr revno' (like the about screen) will
> >>       need modified to use git.
> >>       - Formatting for about screen should be something resembling:
> >>       "Inkscape 0.92+devel (2017-01-18 f0e47570)"
> >>       - git describe --tags --dirty
> >>       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.  It's not too hard to
> >>         clean up the tag name (remove "release-") and add the commit
> >>         date.
> >>       - Use the commit date rather than the author date
> >>     + Issues encountered with gitlab will be recorded in our bug tracker
> >>       with the 'gitlab-migration' tag.
> >>     + Transition of wiki pages can start as desired
> >>       (see separate plan proposal).
> >>     + Bugs stay on LP for now

Bryce

> >> 4.  Outreach effort to bring in contributors
> >>
> >>     + Assemble an outreach/advocacy team
> >>     + 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.
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> 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
>
>
> ------------------------------------------------------------------------------
> 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
Loading...