MOTU Tools & Workflow

[Emmet Hikory]

    In the discussion of "Future of REVU and Debian Mentors" (1),
there has been further discussion of useful tools, which reminds me of
previous discussion of "
Archive tools/reports for universe" (2).  There has also been
discussion of what we used to do, and what we should do, now split
into a couple threads.

    Firstly, I'd like to suggest that we not consider the processes
used pre-Dapper as a model for future processes, as these were well
designed for a small team with a small number of issues, but being
largely wiki-based, don't scale well to the larger team and much
larger amount of work done today.

    Secondly, I'd like to agree that the development of tools and
scripts to make MOTU work easier is a good thing, and that we should
make efforts to get common scripts packaged and distributed: having
scripts available, even with directions from a Wiki page is a good
thing, but it would be much better to be able to suggest to
contributors and other developers that some set of packages is
installed, which does the right thing.  Jordan has prepared a nice
wiki page (3) to work towards getting the shell scripts together.

    Thirdly, I also believe there is a place for web-based tools.
While this may require different skills than writing shell scripts,
the results are very useful, and easily allow for collaboration.  On
the other hand, we've had some issues in the past with bandwidth and
hardware for external tools.  I'd like to suggest that we review our
current set, package them, and either integrate with existing tools,
or request centralised hosting to reduce the time spent on
administration, and allow us to focus on the primary work.  A first
start at a list would be:

1. REVU (4)
2. MDT (5)
3. debcheck (6)
4. missing-fixes  (7)
5. DaD (8)
6. Automated linda/lintian checking (not available)
7. What else would be useful?

    MoM is an excellent example of a tool that was created by MOTU,
reviewed, improved, and is now officially hosted in the data centre,
and a core feature of Ubuntu development: Let's follow this path
towards improving the collaborative toolset.

    Fourthly, I believe we need stronger definitions of workflow.
There are many people who ask "What can I do?" or "How can I help?".
Generally, we refer them to merges, bitesize bugs (9), or other things
that don't require us to think much.  With clearer definitions of what
needs to be done, and how it could be done, I suggest that we would
see more activity, and a higher quality distrubution.  I propose that
the best way to address this is to update and improve the TODO wiki
page (10).  The current emphasis on merges & new packaging likely
contributes to the current focus on these activities.

    Lastly, while there are several valid philosophical reasons why LP
may not be considered an ideal tool for us, it is the standard
workflow tool for Ubuntu, and we will get greater support in terms of
hosting and adoption into main for our tools if we work with the LP
developers to extend and improve the environment, rather then building
our own tools externally.  Software like apport, bughelper, and
requestsync is much more useful than another wiki page or external
resource when it comes to ensuring wide adoption and improving our
workflow.

1: https://lists.ubuntu.com/archives/ubuntu-motu/2007-July/002003.html
2: https://lists.ubuntu.com/archives/ubuntu-motu/2007-July/001826.html
3: https://wiki.ubuntu.com/UbuntuDevTools
4: http://revu.tauware.de/
5: http://people.debian.org/~lucas/ubuntu-versions/
6: http://alt.qeuni.net/~william/debcheck/
7: http://ajmitch.net.nz/~ajmitch/missing-fixes-rc.html (and similar)
8: http://dad.dunnewind.net/
9: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
10: https://wiki.ubuntu.com/MOTU/TODO

-- 
Emmet