lists at nadir-seen-fire
Aug 1, 2012, 6:08 PM
Post #13 of 18
(1243 views)
Permalink
|
Expanding it might be a good idea. Though you should probably rethink the
tool and do things differently.
When you wrote that we discussed Git's built in `git archive` which can
create a tarball of an arbitrary repo.
But besides that what we didn't think of was Gitweb. Which already has
snapshot capabilities.
The hourly snapshot tool doesn't really serve much purpose:
- Gitweb HEAD snapshots are always completely up to date while the
snapshot lags by an hour
- Gitweb can give snapshots of every branch in the repo so the hourly
snapshot doesn't add anything there
- Gitweb can give snapshots of every repo instead of just core. So we
already essentially have snapshots of extensions built into Gitweb while
the hourly tool only does core.
- Gitweb can make a snapshot of any commit, not just the latest commit
So the only thing that a tool really has to offer is a clean UI and some
information like the checksum.
Those are probably what we should focus on.
- Drop the notion of hourly snapshots; Either use Gitweb snapshot links
directly or package snapshots dynamically when a new one is requested.
- Support getting snapshots from old commits in the repo.
- Consider expanding the tool to support other repos.
Because this will basically be a UI we shouldn't be half-hearted about the
UI. The tool is pointless if we don't go all the way.
Don't leave 'Branches' out in the open like that. This is a user tool
rather than a Git tool.
So instead of listing things like "master" and "REL1_19" use a mapping to
give them proper labels like "Development" or "Alpha" and "MediaWiki
1.19.x".
Also cleanly group things together. ie: Take all the REL#_## branches and
put them in a "Release snapshots" group. wmf/ in "WMF branch snapshots".
And things like Wikidata and iwtransclusion in a "Experimental project
snapshots" group.
Also drop the select field and instead make it a list of links that users
can actually see.
I wonder if we should turn this into a special page on MW.org.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Wed, 01 Aug 2012 17:06:08 -0700, Krinkle <krinklemail [at] gmail> wrote:
> We already have hourly snapshots of the stable master though:
>
> https://toolserver.org/~krinkle/mwSnapshots/#!/mediawiki-core/master
>
> (and it includes release branches, feature branches and wmf branches).
>
> That could be expanded to keep old version (right now it only keeps the
> latest one).
>
> -- KJrinkle
>
> On Wed, Aug 1, 2012 at 12:29 PM, Mark A. Hershberger
> <mah [at] everybody>wrote:
>
>> Is there any interest in having nightly snapshots of MediaWiki
>> available?
>>
>> I realize people could just use git, but this poses a problem for users
>> who are familiar with extracting, say, a .xip file, and making MediaWiki
>> work, but are stymied by the esoteric nature of git.
>>
>> This would be similar to Mozilla's nightlies:
>> (http://nightly.mozilla.org/) and may also be a stepping stone for
>> people to get into development, or at least patch submission.
>>
>> This all came up because I had the chance to provide a snapshot to help
>> solve a problem in 1.19
>> (http://thread.gmane.org/gmane.org.wikimedia.mediawiki/40011, shortened:
>> http://hexm.de/kt).
>>
>> I used the make-release script
>> (http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/make-release/,
>> shortened: http://hexm.de/ku) and put the snapshot up at
>> http://mah.everybody.org/snapshots/.
>>
>> I'm willing to set this up to run on wmflabs.org or on my own server if
>> there is interest. This may also be a good way to measure the "need"
>> for a point release -- for example, if the nightly starts including
>> fixes for annoying bugs that affect a lot of people, then a point
>> release is probably needed. (I'm looking at you, Bug #24985.)
>>
>> --
>> http://hexmode.com/
>>
>> Human evil is not a problem. It is a mystery. It cannot be solved.
>> -- When Atheism Becomes Religion, Chris Hedges
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
