Fwd: Migration to Gitlab -- Update

[Yuri Chornoivan]

FYI

---------- Forwarded message ---------

Тема: Migration to Gitlab -- Update
Дата: неділя, 10 травня 2020 р., 10:48:50 EEST
Від: Ben Cooksley <bcoo...@kde.org>
Кому: kde-core-devel <kde-cor...@kde.org>, kde-devel <kde-...@kde.org>
Копія: sysadmin <sysa...@kde.org>

Good morning all,

We recently had a rather lengthy discussion concerning the final
manner in which Gitlab will be deployed for KDE.

To ensure everything is clear, we'd like to summarise that and present
the final structure which has been agreed upon, along with details on
tools that will be able to assist Developers with the migration and
working with Gitlab in the long term.

-- Timeline --

At the moment we are intending to perform a bulk migration of all
repositories from git.kde.org to invent.kde.org on 16 May 2020.

When this transition commences, git.kde.org will be made read-only.

Following this, the current system will be kept active in a read-only
configuration for two weeks (until 30 May 2020) to allow for everyone
to smoothly transition local clones and any automated systems over to
the new Gitlab setup.

-- Structure --

Following lengthy discussion in the original thread, it was agreed
that the original sysadmin proposal of various categories would be
implemented, with repositories organised according to that structure.

You can find this documented at
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/
invent

-- Tooling --

To assist developers with the transition process, Sysadmin has
developed a utility ('git kpull') which once setup on a developers
system will automatically migrate any git.kde.org/anongit.kde.org to
the new structure automatically, before proceeding with a regular 'git
pull' when run in a Git repository.

Additionally, as some developers had concerns regarding locating
repositories, an additional utility known as 'git kclone' is being
shipped as well. This will allow developers to run "git kclone
<identifier>" to clone a repository.

In the majority (95%) of cases we expect "<identifier>" to be
identical to the repository name (frameworks/kcoreaddons being
kcoreaddons for instance), however where the name is common (such as
'dialer') then it will be prefixed by the name of the originating
project (so maui/dialer would have an identifier of maui-dialer)
following the convention we use at the moment for projects wishing to
have a repository using a common name.

It should be noted that 'git kclone' is also able to perform bulk
clones based on wildcard patterns (which you could use to clone all
frameworks by running "git kclone frameworks/*" for example)

Instructions on how to set this up on your system will be sent out
closer to the migration commencing.

-- Continuous Integration --

Following the migration, we will continue to use our existing Jenkins
based setup. Migration to using Gitlab for CI purposes will take place
at a later date once the necessary adjustments to the CI
infrastructure have been completed.

During the intervening time CI capability will be available on Gitlab
for evaluation and testing purposes only.

This is not supported as a standard production level service by
Sysadmin and therefore should not be relied upon by projects as part
of their workflow.

-- Tasks --

Tasks will be migrated from Phabricator at a future point in time.
These will remain on Phabricator for the time being and are not
affected by the migration.

Projects wishing to start entirely new boards and not needing to work
with  existing boards on Phabricator should feel free to begin making
use of their new Gitlab boards following the migration.

-- Migration from Phabricator --

Existing code reviews will not be migrated from Phabricator as part of
this migration process and will need to be completed using the usual
process on Phabricator. It is expected that following the completion
of the migration of code hosting that no further new reviews will be
started on Phabricator.

Please note that because Phabricator is dependent on the existing
git.kde.org/anongit.kde.org setup, once those are shutdown the hooks
that automatically close reviews will no longer operate.

Tasks will be migrated in a future step, following which Phabricator
will be shutdown. Based on initial testing we expect to be able to
provide a static copy of Phabricator (for reviews only as tasks will
have been migrated at this stage) for long term archival purposes.

-- Conclusion --

Should anyone have any questions regarding the above, please let us know!

Thanks,
Ben Cooksley
KDE Sysadmin

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

[Davide Gianforte]

Hi,

good news :) This week I stopped working on Krusader waiting for this.


Phabricator

I have no relevant tasks to migrate/complete, so they could be abandoned. I have 3 revisions open, one of them require more tests (keyboard widget focus), the other two could be commited but I want to do that on Gitlab to check that all is working well.

We have also some old Revisions that Toni is handling, but as Phabricator will remain read-only for a while, we could migrate them manually without rush.


Gitlab/Invent

I think we'll handle the commits through issues/merge requests (I'm lurking major teams/repo to see how they work). As we are a small team, the basic idea is to create an issue (optional, because we could keep the discussion on the merge request) and a related marge request (directly on master branch). I still didn't get if Bugzilla will integrate with invent, I'm sure that normal users won't open issues.

I haven't tested yet if forked repositories can be synced upstream (it's a paid feature on gitlab); this means we could create merge requests from the fork directly to the upstream/master; this will keep the main repo cleaner, but as long as we delete branch when doing the merge requests, this feature is not essential (it could be messy when there are many requests opened).


Happy coding,
Davide

[Yuri Chornoivan]

пт, 15 трав. 2020 о 11:19 Davide Gianforte <dav...@gengisdave.org> пише:

Hi,

good news :) This week I stopped working on Krusader waiting for this.


Phabricator

I have no relevant tasks to migrate/complete, so they could be abandoned. I have 3 revisions open, one of them require more tests (keyboard widget focus), the other two could be commited but I want to do that on Gitlab to check that all is working well.

We have also some old Revisions that Toni is handling, but as Phabricator will remain read-only for a while, we could migrate them manually without rush.


Gitlab/Invent

I think we'll handle the commits through issues/merge requests (I'm lurking major teams/repo to see how they work). As we are a small team, the basic idea is to create an issue (optional, because we could keep the discussion on the merge request) and a related marge request (directly on master branch). I still didn't get if Bugzilla will integrate with invent, I'm sure that normal users won't open issues.

I haven't tested yet if forked repositories can be synced upstream (it's a paid feature on gitlab); this means we could create merge requests from the fork directly to the upstream/master; this will keep the main repo cleaner, but as long as we delete branch when doing the merge requests, this feature is not essential (it could be messy when there are many requests opened).


Happy coding,
Davide

Hi,

It might happen that you have already read this, but here are some useful tips on how to use KDE gitlab instance:

https://tsdgeos.blogspot.com/2020/02/working-with-different-remotes-in-git.html

Hope this helps.

Best regards,

Yuri

 

On domenica 10 maggio 2020 09:56:54 CEST Yuri Chornoivan wrote:
> FYI
> ---------- Forwarded message ---------
> Тема: Migration to Gitlab -- Update
> Дата: неділя, 10 травня 2020 р., 10:48:50 EEST
> Від: Ben Cooksley <bcoo...@kde.org>
> Кому: kde-core-devel <kde-cor...@kde.org>, kde-devel <kde-...@kde.org>
> Копія: sysadmin <sysa...@kde.org>
>
> Good morning all,

--
You received this message because you are subscribed to the Google Groups "krusader-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to krusader-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/krusader-devel/24458123.1r3eYUQgxm%40slayer.gengisdave.org.

[Toni Asensi Esteve]

In https://invent.kde.org/utilities I've seen:

krusader 1 hour ago

and so

https://invent.kde.org/utilities/krusader

is working.

[Toni Asensi Esteve]

P.S. https://invent.kde.org/websites/krusader-org has also been created.

 

[Davide Gianforte]

On venerdì 15 maggio 2020 11:09:53 CEST Yuri Chornoivan wrote:
> Hi,
>
> It might happen that you have already read this, but here are some
> useful tips on how to use KDE gitlab instance:
>
> https://tsdgeos.blogspot.com/2020/02/working-with-different-remotes-in-git.html
>
> Hope this helps.
>
> Best regards,
> Yuri

Hi all,

I did a fast read this article time ago, but never worked on it (it's still to be read on my e-reader).

I think it's the best way to keep things (repo) clean: we pull from the upstream/master branch and push a new branch to our fork, then proceed with the merge request to upstream/master (in this situation, the branch name could be almost anything, as it will deleted with the merge).

Issues does not seems to be used in everyday code activity; it could be used in a future, like for change proposals.

I've already forked Krusader, permissions seem to be ok; I will create some commits in the next days.

Cheers,
Davide

[Davide Gianforte]

Hi all,

good news, all is working well. Sysadmins did a perfect job. I've created a merge request not related to a bug and an issue related to a bug that will have sooner a merge request.

Looking at other projects, we should create some labels to use on merge requests; take a look at Krita (https://invent.kde.org/graphics/krita/-/labels), they use Gitlab since the beginning of the year.

The guide link posted by Yuri is working perfect, at the beginning it could be a bit tricky but once you get used to, it's a good way.

Cheers
Davide

[Toni Asensi Esteve]

> Hi all,

>

> [...]

> Looking at other projects, we should create some labels to use on merge

> requests; take a look at Krita

> (https://invent.kde.org/graphics/krita/-/labels), they use Gitlab since

> the beginning of the year.

 

I've looked for other label systems in:

https://invent.kde.org/graphics/okular/-/labels

https://invent.kde.org/utilities/kate/-/labels

https://invent.kde.org/utilities/okteta/-/labels

https://invent.kde.org/utilities/konsole/-/labels

https://invent.kde.org/sdk/kompare/-/labels

https://invent.kde.org/system/dolphin/-/labels

and, for Krusader, the label system that is seen in https://invent.kde.org/graphics/krita/-/labels seems to be better, at least for me. Thank you all!

Toni

 

[Davide Gianforte]

On martedì 19 maggio 2020 23:12:52 CEST Toni Asensi Esteve wrote:
> and, for Krusader, the label system that is seen in
> https://invent.kde.org/graphics/krita/-/labels seems to be better, at least
> for me. Thank you all!
> Toni

I've created some label:

Needs Review, Needs Changes and Approved will refer to the usual MR lifecycle.

Bugfix, Wishlist, Feature Request and Documentation are the applied to describe what the MR does; the first two are related with bugs.kde.org and Documentation is used when we change something in doc/

You are free to change descriptions/names/colours.

Davide

[Toni Asensi Esteve]

> I've created some label:

>

> Needs Review, Needs Changes and Approved will refer to the usual MR

> lifecycle.

>

> Bugfix, Wishlist, Feature Request and Documentation are the applied to

> describe what the MR does; the first two are related with bugs.kde.org and

> Documentation is used when we change something in doc/

>

> You are free to change descriptions/names/colours.

>

> Davide

 

Nice!

 

Just a question, is the meaning of the "Feature Request" label very different from the "Wishlist" one?

 

Thanks!

[Davide Gianforte]

The slight difference is that wishlist is related to a bug filled, while
feature request isn't. On a second thought, I would drop the "wishlist" label
using "feature request" paired with "bugfix" to point a wishlist bug, I would
also add a new label called "Improvement" for janitor works (like code
improvement, compiler fixes, etc.).

Davide

[Toni Asensi Esteve]

> The slight difference is that wishlist is related to a bug filled, while

> feature request isn't. On a second thought, I would drop the "wishlist"

> label using "feature request" paired with "bugfix" to point a wishlist bug,

 

It looks good to me (TM😊).

 

> I would also add a new label called "Improvement" for janitor works (like

> code improvement, compiler fixes, etc.).

 

I'm thinking that, since practically everything committed somehow improves Krusader, and because that label is also not used in the Krita label system, not adding that label would clarify the processes. In the commits I would keep the system of adding texts like "FIXED:", "ADDED:", etc. that allows later executing

$ git log v2.7.2.. | grep 'FIXED:\|ADDED:\|UPDATED:\|CHANGED:\|REMOVED:' | sort

to get information for the ChangeLog file, and to get a general impression.

 

In https://invent.kde.org/websites/krusader-org we can use the same labels in order to simplify its maintenance (e.g. everything applied to one label system it would be easily applied to the other one), or do you think that it would be better to use different ones?

 

Greetings!

Toni

[Davide Gianforte]

On giovedì 21 maggio 2020 22:44:56 CEST Toni Asensi Esteve wrote:
> > The slight difference is that wishlist is related to a bug filled, while
> > feature request isn't. On a second thought, I would drop the "wishlist"
> > label using "feature request" paired with "bugfix" to point a wishlist bug,
>
> It looks good to me (TM😊).
>
> > I would also add a new label called "Improvement" for janitor works (like
> > code improvement, compiler fixes, etc.).
>
> I'm thinking that, since practically everything committed somehow improves
> Krusader, and because that label is also not used in the Krita label system,
> not adding that label would clarify the processes. In the commits I would keep
> the system of adding texts like "FIXED:", "ADDED:", etc. that allows later
> executing
> $ git log v2.7.2.. | grep 'FIXED:\|ADDED:\|UPDATED:\|CHANGED:\|REMOVED:' |
> sort
> to get information for the ChangeLog file, and to get a general impression.

No need at all to touch the ChangeLog logic; I'll just remove the "Wishlist"
label.

>
> In https://invent.kde.org/websites/krusader-org we can use the same labels in
> order to simplify its maintenance (e.g. everything applied to one label system
> it would be easily applied to the other one), or do you think that it would be
> better to use different ones?
>
> Greetings!
> Toni

For the website we don't have to clarify with a label what the MR does, I think
the title itself will be enough.

On the other hand, the status labels "Needs review", "Needs changes" and
"Approved" are useful.

Davide

[Toni Asensi Esteve]

> For the website we don't have to clarify with a label what the MR

> does, I think the title itself will be enough.

 

> On the other hand, the status labels "Needs review", "Needs changes" and

> "Approved" are useful.

 

All right! I've added those labels to https://invent.kde.org/websites/krusader-org

using the same names, descriptions and colors.

 

Best regards,

Toni