Hi Carsten, Carsten Munk wrote: > Some of us are currently discussing how to deal with hardware > adaptations (also 'community' ones) and one question by Thomas B. > Ruecker from Tieto was that came up is what exactly our concept of > maintenance is and how it works in practice?
This will depend on the module. To take 2 extremes: Linus is the maintainer of the kernel, and works full time integrating patches from hundreds of contributors per month. If he spent less time, or had not set up a system with subsystem maintainers, the whole thing would break down. Donald Knuth has not made a release of TeX in over 2 years, since v3.1415926. Between 1982 and 2008, 425 bugs were corrected in the software, an average of 16 per year (and it's fewer per years since then). It would be fair to say that Prof. Knuth spends a median amount of 0 hours per week maintaining TeX. Basically, package maintainers typically take care of: * Packaging & releasing new versions (I know of at least one maintainer debating whether "git tag" is sufficient). Many maintainers just maintain .spec files and similar packaging metadata in the source tree, and ask volunteers to maintain the packages for various distros. * Communicating with everyone who develops the package when there's a new version (or beforehand) to give documenters, translators and plug-in developers the chance to update their work * Managing the roadmap of the product (letting people know what features you want to have in the next version, and who's going to do them - or not going to do them, as the case may be) * Reviewing bug reports, providing feedback on potential fixes, providing patch review and integrating patches * Typically the maintainer is also the primary developer of a piece of software. Good maintainers look for opportunities to delegate as much as possible - such as packaging and translations, but also potentially bug triage, bug fixing and patch review. Maintainers in the Debian sense don't actually (necessarily) develop the software they maintain. They: * Keep up to date on what is happening in the upstream project, and prepare packages for new versions for upload * Watch bugs reported against their package, and filter packaging bugs (which are their responsibility) from software bugs (which should get cloned upstream) * Follow upstream bugs that are duplicated against the package, and keep the distro bug system in sync with the upstream bugs (ie. when a bug gets closed against Totem, it should also get closed with a pointer to the fix against Debian's Totem package) * Forward patches upstream for review But packaging maintainers do not generally have a say in the project roadmap, or do any product management type tasks. > I'm sure this is an issue that most vendors wonder about too in our > feature process/package maintaining/etc, so here they are: > > Specifically: > * what are the requirements for a maintainer in terms of: > * availability > * time commitment > * response to requirement changes This is totally dependent on the software, the community around it, and the maintainer in question. If you're maintaining stable well tested software with relatively few users, then maintenance might involve making a new release to get updated translations out every time there is a product release. If you're developing new software, then you will be writing new code, with bugs in it, and potentially responding to daily feedback from alpha users. The interesting question, I think, is "how much time will software maintenance tasks take over & above coding tasks?" Another way of putting it is: How much time does it take to manage a development project? If you have one developer, not much. If you have two developers, then the manager will want to make sure that the developer is working on the right thing, in the right way. So there's some overhead. He'll also want to co-ordinate releases and alternate between write new code & fix and stabilise. But communicating releases to 2 developers isn't a big deal. If you have 10 developers, you might delegate responsibility for a sub-project to someone, but have regular status meetings to ensure everyone is on track and ensure your roadmap & release schedule are matching reality, etc. etc. The glib short answer to the question "how much time does it take to be a maintainer?" is "as much time as the maintainer wants to spend". Cheers, Dave. -- Email: [email protected] Jabber: [email protected] _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
