=== Draft of the actual article === 

During DebConf15 in Heidelberg, we had the pleasure to meet members of the
Debian ZSH team.

The team, composed of four German-speaking Debian developpers, was created
after the initial packager, Clint XXX, orphaned the zsh package. He pinged
several people, and it was decided to create the a team, in order to avoid the
burden of maintainership on only one person.

The team is in charge of ZSH and sponsors occasionally ZSH related packages,
like fizsh.

The Debian team has very good relation with upstream "We are very lucky to have
such a friendly and responsive upstream, but also very responsive users to help
detecting problems in various corner cases".
Three members of the Debian have even commit access upstream. The upstream is
managed smoothly during a release cycle of Debian, and upstream patches are
usually easily cherry-pickable.

The ZSH team benefits also from a Jenkins infrastructure, provided by the Grml
Debian derivative and maintained by Mickael Prokop, which after every commit,
build the zsh package and run piuparts, lintian and other quality assurance tools.


=== Initial questions ====

- size of the team

- tasks
  - packaging (interpreter + ?? packages)
  - workflow / particular tools you use
  
- relation with upstream

- past/scheduled sprints

- short/long term goals

=== Notes from the interview ====

jenkins infrastructure building on every push ( on the grml server)
(jenkins-debian-glue) run piupart, lintian,...

4 people (more hanging on IRC channel) on freenode
3 have commit accept upstream
1 member really active upstream + global .zshrc
(most patches from Debian: completion for specific/Debian related tools)

german-speaking team

only zsh source package (+sponsor zshell related packages: fizsh) 

clint gave up the package -> pinged people -> creation of the team
(maintainance but not alone: peer review, rely on other about some aspects)
(check debian-devel) (somewhere between squeeze/wheezy)

very responsive users (usually advanced users: not the default choice)
frendly and responsive upstream: very good relation

plan:
 - package grml zsh rc conf (even RFP for that)
 - sprint for that
 - zshell-static package will be kept

patches from upstream cherry-pickable. smooth management during release cycle