Re: [Wp-mirror-list] en.wikipedia image sizes and templates

[wp mirror]

Dear Jason,

Thank you very much. I think your suggestion (option two) is sound. It
solves several problems at once.

1) Packaging

I will want to think carefully about package naming to avoid collision
with the LTS version currently maintained by Debian. Perhaps
`mediawiki-latest,' `mediawiki-latest-extention-scribunto,' and so on
would work well.

The actual mechanics of packaging are not too involved:  clone the GIT
repository, find the appropriate HEAD, dh_make, and so forth.  I
expect the process to be similar to packaging `mediawiki-mwxml2sql'
earlier this year. The folks at WMF are most helpful.

2) Repository

This step will be new to me.  Several tools are described by Debian
<https://wiki.debian.org/HowToSetupADebianRepository>.
My initial impression is that `reprepro' will get the job done.

3) Hosting

I will inquire to see if WMF could host the repository.

Developers.  Perhaps this should be a shell account to which
developers would be given credentials.  Of course, the account would
have to have `git,' `reprepro,' and other utilities so that the
repository could be built and maintained there.

Users.  Package users would have be able to find the repository via HTTP or FTP.

Sincerely Yours,
Kent

>> 7) Planning for wp-mirror 0.7
>>
>> I think I need to address the `impedance mismatch' in development cycles.
>>
>> One option would be to remove mediawiki 1.19 and related extensions as
>> dependencies in the wp-mirror DEB package; and instead include the
>> latest version of mediawiki and relevant extensions, as part of the
>> wp-mirror DEB package.  This would have some consequences.
>
> Option two:  Host your own debian repository which contains wp-mirror
> and the newer versions of mediawiki et al as separate packages.  I think
> this would be the easiest for the users (honestly, installing the debian
> package from the cli involved a few extra undocumented steps that a lot
> of people aren't familiar with) and the most maintainable.
>
> You could even do a stable and a testing repo.  A cron job could check
> for new versions of mediawiki etc and auto package them.  Individuals
> wanting to help with development could enable the testing repo and
> validate the upgrade.  You would then manually push the package to the
> stable repo once a suitable amount of time has passed.
>
> If you don't want to host your own repo, ubuntu's PPA infrastructure
> might be an option.