Author: dasch
Description:
It would be nice, if the date of the last commit of the extension shown on Special:Version could be displayed.
With SVN I could look at the revision number, to check if I have to look for updates. With git this doesn't work. So it would be helpful to see how long an Extension was not updated.
Version: 1.21.x
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T49261 Wrong path to git? | |||
| Resolved | None | T50418 api.php?action=query&meta=siteinfo&siprop=extensions should print extension last commit information | |||
| Declined | Wikinaut | T49264 Special:Version: show timestamps of last _local_ git transactions for core and extensions | |||
| Open | Feature | None | T49265 Option to disable showing dates of git commits in Special:Version | ||
| Resolved | Krenair | T55335 Error trying to access Special:Version on beta labs, as it tries to get the HEAD commit date for each extension | |||
| Resolved | Krinkle | T53360 Special:Version with exts in git is too slow, needs caching or using something other than git show | |||
| Resolved | None | T41655 Scribunto should expose a version and Lua version on Special:Version | |||
| Resolved | None | T40783 Add git commit date for core and extensions to Special:Version |
A new patch, Ib66be27a, is still under review. There doesn't seem to be any fundamental reason not to do this, the patch just needs some tweaking (apparently,y the date format isn't localized or something).
I for one would live to see this implemented.
taste1at wrote:
You write
date("d.m.Y H:i",$rawdate);
This is a german date format.
The localized date format is available using
$wgLang->date( ) and $wgLang->time( )
and others, where $wgLang is a global variable storing an instance of the Language class (can be found in /language/Language.php).
Btw, I suggest not to do the formatting in the GitInfo class. This class should return a MediaWiki-timestamp obtained by
date( 'YmdHis', $lastlinearray[4] );
In the class SpecialVersion, you can use $wgLang for formatting. (I'm not sure if the global variable is still to be used but in SpecialVersion lots of them are still around...)
dasch wrote:
Okay, I'm out. That's to complicated for me. Gerrit also does not move. I close this, seams I have to live without this.
Could you use YYYY-MM-DD ISO 8601 format instead?
This will help a lot to avoid misunderstanding with a unique date format during debug.
In the bug 43354, we wanted the Special:Version format:
Method | Git revision and date | Description | Authors
Example of the 4 columns content:
ParserFunctions (Version 1.4.1)
(8d2534b)
2012-12-22
Enhance parser with logical functions
Tim Starling, Robert Rohde, Ross McClure and Juraj Simlovic
As explained in comment 7, I strongly insist for a ISO 8601 date. This is a vital debug information, not something to localize, especially with a risk of day/month confusion.
Is someone working on that? I really wish to see the ISO-8601 commit _dates_ close to the version hashes.
It seems this should be done in two ways:
(1) ExtensionDistributor. Add a an information file with hash and date.
To get the date:
git show --format="%ci" HEAD | head -n1 | cut -f1 -d ' '
To get the hash (if this is needed, I think the case is well covered by our current class):
git rev-parse HEAD
(2) If this file is absent and a .git folder is present. The extension has probabably been fetched by a git clone repository. Test we can execute git on the system and get the date.
[Please don't reset the version field to "unspecified".]
Tom: Do you plan to work on this, or why did you set the Target Milestone?
dasch wrote:
There was a patch
There was a gerrit commit
But nobody took care of approving
So I think nobody really is interested in this
https://gerrit.wikimedia.org/r/#/c/17333/ is the latest version of the patch which was abandoned.
(In reply to comment #13)
There was a patch
There was a gerrit commit
But nobody took care of approving
So I think nobody really is interested in this
As I said to you end December, T. Gries and me are interested in this.
As I indicated in the Ib66be27a review in December, I've tested your patch and it doesn't work as intended.
First, the logs/HEAD file contains other operations than commits. There would have been a need to filter to only process "commit" lines.
But there is a bigger issue: the patch currently reads the .git/logs/HEAD file. This won't always contain the information we want.
It contains the operation you did to the git repository (e.g. clone, checkout).
It will only contain the date of the last commit when committed locally.
dasch wrote:
4 month after the commit and some days after I said that I'm out of this
by the way I'm not going to ever commit anything to gerrit because this is way to complicated to me and I have no idea of how it works
(In reply to comment #18)
4 month after the commit and some days after I said that I'm out of this
by the way I'm not going to ever commit anything to gerrit because this is
way to complicated to me and I have no idea of how it works
DaSch:
When was the last time you took a look at Gerrit and its documentation at http://www.mediawiki.org/wiki/Gerrit ? Could you elaborate on what's complicated? Your feedback is very welcome to make things easier for you to contribute. Thank you in advance!
dasch wrote:
The documentation is for working with command line and I'm working with Eclipse, Aptana and Egit. So the Documentation is worthless and the functions and workflows described there are not available there!
(pressed Save Changes too soon, sorry)
PS: learning how to deal properly with git and code review from your IDE is useful not only for MediaWiki development but also for many other software projects. The first time might be annoying but after that going through the process is trivial.
If you still want to give it a go there is always people happy to help at MediaWiki-General IRC or wikitech-l mailing list.
https://www.mediawiki.org/wiki/Communication
Thank you for your interest in improving MediaWiki software!
dasch wrote:
I make my extensions simple and my own way at github and mediawiki is the only project I contribute a little bit and that's only a bit hacking and Copy Paste Programming because I don't have any experience with PHP only because I have to do it in PHP for mediawiki because I hate PHP.
Note: As this has the 1.21.0 target milestone set (by Nemo), somebody would have to pick up the patch and rework it. If this does not happen in the next weeks, the Target Milestone will get removed.
I am working on that now, rebased and made it working (with core / master ).
see screenshot http://i.imgur.com/d9VC08W.png
A screenshot of Special:Version page with this patch is available http://i.imgur.com/d9VC08W.png
and is deployed to
http://openid-wiki.instance-proxy.wmflabs.org/wiki/Special:Version
where it can be seen in action.
Related URL: https://gerrit.wikimedia.org/r/54902 (Gerrit Patch-Set: Ia31a747c0d79f460503f66c369a0d1f2b971b692/5)
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Reviewed:+1 Patch Set 5: Code-Review+1 [by Wikinaut]
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Patch Set 5:
A screenshot of Special:Version page with this patch is available http://i.imgur.com/d9VC08W.png
and is deployed to http://openid-wiki.instance-proxy.wmflabs.org/wiki/Special:Version
where it can be seen in action. [by Wikinaut]
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Reviewed:-1 Patch Set 5: Code-Review-1
(1 comment) [by Catrope]
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Verified:+1 Patch Set 5: Verified+1
Build successful
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Patch Set 5:
(1 comment)
@DaSch: Catrope asked, why you removed return self::getwgVersionLinked() . " $shortSHA1";
Can you explain ?
I also set to -1 because I want again to check the dates. [by Wikinaut]
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Reviewed:-1 Patch Set 5: Code-Review-1 [by Wikinaut]
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Patch Set 5:
(1 comment) [by Wikinaut]
Related URL: https://gerrit.wikimedia.org/r/54902 (Gerrit Patch-Set: Ia31a747c0d79f460503f66c369a0d1f2b971b692/6)
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Verified:+1 Patch Set 6: Verified+1
Build successful
Related URL: https://gerrit.wikimedia.org/r/54902 (Gerrit Patch-Set: Ia31a747c0d79f460503f66c369a0d1f2b971b692/7)
dasch wrote:
(In reply to comment #33)
https://gerrit.wikimedia.org/r/54902 (Gerrit Change
Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Patch Set 5:(1 comment)
@DaSch: Catrope asked, why you removed return self::getwgVersionLinked() . "
$shortSHA1";Can you explain ?
I also set to -1 because I want again to check the dates. [by Wikinaut]
That's not from my patch!
It can't be found here
https://gerrit.wikimedia.org/r/#/c/16904/
nor here
https://gerrit.wikimedia.org/r/#/c/17333/
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Verified:+1 Patch Set 7: Verified+1
Build successful
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Reviewed:-1 Patch Set 7: Code-Review-1
The following comment by Dereckson is important:
https://bugzilla.wikimedia.org/show_bug.cgi?id=38783#c17
Dereckson wrote:
As I indicated in the Ib66be27a review in December, I've tested your patch and
it doesn't work as intended.
First, the logs/HEAD file contains other operations than commits. There would
have been a need to filter to only process "commit" lines.
But there is a bigger issue: the patch currently reads the .git/logs/HEAD file.
This won't always contain the information we want.
It contains the operation you did to the git repository (e.g. clone, checkout).
It will only contain the date of the last commit when committed locally. [by Wikinaut]
https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | change ABANDONED [by Wikinaut]
Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/1)
Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/2)
Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/3)
dasch wrote:
what Dereckson want's is only possible by connecting to remote within the PHP Skript
git information in .git only have local changes.
The information from logs/HEAD contains the last git operation. And that is exactly what is needed. But only there I see how long I didn't check for an update. Because when I take the date from the commit I always think that I have to pull for new updates just because there where no changes for a long time!
(In reply to comment #46)
what Dereckson want's is only possible by connecting to remote within the PHP
Skriptgit information in .git only have local changes.
I think, you are right -- this is, what I also think is needed (fetching the dates from the remote).
So in summary, the present solution is the best possible local solution.
Url will be added, when the (draft) patch is published.
The information from logs/HEAD contains the last git operation. And that is
exactly what is needed. But only there I see how long I didn't check for an
update. Because when I take the date from the commit I always think that I
have
to pull for new updates just because there where no changes for a long time!
Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/4)
Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/5)
Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/6)
Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/7)
Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/8)
Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/9)
(In reply to comment #46)
what Dereckson want's is only possible by connecting to remote within the PHP
Skriptgit information in .git only have local changes.
Commit dates are stored as part of the commit objects, so they are available locally. However, commit objects can be (and often are) part of packfiles, so reading them is not easy (unless of course you shell out to git).
A working version is now available in
https://gerrit.wikimedia.org/r/#/c/54986/
Screenshot http://i.imgur.com/z3RvMiB.png shows, how the Special:Version page looks when the patch is applied.
It has to * shell out * and makes use of the "git show" command to let git do the work to fetch and format author and commit dates. Any other solution is PITA, I investigated different alternatives and all of them are even worse.
(In reply to comment #7)
Could you use YYYY-MM-DD ISO 8601 format instead?
This will help a lot to avoid misunderstanding with a unique date format
during
debug.
(In reply to comment #9)
As explained in comment 7, I strongly insist for a ISO 8601 date. This is a
vital debug information, not something to localize, especially with a risk of
day/month confusion.
We localize dates everywhere by the user's preference. RC, contribs, histories, etc... even our old code review system uses localized dates.
Dates are localized according to the user's choice, they should know how to read it. In fact none of the date preference options we give are ambiguous. And if YOU don't like seeing localized dates you can set your preferences to show ISO dates.
Is there any real reason not to localize the date as our standard is?
(In reply to comment #56)
(In reply to comment #7)
Dates are localized according to the user's choice, they should know how to
read it. In fact none of the date preference options we give are ambiguous.
And
if YOU don't like seeing localized dates you can set your preferences to show
ISO dates.Is there any real reason not to localize the date as our standard is?
Daniel, please simply change the two lines in SpecialVersion.php as you like to have it --- I want to finish this story, successfully and soon. Pls.
patch available https://gerrit.wikimedia.org/r/#/c/54986/ . pls. can someone review and commit?
(In reply to comment #59)
T. Gries: Why did you bomp the Target Milestone from 1.21 to 1.22?
André: because I thought that the 1.21 train was already gone... (reset to 1.21 milestone). Perhaps you can help to get this in, thanks.
(In reply to comment #59)
T. Gries: Why did you bomp the Target Milestone from 1.21 to 1.22?
@André:
because this bug is - apparently currently - not part of https://www.mediawiki.org/wiki/Release_notes/1.21 !
(In reply to comment #62)
Of course - 1.21 is not even released, so release notes are work in progress.
:)
ok,. did not know, and added it now https://www.mediawiki.org/w/index.php?title=Release_notes%2F1.21&diff=671485&oldid=667144
T. Gries: Errm, but the patch is not merged, so it's NOT part of 1.21 yet, and IMO it should not be part of the release notes yet either.
(In reply to comment #64)
T. Gries: Errm, but the patch is not merged, so it's NOT part of 1.21 yet,
and
IMO it should not be part of the release notes yet either.
merge it
current code is live on http://openid-wiki.instance-proxy.wmflabs.org/wiki/Special:Version
@PleaseStand: See your comment to patch set 31 https://gerrit.wikimedia.org/r/#/c/54986/31/includes/GitInfo.php in Line 131
The present commit implements your proposal to have $wgGitBin as DefaultSetting parameter, which prevents multiple exec failures in Special:Versions when this command is not available. Thanks for pointing me to this.
I realize this commit has already been merged in, but it would be really nice if this information were also exposed in the API call for extensions
api.php?action=query&meta=siteinfo&siprop=extensions