The ultimate bikeshed: typos in commit messages

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The ultimate bikeshed: typos in commit messages

Jeroen De Dauw-2
Hey,

I have observed a difference in opinion between two groups of people on
gerrit, which unfortunately is causing bad blood on both sides. I'm
therefore interested in hearing your opinion about the following scenario:

Someone makes a sound commit. The commit has a clear commit message, though
there is a single typo in it. Is it helpful to -1 the commit because of the
typo?

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Nikola Smolenski-2
On 15/01/13 12:44, Jeroen De Dauw wrote:
> I have observed a difference in opinion between two groups of people on
> gerrit, which unfortunately is causing bad blood on both sides. I'm
> therefore interested in hearing your opinion about the following scenario:
>
> Someone makes a sound commit. The commit has a clear commit message, though
> there is a single typo in it. Is it helpful to -1 the commit because of the
> typo?

This intricate, complex and important question deserves a long and
thoughtful answer.

In my opinion, if the typo is trivial (f.e. someone typed "fo" instead
of "of"), there is no need to -1 the commit, however if the typo
pertains to a crucial element of the commit (f.e. someone typed "fixed
wkidata bug") perhaps it should, since otherwise people who search
through commit messages won't be able to find commits that contain word
"wikidata".

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Daniel Kinzler
In reply to this post by Jeroen De Dauw-2
On 15.01.2013 12:44, Jeroen De Dauw wrote:
> Hey,
>
> I have observed a difference in opinion between two groups of people on
> gerrit, which unfortunately is causing bad blood on both sides. I'm
> therefore interested in hearing your opinion about the following scenario:
>
> Someone makes a sound commit. The commit has a clear commit message, though
> there is a single typo in it. Is it helpful to -1 the commit because of the
> typo?

Yes, I have noticed the same.

My very personal opinion:

No, a -1 is not justified because of a typo in a commit message. Doing that just
causes a lot of overhead for extremely little benefit. If someone is really
bothered by it, they can fix it themselves.

It's like reverting a Wikipedia edit because of a type. You don't do that. You
fix it or leave it.

The only semi-valid argument I have heard in support is that commit messages
(may) go into the release notes. But release notes are edited, formatted and
spell-checked anyway, and they don't include all commit messages. Not even all
tag lines.

Personally, if I do a quick fix of a bug I find somewhere, and the fix gets a -1
for a typo in the commit message, I'm tempted to just walk away and let it rot.
I'm immature like that I guess... and I'm pretty sure I'm not the only one.

-- daniel

PS: note that this is about typos. A commit with an incomprehensible or plain
wrong commit message should indeed get a -1.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Daniel Kinzler
In reply to this post by Nikola Smolenski-2
On 15.01.2013 12:58, Nikola Smolenski wrote:
> In my opinion, if the typo is trivial (f.e. someone typed "fo" instead of "of"),
> there is no need to -1 the commit, however if the typo pertains to a crucial
> element of the commit (f.e. someone typed "fixed wkidata bug") perhaps it
> should, since otherwise people who search through commit messages won't be able
> to find commits that contain word "wikidata".

Ok, full text search might be an argument in some cases (does that even work on
gerrit?).

But in that regard, wouldn't it be much more important to enforce (bug 12345)
links to bugzilla by giving a -1 to commits that don't have them (though they
clearly have, or should have, a bug report?)

I'm still in favor of requiring every tag line to contain either (bug nnnnn) or
(minor), so people are reminded that bugs should be filed and linked for
anything that is not trivial. That's not what I want to discuss here - it just
strikes me as much more relevant than typos, yet people don't seem to be too
keen to enforce that.

-- daniel

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Chad
In reply to this post by Jeroen De Dauw-2
On Tue, Jan 15, 2013 at 6:44 AM, Jeroen De Dauw <[hidden email]> wrote:

> Hey,
>
> I have observed a difference in opinion between two groups of people on
> gerrit, which unfortunately is causing bad blood on both sides. I'm
> therefore interested in hearing your opinion about the following scenario:
>
> Someone makes a sound commit. The commit has a clear commit message, though
> there is a single typo in it. Is it helpful to -1 the commit because of the
> typo?
>

This is a non issue in the very near future. Once we upgrade (testing
now, planning for *Very Soon* after eqiad migration), we'll have the
ability to edit commit messages and topics directly from the UI. I
think this will save people a lot of time downloading/amending changes
just to fix typos.

Personally, I think all typos should be fixed, since this becomes an
immutable part of the history once submitted. But hopefully this will
be much easier for people soon :)

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Antoine Musso-3
In reply to this post by Jeroen De Dauw-2
Le 15/01/13 12:44, Jeroen De Dauw wrote:
>
> I have observed a difference in opinion between two groups of people on
> gerrit, which unfortunately is causing bad blood on both sides. I'm
> therefore interested in hearing your opinion about the following scenario:
>
> Someone makes a sound commit. The commit has a clear commit message, though
> there is a single typo in it. Is it helpful to -1 the commit because of the
> typo?

Yup -1 anything that is wrong, even if it is the must trivial error ever
encountered.  We have a pre commit review workflow exactly for that.

If you feel brave enough, you could edit it yourself:
 - download the change
 - amend it
 - sent patchset back
 - leave a message (fixed typo)
 - removed yourself from the reviewer list
Done :-]


I wanted to have a spell checker to lint the commit message, but
eventually gave up because of the number of false positives.


--
Antoine "hashar" Musso


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Tyler Romeo
I agree with Antoine. Commit messages are part of the permanent history of
this project. From now until MediaWiki doesn't exist anymore, anybody can
come and look at the change history and the commit messages that go with
them. Now you might ask what the possibility is of somebody ever coming
across a single commit message that has a typo in it, but when you're using
git-blame, git-bisect, or other similar tools, it's very possible.

Also, a -1 is not a -2. It won't block the change from being merged; it's
just a notification that something needs to be fixed, however minor.

I'm still in favor of requiring every tag line to contain either (bug
> nnnnn) or
> (minor), so people are reminded that bugs should be filed and linked for
> anything that is not trivial. That's not what I want to discuss here - it
> just
> strikes me as much more relevant than typos, yet people don't seem to be
> too
> keen to enforce that.


I'm not so sure about *every* commit, but I definitely agree that this
needs to be enforced more. If you're fixing something or adding a new
feature, there should be a bug to go with it.

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [hidden email]


On Tue, Jan 15, 2013 at 8:37 AM, Antoine Musso <[hidden email]> wrote:

> Le 15/01/13 12:44, Jeroen De Dauw wrote:
> >
> > I have observed a difference in opinion between two groups of people on
> > gerrit, which unfortunately is causing bad blood on both sides. I'm
> > therefore interested in hearing your opinion about the following
> scenario:
> >
> > Someone makes a sound commit. The commit has a clear commit message,
> though
> > there is a single typo in it. Is it helpful to -1 the commit because of
> the
> > typo?
>
> Yup -1 anything that is wrong, even if it is the must trivial error ever
> encountered.  We have a pre commit review workflow exactly for that.
>
> If you feel brave enough, you could edit it yourself:
>  - download the change
>  - amend it
>  - sent patchset back
>  - leave a message (fixed typo)
>  - removed yourself from the reviewer list
> Done :-]
>
>
> I wanted to have a spell checker to lint the commit message, but
> eventually gave up because of the number of false positives.
>
>
> --
> Antoine "hashar" Musso
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Daniel Kinzler
On 15.01.2013 15:06, Tyler Romeo wrote:
> I agree with Antoine. Commit messages are part of the permanent history of
> this project. From now until MediaWiki doesn't exist anymore, anybody can
> come and look at the change history and the commit messages that go with
> them. Now you might ask what the possibility is of somebody ever coming
> across a single commit message that has a typo in it, but when you're using
> git-blame, git-bisect, or other similar tools, it's very possible.

And then they see a typo. So what? If you look through a mailing list archive or
Wikipedia edit comments, you will also see typos.

I'm much more concerned about scaring away new contributors with such nitpicking.

> I'm not so sure about *every* commit, but I definitely agree that this
> needs to be enforced more. If you're fixing something or adding a new
> feature, there should be a bug to go with it.

Every commit that is not trivial. This would be so much nicer if we had good
integration between bug tracker and review system :/

-- daniel


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Daniel Kinzler
In reply to this post by Chad
On 15.01.2013 13:39, Chad wrote:
> This is a non issue in the very near future. Once we upgrade (testing
> now, planning for *Very Soon* after eqiad migration), we'll have the
> ability to edit commit messages and topics directly from the UI. I
> think this will save people a lot of time downloading/amending changes
> just to fix typos.

Oh yes, please!

-- daniel


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

John Erling Blad
Its not that difficult to read through the text before you commit, right?
At least try to remove the most obvious spelling errors.

Perhaps I just find to much BS I should have given a -1 or even a -2
in some cases.

John

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

bawolff
In reply to this post by Daniel Kinzler
--
- Brian
Caution: The mass of this product contains the energy equivalent of 85
million tons of TNT per net ounce of weight.


On Tue, Jan 15, 2013 at 10:57 AM, Daniel Kinzler <[hidden email]> wrote:

> On 15.01.2013 15:06, Tyler Romeo wrote:
>> I agree with Antoine. Commit messages are part of the permanent history of
>> this project. From now until MediaWiki doesn't exist anymore, anybody can
>> come and look at the change history and the commit messages that go with
>> them. Now you might ask what the possibility is of somebody ever coming
>> across a single commit message that has a typo in it, but when you're using
>> git-blame, git-bisect, or other similar tools, it's very possible.
>
> And then they see a typo. So what? If you look through a mailing list archive or
> Wikipedia edit comments, you will also see typos.
>
> I'm much more concerned about scaring away new contributors with such nitpicking.

On the other hand, new users may be attracted to the fact that we have
high standards.

I agree that spelling is a valid reason for a -1. After all, -1 is not
the same as a revert in the svn days, it simply means that the commit
is not yet "perfect". (Even in svn a revert was supposed to be no big
deal).

-bawolff

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
OQ
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

OQ
On Tue, Jan 15, 2013 at 10:05 AM, bawolff <[hidden email]> wrote:
> On the other hand, new users may be attracted to the fact that we have
> high standards.
>
> I agree that spelling is a valid reason for a -1. After all, -1 is not
> the same as a revert in the svn days, it simply means that the commit
> is not yet "perfect". (Even in svn a revert was supposed to be no big
> deal).
>

I would disagree, I think most developers will look for community
first. While yes, some wont care that it's full of nitpicky pedants, I
think that would turn off more potential developers then would help.
Extending this logic, nobody would commit to the Linux kernel tree
since it has had fuck and shit committed in revisions. What type of
standards is that?

I would agree with Daniel above that if it's in a non-critical part of
the commit message, if it bothers you that much, then follow it up
yourself.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Tim Landscheidt
In reply to this post by Daniel Kinzler
Daniel Kinzler <[hidden email]> wrote:

>> In my opinion, if the typo is trivial (f.e. someone typed "fo" instead of "of"),
>> there is no need to -1 the commit, however if the typo pertains to a crucial
>> element of the commit (f.e. someone typed "fixed wkidata bug") perhaps it
>> should, since otherwise people who search through commit messages won't be able
>> to find commits that contain word "wikidata".

> Ok, full text search might be an argument in some cases (does that even work on
> gerrit?).

It works in Git, for example with "git log --grep".  I do
think that fixing typos should be preferred to preserving
typos for eternity, and -1 is better than nothing, but up-
loading a new changeset is how it should be done.

> But in that regard, wouldn't it be much more important to enforce (bug 12345)
> links to bugzilla by giving a -1 to commits that don't have them (though they
> clearly have, or should have, a bug report?)

> I'm still in favor of requiring every tag line to contain either (bug nnnnn) or
> (minor), so people are reminded that bugs should be filed and linked for
> anything that is not trivial. That's not what I want to discuss here - it just
> strikes me as much more relevant than typos, yet people don't seem to be too
> keen to enforce that.

I cannot follow that line of thought at all.  The "tag line"
is rather short and should give the reader a summary of what
the commit is about when browsing through a list of commits.
Reserving part of that for a bug number would only be useful
if the reader could associate the underlying issue by the
number, but apart from bug #1 and a few (other) tracking
bugs noone will be able to do so, and those bugs will (un-
fortunately) never be closed.

Is there another software project that uses the summary line
in a similar way to MediaWiki?

Tim


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Chad
On Tue, Jan 15, 2013 at 11:44 AM, Tim Landscheidt
<[hidden email]> wrote:

> Daniel Kinzler <[hidden email]> wrote:
>
>>> In my opinion, if the typo is trivial (f.e. someone typed "fo" instead of "of"),
>>> there is no need to -1 the commit, however if the typo pertains to a crucial
>>> element of the commit (f.e. someone typed "fixed wkidata bug") perhaps it
>>> should, since otherwise people who search through commit messages won't be able
>>> to find commits that contain word "wikidata".
>
>> Ok, full text search might be an argument in some cases (does that even work on
>> gerrit?).
>
> It works in Git, for example with "git log --grep".  I do
> think that fixing typos should be preferred to preserving
> typos for eternity, and -1 is better than nothing, but up-
> loading a new changeset is how it should be done.
>
>> But in that regard, wouldn't it be much more important to enforce (bug 12345)
>> links to bugzilla by giving a -1 to commits that don't have them (though they
>> clearly have, or should have, a bug report?)
>
>> I'm still in favor of requiring every tag line to contain either (bug nnnnn) or
>> (minor), so people are reminded that bugs should be filed and linked for
>> anything that is not trivial. That's not what I want to discuss here - it just
>> strikes me as much more relevant than typos, yet people don't seem to be too
>> keen to enforce that.
>
> I cannot follow that line of thought at all.  The "tag line"
> is rather short and should give the reader a summary of what
> the commit is about when browsing through a list of commits.
> Reserving part of that for a bug number would only be useful
> if the reader could associate the underlying issue by the
> number, but apart from bug #1 and a few (other) tracking
> bugs noone will be able to do so, and those bugs will (un-
> fortunately) never be closed.
>
> Is there another software project that uses the summary line
> in a similar way to MediaWiki?
>

Really, we should be using them in the footer so gerrit can track them.

Eg:

===
Some awesome new feature

Blah blah blah
I did stuff
Fixed this too.

Bug: 1234
Change-Id: I....
===

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Platonides
In reply to this post by OQ
Well, I would prefer to get a notice that I made a typo than having that
embarrassing typo in the commit log forever. That's the point of using a
gating system, right? :)

So yes, I do think they should be corrected. (And I have committed typos
in both commit messages and inside files, just as anyone else)


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Tim Starling-2
In reply to this post by Daniel Kinzler
On 16/01/13 01:57, Daniel Kinzler wrote:

> On 15.01.2013 15:06, Tyler Romeo wrote:
>> I agree with Antoine. Commit messages are part of the permanent history of
>> this project. From now until MediaWiki doesn't exist anymore, anybody can
>> come and look at the change history and the commit messages that go with
>> them. Now you might ask what the possibility is of somebody ever coming
>> across a single commit message that has a typo in it, but when you're using
>> git-blame, git-bisect, or other similar tools, it's very possible.
>
> And then they see a typo. So what? If you look through a mailing list archive or
> Wikipedia edit comments, you will also see typos.
>
> I'm much more concerned about scaring away new contributors with such nitpicking.

I am also concerned about demotivating people.

Giving a change -1 means that you are asking the developer to take
orders from you, under threat of having their work ignored forever. A
-1 status can cause a change to be ignored by other reviewers,
regardless of its merit.

If the developer can't lower their sense of pride sufficiently to
allow them to engage with nitpickers, then the change might be ignored
by all concerned for many months.

However, if you give minor negative feedback with +0, the change stays
bold in your "review requests" list, as if you haven't reviewed it at
all. I've tried giving -1 with a comment to the effect of "please
merge this immediately regardless of my nitpicking above", but IIRC
the comment was ignored.

I think people who give -1 should be aware of the potential roadblock
they are creating. And I would like to see a feature in Gerrit to
unbold +0 reviews.

Under Subversion, my policy as a reviewer was to never ask the
committer to fix a typo in a comment, since committing the fix myself
was easier than telling them what to fix, and doing so avoided
offence. Under Gerrit, it's more difficult to submit amendments, and I
hate multi-author patchsets anyway, so negative feedback seems more
attractive.

Maybe the answer is better scripting for amendments and dependent commits.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Matthew Flaschen-2
In reply to this post by Nikola Smolenski-2
On 01/15/2013 06:58 AM, Nikola Smolenski wrote:
> In my opinion, if the typo is trivial (f.e. someone typed "fo" instead
> of "of"), there is no need to -1 the commit, however if the typo
> pertains to a crucial element of the commit (f.e. someone typed "fixed
> wkidata bug") perhaps it should, since otherwise people who search
> through commit messages won't be able to find commits that contain word
> "wikidata".

I agree. Well said.  A minor mistake like that that doesn't affect
grepping isn't worth a -1, since it doesn't affect the readability of
the code itself.

Matt Flaschen

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Tei-2
Japanese RPG games does something interesting. When you get a quest
like  "Go to the house of MrTom and pick the toothnail"  the words
MrTom and toothnail are bolded. Something in the system (maybe is done
manually wen the quest text is written) acknowledge entities in the
system ( NPC characters, locations, items) and bold it, so is easier
for the player to tell the important parts of the quest without really
reading it full trough it.

Computer geeks use to do this using the * character.  "fixed wikidata
bug by reversing the *polarity*".  This type of ascii syntax is what
started the wikisyntax.

It could be interesting (but I have no idea if is feasible), if git
recognize automatically elements in a commit text, and colorize it on
the terminal screen (or maybe bold it if the screen renders using
truetype fonts).  This way, if you have written wikidata many times,
you will quickly spot a problem if the commit renders to you with
"fixed wkidata bug by reversing the polarity"  and wikidata is not
bolded/colored different. A alternate would be for this
script/program, to extract keywords and present to you, so if you
notice the commit lack the label "wikidata", theres something wrong.

Many times people don't read what are writing, only when are given
back what have write notice that theres something wrong in it.  Many
Internet forums recognize this by allowing people to edit / fix post
in the first 5 minutes.
Anyway half the battle is making so people care about this,so put a
bit of effort into writing without many spell errors.  Perhaps is
harder if you have people from different cultures, and you have
developers that are not english natives.

If people not care, will always make this type of mistakes, and if the
mistakes change keywords like wikidata or function names, it may make
commits harder to search for keywords. It is true this thing is so
minor its not even worth a thread on the mail list. I am posting this
here, because is a fun problem.

--- The Swedish Chef

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Sébastien Santoro
In reply to this post by Tim Starling-2
On Wed, Jan 16, 2013 at 7:09 AM, Tim Starling <[hidden email]> wrote:
> I am also concerned about demotivating people.
The motivation factor works with the two positions.

I felt a little demotivated after having read all these "we don't care
about typos" positions at the start of the thread and felt really
relieved to read this is not the consensus opinion.

Especially, as, in September and October, when I weren't at ease with
my -1 typo reviews, I mailed four people I reviewed their change such
a way to ask them what they prefer: a -1 review or a new patchset
fixing the typo directly (I weren't at ease with the idea to resubmit
a patchset without prior author consent either). Three of them didn't
bother to answer me at all (for the anecdote, the 4th preferred a -1
review). So we quit the realm of "the workflow and the UI don't allow
easy correction" to enter into the realm of "we don't care".

On a side matter, typos could be a symptom of another issue: how
important a commit message is? Should it be a formality to expedite in
30 seconds or an informative valuable text describing the change,
crafted with care and proofread before submission or merge? What's the
goal of a commit message as a changelog, communication tool and change
documentation value?

At the end, the direct commit message edit in the UI will offer an
acceptable solution: corrections will be more trivial than found again
my branch, amend the commit, resubmit as a new patchset. Meanwhile, we
can suffer the last weeks of extra work for review spelling (as 0 or
-1) purpose pending the Gerrit migration.

And if you don't want to fix yourselves your commit, please create a
list stating so on mediawiki.org, that will be a clear message for the
code reviewers: "If you see a typo, would you be so kind as to fix it
yourself and submit a new patchset?".

--
Best Regards,
Sébastien Santoro aka Dereckson
http://www.dereckson.be/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The ultimate bikeshed: typos in commit messages

Chad
On Wed, Jan 16, 2013 at 8:06 AM, Sébastien Santoro
<[hidden email]> wrote:
> At the end, the direct commit message edit in the UI will offer an
> acceptable solution: corrections will be more trivial than found again
> my branch, amend the commit, resubmit as a new patchset. Meanwhile, we
> can suffer the last weeks of extra work for review spelling (as 0 or
> -1) purpose pending the Gerrit migration.
>

And really, this is just a few weeks out. I've been testing the upgrade,
and I'm confident we won't see any real problems. I'm planning to do
it as soon as the eqiad migration is complete next week.

> And if you don't want to fix yourselves your commit, please create a
> list stating so on mediawiki.org, that will be a clear message for the
> code reviewers: "If you see a typo, would you be so kind as to fix it
> yourself and submit a new patchset?".
>

Please no. We really don't want to encourage people to be lazy
because they think people will clean up after them.

Really, I think the whole thread is moot with the pending upgrade.
Typos should always be fixed before merging (I think we all agree?),
and the new abilities to fix these from the UI means we won't need
to mark people as -1 to do so.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123