non-MOTU Hopeful contributions (was:: GetDeb Project (Why I participate))

[Emmet Hikory]

On 10/19/07, João Pinto <lamego.pinto at gmail.com> wrote:
> IMHO, the point is not about lowering the bar, is is about not having the
> "bar" at all, the key is about converting the current MOTU processes which
> are based on a long pipe workflow with known bottlenecks into a grid
> workflow .

    While I'm strongly in agreement that the issue is about developing
processes that scale well, for which a grid workflow may be a
solution, I'm less sure that completely open uploads are ideal: it
makes sense to me that there is a set of people who are trusted to
upload to the repositories, and that there are requirements to be
granted this trust.  The alternative may lead to claims of copyright
violation, unauthorised use of patented technologies, distribution of
unacceptable content, etc.  Despite that, the "bar" for MOTU should
not significantly impact the opportunity for others to contribute (and
there is currently no "bar" to the Contributors team (1)).

> The current process requires, developers which love debian/rules, but which
> hate debian/copyright to be expert on both.
> The current process requires end users, which love to test new software, and
> which would be the best functional testers for new packages/updates to
> subscribe this list in order to get "please test" notifications. IThis list
> is not really interesting for those people which spend more time using
> applications, than packaging them.
>
> The key, is about moving from single processing, to multiprocessing,
> different people, with different skills can provide their specif contribute
> to the final product which is, a good package, proper tested from both a
> packaging and functional perspective and which will be updated according to
> a policy which also meet users expectations.

    While this list of issues with the current process is far from
complete, I believe the extended list falls into two basic categories:
barriers on collaboration before a package enters the archive, and
communication issues to non-developer users.

    For the former, a couple of solutions have been tried, and REVU
has been of great benefit, but there does not yet seem to be a
combination of tools and workflow that meets everyone's needs.
Further, the social aspects of collaborative initial packaging can be
difficult: some people maintain a sense of "ownership" of their work,
and may not react well to arbitrary "assistance"; some people prefer
to work in a VCS environment, and some would rather avoid it (never
mind discussions as to which VCS); and some people approach packaging
as an educational exercise, and would prefer explanations and comments
to a working replacement.  In the simple case of one developer who
puts together excellent debian/rules and debian/control files (along
with whatever other helpers assist these), but is having trouble with
debian/copyright, requesting assistance either from
ubuntu-motu at lists.ubuntu.com or ubuntu-motu-mentors at lists.ubuntu.com
may well result in a volunteer to assist with the remainder of the
packaging.

    For the latter, extended promotion of teams and bug tags may be
valueable.  I'm not deeply familar with backport and update
procedures, but I suspect that the backport testers team bug list (2)
is likely a good list of backports that need testing, and that bugs
with the "verification-motu-needed" tag (3) is the correct source for
packages currently in need of testing for -updates.

> Changing from single to multi processing is not simple, it is not just about
> adding new processors (in this case, people), it is about changing the
> application, building reliable interfaces between processes, handling shared
> resources, handling synchronization, etc.
>
> The documentation improvement is important because it is the entry point for
> participation, however, it is not sufficient.

    I completely agree it's neither easy to develop processes that
scale arbitrarily, nor to change processes already in use by hundreds
of people.  On the other hard, I believe that a sufficient amount of
the infrastructure exists that changes in the documentation are
sufficient to represent a change to the process.  I see that there are
two activities here: firstly identifying poorly advertised processes,
and ensuring that it is easy for people to find them, and contribute
towards the result, and secondly identifying places where our
processes bottleneck, and developing solutions that reduce the impact
of these bottlenecks while preserving the quality of the final result.
 I suspect that it is the rare case where a combination of the tools
already available cannot be used to accomplish these goals.

1: https://launchpad.net/~ubuntu-universe-contributors
2: https://bugs.launchpad.net/~ubuntu-backports-testers/
3: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=verification-motu-needed

P.S.  There are several tags including the work "verification".  Are
they all in use?  Were some mistakenly entered?

-- 
Emmet HIKORY