Re: Proposal: make squash-merging the default behavior for gitlab MRs

[Boudewijn Rempt]

On Friday, 2 October 2020 19:39:37 CEST Nate Graham wrote:

> Thoughts?

Like others have said, please, no. Squashed commits are the worst things to 
have in a git history. They make it hard to use git blame, they make it hard to 
read the history... And the whole argument about making life easier for 
drive-by contributors and newbies and people not familiar with git isn't to the 
point anyway: those people will make a fork, do their work, make a merge 
request, get that reviewed, and then the maintainer does the merge.

-- 
https://www.krita.org

Announcing MyKDE

[Carl Schwan]

Hello folks,
I'm happy to announce the successful deployment of the new identity system
in KDE, codename MyKDE. The new identity system is now available in
https://my.kde.org. You should be able to login into the my.kde.org website
with your normal KDE credential.

For the moment, only the wikis are using MyKDE but in the comming months
this should change with more and more services switching to MyKDE. I will
let you all know of the progress of the migration.


FAQ:


Why the move?
-

identity.kde.org is using OpenLDAP for user management with a small PHP
frontend allowing the account creation. And we had the following problems
with it:

* Account removal is hard, requiring significant manual intervention and
effort (several hours work in some instances)
* Account registration takes 30 seconds or more to complete, creating a poor
user experience
* Groups don't scale effectively
* Anti-spam measures are too crude

More on that in https://phabricator.kde.org/T8449

Will my data be migrated?
-

Yes, your data are migrated just by login into MyKDE once. This will migrate
all your group membership (KDE developer, Akademy Team, ...), personal
data and password.

For users who didn't log into MyKDE during the migration period. If you are
a KDE developer or KDE e.V. member, your account will be imported as a
disabled account and you will need to ask sysadmins to enabled it. For the
rest of the users of identity.kde.org who don't have a membership to groups,
your account will be removed. We think this is the best solution because there
is no need to store personal information that we don't need from users who
don't use the system anymore. If you want to conserve your account (and
username), please log at least once. We will send periodic emails reminding
you of migrating your account.

How do I register a new account in MyKDE?
-

For the moment the possibility of registering a new account is disabled in
MyKDE and the only possibility is to create an identity.kde.org account and
then migrate your account. This is due to the fact we don't want some
accounts existing only in MyKDE. This will naturally change when we migrate
fully to MyKDE.

How to I collect a badge?
-

MyKDE has the possibility to grant badges to users. For the moment there is
only one badge enabled: KDE developer. This badge is given to every KDE
developer and is displayed on their public profile (if enabled). When the
new Season of KDE website will be deployed, it will be also possible to have
an SoK mentor and SoK mentee badge.

I'm interested in ideas of new badges (and badge designs), so please let me
know if you have a genius idea that doesn't gamify KDE contribution (e.g no made
100/1000/10 000 commits badge).

Note that you are in control of that badge get displayed.

What is the public profile functionality?
-

One of the new features of MyKDE is the possibility to have a public profile.
This public profile is opt-in, so you need to explicitly enable it to make
it work and it can display a small bio, your avatar, name, username, social
network account, Liberapay account, and badges earned.

This is for example how it looks for me: https://my.kde.org/user/carlschwan/

Can I contribute to MyKDE?
--

Yes, the source code is hosted in https://invent.kde.org/websites/my-kde-org
and all the deployment information can be found here:
https://sysadmin-docs.kde.org/services/mykde.html

Cheers,
Carl Schwan
https://carlschwan.eu

Re: Proposal: make squash-merging the default behavior for gitlab MRs

[David Hurka]

> That doesn't prevent me from having a clean history when I finally git-push
> to an opened MR, so my colleagues could easily review my code. I know that
> if I'd push some "dirty" commits to my "merge request", my colleagues would
> unnecessarily spend time navigating these commits, and reviewing code-lines
> that were fixed in the further commit. And why? Just because I didn't care
> to squash last commit?

Why should colleagues navigate through any commits, when the MR is intended to 
be squashed? Wouldn’t squash merge make it easier to review an MR?

> I should note though that while I do a lot of stuff with git as I work
> (e.g. swapping commits, amending a commit, going back to a commit in history
> then changing it, etc.), I spend minuscule amount of time on it.

I think this can not be expected from new contributors.

If the default for this checkbox is configurable per user, I would like it 
when new MRs from new contributors are squash merged by default.

New users usually submit easier patches, right? Such patches usually can not 
be separated into individual, clean commits, unless we want to push broken 
code to production branches.

If we reject a patch submitted a new user with “Thanks, your patch finally 
fixes this annoying bug, but we can not accept it, because I don’t like your 
git history. Please learn git first.”, that would IMHO be the first step to 
make KDE a closed community.

Re: Proposal: make squash-merging the default behavior for gitlab MRs

[Johan Ouwerkerk]

On Sat, Oct 3, 2020 at 12:26 AM David Hurka  wrote:
>
> > > However, it remains a fairly advanced workflow which is challenging for
> > > newcomers, drive-by-developers, and people not as familiar with git. For
> > > these people, squash-merging makes much more sense, [...]
>
> This workflow is too advanced for me. My commits are usually garbage like “fix
> pipeline”, and often contain notes on what I was doing and what I still need
> to do. If I was maintaining a clean history, that wouldn’t be possible.
>

Arguing from theory on maintaining a good commit history, this
actually means you should not be squashing your commits -- you should
be using the `fixup` operation in an interactive rebase

But I understand where you are coming from. At work we used to have a
policy on squash commits for much the same reason, even professional
developers don't always bother to learn their scm tools. (I've also
worked with someone who did not appreciate the idea of commit history
and commit messages at all, as in a "why would I ever look at that?"
level of don't care).

Still others have raised a valid point that for long term maintenance
it is better to have a curated history if you can get it. That is why
we abandoned it eventually, especially for non-functional refactoring
commits or for a bunch of accumulated bug fixes squashing did more
harm than good. Essentially you get punished for doing things
'correctly' (for opinionated values of correct).

>
> Is it possible to make the default configurable for each user? Then I could
> simply check “Squash by default” and all my MRs are how I want them.
>
>

I'm not sure about that, but at least it *is* possible to do this per
repo, there's no need why projects should stick to a global default.
So if you're the maintainer you could nudge the default towards what
makes sense for your project and its dominant workflow. Go to Settings
(side bar) > General > Squashing and merging. Apparently that has been
a feature of Gitlab core since version 11.

Regards,

- Johan Ouwerkerk

Re: Proposal: make squash-merging the default behavior for gitlab MRs

[Johan Ouwerkerk]

On Sat, Oct 3, 2020 at 10:15 AM Boudewijn Rempt  wrote:
>
> On Friday, 2 October 2020 19:39:37 CEST Nate Graham wrote:
>
> > Thoughts?
>
> Like others have said, please, no. Squashed commits are the worst things to 
> have in a git history. They make it hard to use git blame, they make it hard 
> to read the history... And the whole argument about making life easier for 
> drive-by contributors and newbies and people not familiar with git isn't to 
> the point anyway: those people will make a fork, do their work, make a merge 
> request, get that reviewed, and then the maintainer does the merge.
>

This last bit is worth emphasising strongly. The whole thing is only
at issue because in KDE we assume every developer can land their
changes anywhere and rely on an honour system to enforce that it is
properly reviewed (with the exception of sysadmin stuff). But many
drive-by contributors and newbies or even seasoned contributors won't
be deterred at all from not having commit access to the main repo.
Additionally I suspect not many people will object to a maintainer
taking their changes but landing them in different commits or a
slightly different form either.

Regards,

- Johan Ouwerkerk

Re: Proposal: make squash-merging the default behavior for gitlab MRs

[David Edmundson]

>
> your_merge_request_commit_history
> 
> .
>
> However, it remains a fairly advanced workflow which is challenging for
> newcomers, drive-by-developers, and people not as familiar with git. For
> these people, squash-merging makes much more sense, and when they forget
> to check that checkbox and someone merges their work, the result is tons
> of garbage commits in the git history.
>

I do agree that state is a problem. Because we know that box exists we
press approve when the commits themselves are garbage and then we get this
mess.

Accordingly, I think squash-merging makes sense as the default value to
> avoid this. People who are comfortable with the "curated MR commit
> history" workflow will of course still be able to turn it off. IMO it
> makes more sense to ask experts to turn it off than to ask newcomers and
> novices to turn it on.
>
> Thoughts?
>

-1
New to kde doesn't mean new to git. We have a lot of skilled people, and
one of the biggest gains of adopting gitlab is that we expose git more
directly.

Imho that feature request to gitlab to set a default isn't actually what
we're after. It's requesting a bodge that replaces one problem with another.

We don't want a default for a merge option, we want an exposed action like
the existing rebase button to squash things within the local branch. That
would mean reviewers can review commits (and therefore review commit
messages properly) and you still provide an easy path for people who can't
squash locally. If we only approve when commits themselves are sound, it'll
be easy to manage. Win-win.

David

Re: Proposal: make squash-merging the default behavior for gitlab MRs

[Johan Ouwerkerk]

On Sat, Oct 3, 2020 at 12:19 PM David Hurka  wrote:
>
> Why should colleagues navigate through any commits, when the MR is intended to
> be squashed? Wouldn’t squash merge make it easier to review an MR?
>

No because squashing happens only when merging, i.e. *after*
reviewing. So if you review commit-by-commit you have more work and
you're more likely to comment on things which turn out to be fixed by
a later commit.

>
> I think this can not be expected from new contributors.
>
> If we reject a patch submitted a new user with “Thanks, your patch finally
> fixes this annoying bug, but we can not accept it, because I don’t like your
> git history. Please learn git first.”, that would IMHO be the first step to
> make KDE a closed community.
>

I think that the other position is more accurately stated as follows:
if a patch needs work on the git commit level but the code is fine,
perhaps the maintainer should sit down and take time to checkout that
branch locally, do their git magic until they are satisfied and then
push that result to master.
Then just leave a comment on the MR thanking people for their work,
explaining their changes got merged into master via a different route
and invite the contributor to test the new shiny to validate that
their issue is fully fixed.

A similar thing is also needed w.r.t. rebasing if for example you want
to preserve a linear history in master: you can't expect drive by
contributors to have infinite patience to check back and rebase, but
it's not unreasonable for a maintainer who insists on linear history
to shoulder that burden when they get round to merging things in.

In general both approaches would point towards contributors not
merging things on their own by default until they're familiar with the
project and made a co-maintainer. It is also more closely aligned with
the PR/MR workflow itself: note the R stands for "request" after all
:) With active maintainers, that should not be hostile to new
contributors, since you mostly care that your issue gets scratched and
not who does the scratching...

But it does require very active maintainers and it may not be a good
fit for all projects. :)

Regards,

- Johan Ouwerkerk

Re: Proposal: make squash-merging the default behavior for gitlab MRs

[Elvis Angelaccio]

On 02/10/20 19:39, Nate Graham wrote:
> Hello folks,

Hi

> I've been told that our Sysadmins have developed some tooling capable of
> checking the "Squash when merging" checkbox by default for new Merge
> Requests. This would be a downstream solution to
> https://gitlab.com/gitlab-org/gitlab/-/issues/222175.
> 
> I'd like to propose that this be done as a sane default for new Merge
> Requests. Now, personally I have gotten used to the alternative "curate
> your MR's git history" approach and have written documentation for it at
> https://community.kde.org/Infrastructure/GitLab#Curating_your_merge_request_commit_history.
> 
> 
> However, it remains a fairly advanced workflow which is challenging for
> newcomers, drive-by-developers, and people not as familiar with git. For
> these people, squash-merging makes much more sense, and when they forget
> to check that checkbox and someone merges their work, the result is tons
> of garbage commits in the git history.

People should not blindly merge a MR without checking the commit history
first:
- if the submitter pushed one or more well-written atomic commits, those
can be merged without squashing
- otherwise, whoever merges the MR should squash the history and write a
proper commit message. Or they should ask the submitter to fix its history.

> 
> Accordingly, I think squash-merging makes sense as the default value to
> avoid this. People who are comfortable with the "curated MR commit
> history" workflow will of course still be able to turn it off. IMO it
> makes more sense to ask experts to turn it off than to ask newcomers and
> novices to turn it on.

+0, I don't have a preference for this default value. As explained, it's
orthogonal to the problem of a bad commit history.

> 
> Thoughts?
> 
> Nate

Cheers,
Elvis

Re: Announcing MyKDE

[Nate Graham]

Super cool stuff! Great work, Carl.

Nate



On 10/3/20 3:56 AM, Carl Schwan wrote:

Hello folks,
I'm happy to announce the successful deployment of the new identity system
in KDE, codename MyKDE. The new identity system is now available in
https://my.kde.org. You should be able to login into the my.kde.org website
with your normal KDE credential.

For the moment, only the wikis are using MyKDE but in the comming months
this should change with more and more services switching to MyKDE. I will
let you all know of the progress of the migration.


FAQ:


Why the move?
-

identity.kde.org is using OpenLDAP for user management with a small PHP
frontend allowing the account creation. And we had the following problems
with it:

* Account removal is hard, requiring significant manual intervention and
effort (several hours work in some instances)
* Account registration takes 30 seconds or more to complete, creating a poor
user experience
* Groups don't scale effectively
* Anti-spam measures are too crude

More on that in https://phabricator.kde.org/T8449

Will my data be migrated?
-

Yes, your data are migrated just by login into MyKDE once. This will migrate
all your group membership (KDE developer, Akademy Team, ...), personal
data and password.

For users who didn't log into MyKDE during the migration period. If you are
a KDE developer or KDE e.V. member, your account will be imported as a
disabled account and you will need to ask sysadmins to enabled it. For the
rest of the users of identity.kde.org who don't have a membership to groups,
your account will be removed. We think this is the best solution because there
is no need to store personal information that we don't need from users who
don't use the system anymore. If you want to conserve your account (and
username), please log at least once. We will send periodic emails reminding
you of migrating your account.

How do I register a new account in MyKDE?
-

For the moment the possibility of registering a new account is disabled in
MyKDE and the only possibility is to create an identity.kde.org account and
then migrate your account. This is due to the fact we don't want some
accounts existing only in MyKDE. This will naturally change when we migrate
fully to MyKDE.

How to I collect a badge?
-

MyKDE has the possibility to grant badges to users. For the moment there is
only one badge enabled: KDE developer. This badge is given to every KDE
developer and is displayed on their public profile (if enabled). When the
new Season of KDE website will be deployed, it will be also possible to have
an SoK mentor and SoK mentee badge.

I'm interested in ideas of new badges (and badge designs), so please let me
know if you have a genius idea that doesn't gamify KDE contribution (e.g no made
100/1000/10 000 commits badge).

Note that you are in control of that badge get displayed.

What is the public profile functionality?
-

One of the new features of MyKDE is the possibility to have a public profile.
This public profile is opt-in, so you need to explicitly enable it to make
it work and it can display a small bio, your avatar, name, username, social
network account, Liberapay account, and badges earned.

This is for example how it looks for me: https://my.kde.org/user/carlschwan/

Can I contribute to MyKDE?
--

Yes, the source code is hosted in https://invent.kde.org/websites/my-kde-org
and all the deployment information can be found here:
https://sysadmin-docs.kde.org/services/mykde.html

Cheers,
Carl Schwan
https://carlschwan.eu

Re: Announcing MyKDE

[Uli Klinkhammer]

Hey Carl.

Great work!! Many thanks for that.

Uli


On 2020-10-03 11:56, Carl Schwan wrote:
> Hello folks,
> I'm happy to announce the successful deployment of the new identity system
> in KDE, codename MyKDE. The new identity system is now available in
> https://my.kde.org. You should be able to login into the my.kde.org website
> with your normal KDE credential.
>
> For the moment, only the wikis are using MyKDE but in the comming months
> this should change with more and more services switching to MyKDE. I will
> let you all know of the progress of the migration.
>
>
> FAQ:
> 
>
> Why the move?
> -
>
> identity.kde.org is using OpenLDAP for user management with a small PHP
> frontend allowing the account creation. And we had the following problems
> with it:
>
> * Account removal is hard, requiring significant manual intervention and
> effort (several hours work in some instances)
> * Account registration takes 30 seconds or more to complete, creating a poor
> user experience
> * Groups don't scale effectively
> * Anti-spam measures are too crude
>
> More on that in https://phabricator.kde.org/T8449
>
> Will my data be migrated?
> -
>
> Yes, your data are migrated just by login into MyKDE once. This will migrate
> all your group membership (KDE developer, Akademy Team, ...), personal
> data and password.
>
> For users who didn't log into MyKDE during the migration period. If you are
> a KDE developer or KDE e.V. member, your account will be imported as a
> disabled account and you will need to ask sysadmins to enabled it. For the
> rest of the users of identity.kde.org who don't have a membership to groups,
> your account will be removed. We think this is the best solution because there
> is no need to store personal information that we don't need from users who
> don't use the system anymore. If you want to conserve your account (and
> username), please log at least once. We will send periodic emails reminding
> you of migrating your account.
>
> How do I register a new account in MyKDE?
> -
>
> For the moment the possibility of registering a new account is disabled in
> MyKDE and the only possibility is to create an identity.kde.org account and
> then migrate your account. This is due to the fact we don't want some
> accounts existing only in MyKDE. This will naturally change when we migrate
> fully to MyKDE.
>
> How to I collect a badge?
> -
>
> MyKDE has the possibility to grant badges to users. For the moment there is
> only one badge enabled: KDE developer. This badge is given to every KDE
> developer and is displayed on their public profile (if enabled). When the
> new Season of KDE website will be deployed, it will be also possible to have
> an SoK mentor and SoK mentee badge.
>
> I'm interested in ideas of new badges (and badge designs), so please let me
> know if you have a genius idea that doesn't gamify KDE contribution (e.g no 
> made
> 100/1000/10 000 commits badge).
>
> Note that you are in control of that badge get displayed.
>
> What is the public profile functionality?
> -
>
> One of the new features of MyKDE is the possibility to have a public profile.
> This public profile is opt-in, so you need to explicitly enable it to make
> it work and it can display a small bio, your avatar, name, username, social
> network account, Liberapay account, and badges earned.
>
> This is for example how it looks for me: https://my.kde.org/user/carlschwan/
>
> Can I contribute to MyKDE?
> --
>
> Yes, the source code is hosted in https://invent.kde.org/websites/my-kde-org
> and all the deployment information can be found here:
> https://sysadmin-docs.kde.org/services/mykde.html
>
> Cheers,
> Carl Schwan
> https://carlschwan.eu
>
>

Re: Announcing MyKDE

[Piyush Aggarwal]

Amazing work!

Best
Piyush Aggarwal

On Sat, 3 Oct, 2020, 3:26 pm Carl Schwan,  wrote:

> Hello folks,
> I'm happy to announce the successful deployment of the new identity system
> in KDE, codename MyKDE. The new identity system is now available in
> https://my.kde.org. You should be able to login into the my.kde.org
> website
> with your normal KDE credential.
>
> For the moment, only the wikis are using MyKDE but in the comming months
> this should change with more and more services switching to MyKDE. I will
> let you all know of the progress of the migration.
>
>
> FAQ:
> 
>
> Why the move?
> -
>
> identity.kde.org is using OpenLDAP for user management with a small PHP
> frontend allowing the account creation. And we had the following problems
> with it:
>
> * Account removal is hard, requiring significant manual intervention and
> effort (several hours work in some instances)
> * Account registration takes 30 seconds or more to complete, creating a
> poor
> user experience
> * Groups don't scale effectively
> * Anti-spam measures are too crude
>
> More on that in https://phabricator.kde.org/T8449
>
> Will my data be migrated?
> -
>
> Yes, your data are migrated just by login into MyKDE once. This will
> migrate
> all your group membership (KDE developer, Akademy Team, ...), personal
> data and password.
>
> For users who didn't log into MyKDE during the migration period. If you are
> a KDE developer or KDE e.V. member, your account will be imported as a
> disabled account and you will need to ask sysadmins to enabled it. For the
> rest of the users of identity.kde.org who don't have a membership to
> groups,
> your account will be removed. We think this is the best solution because
> there
> is no need to store personal information that we don't need from users who
> don't use the system anymore. If you want to conserve your account (and
> username), please log at least once. We will send periodic emails reminding
> you of migrating your account.
>
> How do I register a new account in MyKDE?
> -
>
> For the moment the possibility of registering a new account is disabled in
> MyKDE and the only possibility is to create an identity.kde.org account
> and
> then migrate your account. This is due to the fact we don't want some
> accounts existing only in MyKDE. This will naturally change when we migrate
> fully to MyKDE.
>
> How to I collect a badge?
> -
>
> MyKDE has the possibility to grant badges to users. For the moment there is
> only one badge enabled: KDE developer. This badge is given to every KDE
> developer and is displayed on their public profile (if enabled). When the
> new Season of KDE website will be deployed, it will be also possible to
> have
> an SoK mentor and SoK mentee badge.
>
> I'm interested in ideas of new badges (and badge designs), so please let me
> know if you have a genius idea that doesn't gamify KDE contribution (e.g
> no made
> 100/1000/10 000 commits badge).
>
> Note that you are in control of that badge get displayed.
>
> What is the public profile functionality?
> -
>
> One of the new features of MyKDE is the possibility to have a public
> profile.
> This public profile is opt-in, so you need to explicitly enable it to make
> it work and it can display a small bio, your avatar, name, username, social
> network account, Liberapay account, and badges earned.
>
> This is for example how it looks for me:
> https://my.kde.org/user/carlschwan/
>
> Can I contribute to MyKDE?
> --
>
> Yes, the source code is hosted in
> https://invent.kde.org/websites/my-kde-org
> and all the deployment information can be found here:
> https://sysadmin-docs.kde.org/services/mykde.html
>
> Cheers,
> Carl Schwan
> https://carlschwan.eu
>
>
>