Last modified: 2014-02-02 19:04:11 UTC
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.
Maybe like this https://gerrit.wikimedia.org/r/#/c/16904/
Patch is there No Review since 7 Weeks WONTFIX!?
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.
@DaSch: 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...)
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.
Somebody else could still give this a try - reopening.
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.
*** Bug 43354 has been marked as a duplicate of this bug. ***
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?
There was a patch There was a gerrit commit But nobody took care of approving So I think nobody really is interested in this
André, a patch is there: https://gerrit.wikimedia.org/r/#/c/16904/
Ah thanks! Adding "patch-in-gerrit" keyword...
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.
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!
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!
Hi DaSch, have you checked https://www.mediawiki.org/wiki/Git/Workflow#How_to_comment_on.2C_review.2C_and_merge_code_in_Eclipse
(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 IRC or wikitech-l mailing list. https://www.mediawiki.org/wiki/Communication Thank you for your interest in improving MediaWiki software!
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 bet on nobody picking it up!
I am working on that now, rebased and made it working (with core / master ). see screenshot http://i.imgur.com/d9VC08W.png https://gerrit.wikimedia.org/r/#/c/54902/
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://integration.wikimedia.org/ci/job/mediawiki-core-merge/9485/console : SUCCESS - https://integration.wikimedia.org/ci/job/mediawiki-core-whitespaces/3096/console : SUCCESS (non-voting) - https://integration.wikimedia.org/ci/job/mediawiki-core-phpcs-HEAD/5573/console : FAILURE (non-voting) - https://integration.wikimedia.org/ci/job/mediawiki-core-jslint/4360/checkstyleResult/ : SUCCESS - https://integration.wikimedia.org/ci/job/mediawiki-core-lint/11333/console : SUCCESS [by jenkins-bot]
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 - https://integration.wikimedia.org/ci/job/mediawiki-core-merge/9486/console : SUCCESS - https://integration.wikimedia.org/ci/job/mediawiki-core-whitespaces/3097/console : SUCCESS (non-voting) - https://integration.wikimedia.org/ci/job/mediawiki-core-phpcs-HEAD/5574/console : FAILURE (non-voting) - https://integration.wikimedia.org/ci/job/mediawiki-core-jslint/4361/checkstyleResult/ : SUCCESS - https://integration.wikimedia.org/ci/job/mediawiki-core-lint/11334/console : SUCCESS [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/54902 (Gerrit Patch-Set: Ia31a747c0d79f460503f66c369a0d1f2b971b692/7)
(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://integration.wikimedia.org/ci/job/mediawiki-core-merge/9488/console : SUCCESS - https://integration.wikimedia.org/ci/job/mediawiki-core-whitespaces/3099/console : SUCCESS (non-voting) - https://integration.wikimedia.org/ci/job/mediawiki-core-phpcs-HEAD/5576/console : FAILURE (non-voting) - https://integration.wikimedia.org/ci/job/mediawiki-core-jslint/4364/checkstyleResult/ : SUCCESS - https://integration.wikimedia.org/ci/job/mediawiki-core-lint/11337/console : SUCCESS [by jenkins-bot]
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 *** I hereby withdraw (abandon) that patch set, because it indeed does not work as intended, Well, it shows a date, but not necessarily the commit date, or edit date. *** 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)
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 > Skript > > git 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 > Skript > > git 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?
T. Gries: Why did you bomp the Target Milestone from 1.21 to 1.22?
(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 !
Of course - 1.21 is not even released, so release notes are work in progress. :)
(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.
committed with https://gerrit.wikimedia.org/r/#/c/54986/
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
This is indeed a good idea. I opened a new feature request on bug 48418.
