ArchiveReorganisation and sponsoring

Philip Wyett philwyett at
Sun Aug 31 23:31:01 BST 2008

On Mon, 2008-09-01 at 01:41 +0900, Emmet Hikory wrote:
> In a recent IRC conversation, I was asked how
> ArchiveReorganisation (1) would affect sponsoring, and thought I'd
> raise the same question to the mailing list in hopes of developing an
> answer.
>     The current model (2) consists of two teams: Ubuntu Sponsors for
> Main and Ubuntu Sponsors for Universe.  Those seeking sponsorship
> subscribe one of these teams, depending on the component in which the
> package resides, and members of those teams then review the upload
> candidate.  There are a number of procedural differences in the ways
> that the two queues work, but for the most part there is a fairly
> simple and obvious interface from the point of view of someone seeking
> to submit an improvement to Ubuntu.
>  * Updates to packages very specific to certain maintenance teams
> (e.g. Mythbuntu Developers, Mozilla Team) are very rarely sponsored
> except by members of those teams.
>  * Updates to some packages in the Main queue may remain unreviewed
> after for an extended time because the specific package falls between
> different maintenance teams, yet casual sponsors viewing the bug
> assume it belongs to some specific person or team.
>  * Updates to some packages in the Universe queue may be lost in the
> bugmail of the interested maintenance team, perhaps causing delay, or
> perhaps resulting in an upload by a sponsor unfamiliar with the effect
> of a change on the flavour concerned.
>     Assuming that there remains no sponsoring interface in Launchpad,
> one possible model for a solution might be modify pkgbinarymangler to
> assign different maintainers based on seed contents, rather than
> main/universe, so that each approved maintenance team would be
> appropriately identified as the maintainer for the binary package.
> Someone wishing to submit a new candidate package could then know the
> appropriate team to approach when seeking sponsorship.  If we redefine
> "universe" to mean unseeded packages (which is a close match to the
> definition prior to the introduction of "Universe Flavours"), the
> sponsoring process for the redefined universe can remain essentially
> as it is now.  The Ubuntu Sponsors for Main team can be dissolved, and
> instead those seeking sponsoring can directly subscribe the relevant
> maintenance team responsible for the package.
>     Unfortunately, this model has a few failings, as follows:
>  * Some teams (e.g. Ubuntu Desktop) are subscribed to *lots* of bugs,
> and sponsorship requests may be lost in the noise


main should really be a special case and treated with a high priority
with regarding updates and patches to bugs to enable as fast as possible

As I see it simply :-)

* Bug reported
* Bug goes through normal info asks, answers and confirmation etc.

Once a patch is offered up...

* The bug is pushed to a status of 'Fix proposed'.

The fixed proposed state:

  * Bug is locked from any further editing.
  * Notification sent to an arm of the release team (email 'note1') plus
    all other subscribers of new state.
  * Allocated by arm of release team to appropriate team or person.
  * Fix confirmed as good or rejected and state changed to show this
    by allocated team or person.

    If rejected, appropriate LP state set and further work can be
    done and conversation had.

    If accepted as good, will be pushed into -proposed upload process
    and appropriate LP state set.

note1: Use of appropriate email tagging from LP would help filter what
is bugmail and what is fixmail for those inside this process. 

I propose an arm of the release team as control and monitor to the
process with QA then monitoring via that well established team.

If a bug could go from 'Fix proposed' to rejected or accepted in 5
working days would be excellent.

Some work on the -proposed process may also need to be performed on how
confirmations of good or bad a fixed package in -proposed are handled so
good fixes are efficiently moved to -updates or are rejected and can
cycle back into the bug process.

I do understand that all these processes always rely on the best of
information being supplied at all levels and for newbies needs to be as
simple as possible.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : 

More information about the ubuntu-devel mailing list