[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: Using git/collab-maint/PET for debian-mentors.



[Please excuse the long email. I welcome comments.]

There has been some recent discussion on debian-mentors about the
difficulties being faced by contributors seeking sponsorship, i.e. that
DDs willing to sponsor packages are short on time and/or motivation.

In my view, this is an important issue because Debian is growing; we
always need more DDs in every area of Debian, which means we always need
more people going through NM, so we need more sponsorship.  Note that I
assume that the purpose of sponsorship is to produce DDs who will
contribute in other areas of Debian, not just to the few packages they
maintain.

The problem I see with the current debian-mentors situation is that
contributing here is very different to contributing to the rest of
Debian; there is too much emphasis on uploading new packages, and not
enough on bug-fixing and maintenance.  Most important work these days
takes place in teams, and the mentors list does not feel like a team.  

At the same time, I don't think turning debian-mentors into a team would
work just yet - that would be a bit sudden, and would probably
inconvenience a lot of people.

Proposal
========

I am considering creating a new workflow for my sponsoring:

      * Maintaining packages in git in collab-maint. (I don't think we
        want a separate pkg-mentors repository, because once people
        graduate from mentors they would feel compelled to move away.)
      * Using PET or similar to show which packages need review, and
        keep track of bugs/upstream versions. (Minor issue: I don't know
        how easy this is without putting the whole of collab-maint into
        PET.)
      * Optionally co-ordinating on IRC in #debian-mentors, as well as
        via notes at the top of debian/changelog.

This would then require my mentees to do some things they don't do at
the moment:

      * Register for an alioth account.
      * Learn how to maintain packages in a VCS.
      * Use the 'UNRELEASED/unstable' method of changelog management
        (and probably stop bothering with the RFS mails).

It would also allow potential contributors to collaborate on packaging
work in a team, rather than every sponsored package being worked on by
exactly one person.

I would most likely enforce the use of short dh7 rules files as well,
and go all out on the 'lintian -iI --pedantic' warnings, same as I do
with regular sponsorship.  And of course, any packages which belong in
other teams should be sent there - the steps above should have lowered
the barrier to entry to the rest of Debian.

Comments
========

Obviously once this is set up, it would be very easy for other DDs to
join in and work in the same manner.  With just a few like-minded
sponsors working together as a team, I think we could take the pressure
off the rest of the mentors mailing list, and improve the way
contributors perceive the mentors system.

I have not formed an opinion on whether the 'Maintainer' or 'Uploaders'
field should be set to a collaborative mailing list (e.g.
debian-mentors) as happens in most teams - at the moment sponsees are
responsible for handling bug reports individually, and I've no idea how
effective this is.  PET would tell us.

The above does not cater for handling NMUs and QA uploads of other
packages, which would happen outside of git.

It also potentially deprives mentees of the steps where they build and
upload the packages to the mentors repository, but I think this is a
minor thing - they will need to use pbuilder for testing anyway.

Success would be measured in terms of the number of contributors making
it to NM, DM and DD status.

-- 
Tim Retout <diocles@debian.org>

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: