[Pkg-mediawiki-devel] Where we are and where we go

[Marc Dequènes (Duck)]

Coin,

Marc Dequènes (Duck) <Duck at DuckCorp.org> writes:

> First important step is to reorganize our repository. GNU Arch is meant
>...

This now DONE. The first version in the archive, 1.4.10-1, is the
starting point of our new repository. 1.4.11-1 was imported too.

I wrote a first attempt of generic documentation for revision control of
Debian packages using baz, which can be found here :
  https://wiki.duckcorp.org/DebianPackagingTutorial/RcsDeb
This does not yet include arch-buildpackage use (but use of this tools
is optional), and most of all do not cover the personnal use at home in
a decentralized environnement. This will come...

Then, you SHOULD NEVER publish changes by direct commits to the
arch.debian.org repository ; work in your own branch at home, test it,
ask ppl to test it in their own branch too if necessary, and ask for
inclusion if the result is good. When the team is ok to accept it, then
your changes would then be merged into the mainline.

Until some missing parts enter the repository (related packages, new 1.5
branch), the documentation is improved, and someone has sufficient baz
knowledge, i would do the mainline maintenance myself. This would not
impact on the team choices over patch acceptation, only the technical
part is my job until someone can assist me in this (not so exiting)
task.

> Second step is to review the existing non-official packages of phptal &
> co and prepare an upload soon.

I plan to work on this in a few days (or this we if i can get sufficient
free time.

> Third step is to work on user installations, which is related to
> multisite capability. A user with no special rights should be able to
>...

Toots has been working on it recently and his work should be validated
soon (tested).


I suggest we include the lastest fixes (build architecture problems for
example) and improvements (multisite support if validated) and get a
shiny 1.4.11-2 package ready in unstable. When it is done, and we only
have to take care of grave and security fixes for 1.4 branch, we should
then focus on 1.5 migration and use experimental to have users test the
upgrade path (which may be tricky). Optionally, one can finish preparing
1.4.11-2 while another start work on 1.5 branch.

-- 
Marc Dequènes (Duck)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-mediawiki-devel/attachments/20051008/dcc8e709/attachment.pgp