(anonymous) wrote:
[...]
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
===
This should be Fixes-Bug: or something similar (I'll leave
it to the native
I would advise against doing anything with the word Fix in it, because a
commit does not necessarily fix a bug. It's possible that a fix for a bug
spans multiple commits, depending on the scope of the bug. When you do just
Bug, all it implies is that you can see that bug report for related
Tyler Romeo tylerro...@gmail.com wrote:
I would advise against doing anything with the word Fix in it, because a
commit does not necessarily fix a bug. It's possible that a fix for a bug
spans multiple commits, depending on the scope of the bug. When you do just
Bug, all it implies is that
That's my point. You wouldn't use Fixes: 123 if it doesn't actually fix
bug 123. However, what if there's a case like I said, where a bug is fixed
across multiple commits. If you're using the Fixes tag, then technically
you should only be tagging the last commit that finally fixes the bug, in
On Wed, Jan 23, 2013 at 1:17 PM, Tyler Romeo tylerro...@gmail.com wrote:
My reasoning has to do with the motivation behind why we tag commits. Maybe
I'm wrong, but the reason we tag commits with bug numbers is so that, in
the future, if one wants to find the commit(s) that fixed a certain bug,
Tyler Romeo tylerro...@gmail.com wrote:
That's my point. You wouldn't use Fixes: 123 if it doesn't actually fix
bug 123. However, what if there's a case like I said, where a bug is fixed
across multiple commits. If you're using the Fixes tag, then technically
you should only be tagging the
IMHO the primary motivation for using Fixes: 123 (or
Relates-To: 123) is to absolve the committer from te-
diously going back to the Bugzilla page and adding a Gerrit
link and (in the former case) the merger from marking the
bug as resolved as computers are so *much* better at that
(and
Tyler Romeo tylerro...@gmail.com wrote:
IMHO the primary motivation for using Fixes: 123 (or
Relates-To: 123) is to absolve the committer from te-
diously going back to the Bugzilla page and adding a Gerrit
link and (in the former case) the merger from marking the
bug as resolved as
Hey,
Thanks to all for voicing your opinions.
My observations:
* The community is split on this topic
* Both camps have people that strongly defend their respective views
* The above two points are unlikely to change
* People are getting upset due to -1 for things that are by some considered
Hey,
Thanks to all for voicing your opinions.
My observations:
* The community is split on this topic
* Both camps have people that strongly defend their respective views
* The above two points are unlikely to change
* People are getting upset due to -1 for things that are by some
On 01/19/2013 08:49 AM, Jeroen De Dauw wrote:
Hey,
Thanks to all for voicing your opinions.
My observations:
* The community is split on this topic
* Both camps have people that strongly defend their respective views
* The above two points are unlikely to change
* People are getting
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,
On Wed, Jan 16, 2013 at 7:09 AM, Tim Starling tstarl...@wikimedia.org 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
On Wed, Jan 16, 2013 at 8:06 AM, Sébastien Santoro
dereck...@espace-win.org 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
Thanks Tim for pitching in.
On 16.01.2013 07:09, Tim Starling wrote:
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.
Le 16/01/13 14:06, Sébastien Santoro a écrit :
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?
To me the commit summary introduce the patch to the reviewers and should
also
- Original Message -
From: . oscar.vi...@gmail.com
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
This is a ridiculous conversation and I can't believe it now spans +20 messages.
___Don't___ -1 a patchset for a typo. The result of that is far more
catastrophic. We put off volunteers and people end up wasting valuable
time doing rebases due to the time taken to find another code review.
Code
Op 15-1-2013 12:44, Jeroen De Dauw schreef:
bla
IMHO all commit messages should be green.
Maarten
*hides*
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jan 16, 2013 at 7:26 PM, Jon Robson jdlrob...@gmail.com wrote:
This is a ridiculous conversation and I can't believe it now spans +20
messages.
Apparently you don't care, but other people do care. Please do not
disregard other people's opinions because you believe yours is correct.
To
I don't mind getting dinged for typos. If I'm being sloppy it's fair to
point it out.
However, I think the social contract should be that after I fix the typos
you requested then you owe me a real code review where you look at the
merits of the code. Code review is an awesomely useful but time
On 2013-01-16 3:07 PM, Luke Welling WMF lwell...@wikimedia.org wrote:
I don't mind getting dinged for typos. If I'm being sloppy it's fair to
point it out.
However, I think the social contract should be that after I fix the typos
you requested then you owe me a real code review where you
On 17/01/13 00:14, Chad wrote:
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.
I didn't mention commit
On Wed, Jan 16, 2013 at 6:07 PM, Tim Starling tstarl...@wikimedia.org wrote:
On 17/01/13 00:14, Chad wrote:
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
On 2013-01-16 7:20 PM, Chad innocentkil...@gmail.com wrote:
On Wed, Jan 16, 2013 at 6:07 PM, Tim Starling tstarl...@wikimedia.org
wrote:
On 17/01/13 00:14, Chad wrote:
Really, I think the whole thread is moot with the pending upgrade.
Typos should always be fixed before merging (I think we
If we're talking nitpicks in general. Ive seen -1 for things like
someFunc($a, $b) instead of someFunc( $a, $b ) which I agree does more harm
than good.
I disagree. The entire purpose of code review is to make sure the code is
organized and styled properly. If code isn't written in
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
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
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
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
On Tue, Jan 15, 2013 at 6:44 AM, Jeroen De Dauw jeroended...@gmail.com 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
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
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
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
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
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
--
- 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 dan...@brightbyte.de wrote:
On 15.01.2013 15:06, Tyler Romeo wrote:
I agree with Antoine. Commit messages are part of
On Tue, Jan 15, 2013 at 10:05 AM, bawolff bawolff...@gmail.com 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
Daniel Kinzler dan...@brightbyte.de 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
On Tue, Jan 15, 2013 at 11:44 AM, Tim Landscheidt
t...@tim-landscheidt.de wrote:
Daniel Kinzler dan...@brightbyte.de 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
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
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
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
43 matches
Mail list logo
