Unblocking SRU uploader permissions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Unblocking SRU uploader permissions

Robie Basak-4
I'm writing to ubuntu-devel with my DMB hat because I'd like to hear the
opinions of existing Ubuntu developers.

Eric and Dave both work for STS - Sustaining Engineering (L3 support), a
department within Canonical. They've both applied to the DMB recently.
Both are motivated primarily by the need to drive SRUs without
unnecessary review queue delays. Right now, they get blocked on needing
sponsorship for most of their work. What should be the path that we
suggest to STS staff who have the goal of no longer needing sponsorship
to drive SRUs?

For background, STS (Support and Technical Services) is responsible for
handling Ubuntu Advantage customer support requests. Most of their
contributions to Ubuntu are in the form of SRUs. The majority of these
SRUs are in main, but across desktop, server and cloud packages, and
include more "core" packages in no packageset. Currently, to fulfil the
STS goal, they either need sponsorship or need to be core devs.

If the answer is that they need to be core devs, then the problem
becomes "what is the appropriate path to get to core dev"? One
expectation seems to be to get MOTU first. But MOTU doesn't seem like
the right path to me. We get applications aiming down this path (like
Eric's), but universe uploads aren't really the goal for these
applicants. Being able to drive SRUs is the goal. It seems inappropriate
to me to force applicants to contribute through some fundamentally
unrelated path to get to their goal of directly driving SRUs. We don't
force other Ubuntu contributors to contribute in area B before they can
upload directly to unrelated area A. I think we should find a way to
allow proven contributors to area A to do that directly.

My understanding is that traditionally a large influencer of a DMB
decision is the consideration of what a successful application would
unblock. If a contributor is doing good work, we want to get out of the
way. So we'd usually grant an application for uploads in a particular
area if endorsers and other relevant people are happy with the
applicant's track record in that area (on quality, understanding of
process, team cooperation, etc). Conversely, not having a track record
of uploads in an area, or not having the intention of continuing uploads
in that area, has generally always been seen as a red flag. The one
exception is in the case of an application from the social aspect, but
this is rare and doesn't apply to my question today.

For this reason, I've been reluctant to vote to award core dev to
applicants with experience mainly limited to driving SRUs, or to vote to
award MOTU without seeing a corresponding level of contributions to
universe. This makes me quite torn with both Eric and Dave's
applications. I think that the quality of their SRUs is high, and think
that they should be able to upload SRUs directly (as well as their fixes
to the development release). But since they don't have a great deal of
experience apart from SRUs, I'm not sure if I should vote to grant core
dev to achieve this.

In my experience, STS staff are generally very good at understanding and
driving the SRU process well. To me, it's clear that if an individual
applicant has a proven track record of high quality sponsored SRU
uploads, it should be a no-brainer for the DMB to grant the applicant
the ability to upload further SRUs without sponsorship. Not doing so
blocks progress. I distinctly remember the pain of the triple wait
between the sponsorship review queue, the SRU review queue and the SRU
verification aging period. And how that increased time increases the
risk that a security upload will trump the SRU and the whole process
will have to go round again, which IIRC happened to me multiple times.

How should we unblock SRU sponsorees and get ourselves more SRU
uploaders? Some points for discussion:

* Is the DMB asking for too much from applicants before granting core
  dev and/or MOTU?

* Should we just give this category of applicants core dev, on the basis
  that we trust these applicants won't upload in other areas without
  seeking advice first? Though in that case, why does the DMB enforce
  per-package-group limits using ACLs at all? Why don't we make all
  successful applicants in any area core devs and ask them all to
  self-police?

* Should we require them to have some wider experience, but less than we
  might for a more generalist core dev applicant, on the basis that
  we're bending to unblock the SRUs as we have no other suitable ACL
  method? In other words, because we don't have an SRU-specific upload
  ACL, should we lower the bar to make progress?

* Should we maintain the bar and require potential SRU uploaders to
  obtain a more wide breadth of experience appropriate for a core dev,
  and only then grant them core dev to unblock their SRU uploads?
  Perhaps requiring them to go through MOTU and make substantial
  contributions to universe, or through other more limited packagesets
  first?

* Based on the tooling the DMB uses to grant upload access, it seems to
  me that Launchpad may be able to allow the DMB to adjust ACLs to
  permit upload to stable releases but not the development release.
  Would this work? It wouldn't help with the initial development release
  upload often required in an SRU, but would help with the subsequent
  SRU uploads, so would at least relieve some of the burden.

I'd appreciate feedback from the wider Ubuntu developer community on
what the DMB should do here.

Thanks,

Robie (acting for himself as a single DMB member)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unblocking SRU uploader permissions

Stéphane Graber-2
On Thu, Feb 02, 2017 at 07:09:57AM +0000, Robie Basak wrote:

> I'm writing to ubuntu-devel with my DMB hat because I'd like to hear the
> opinions of existing Ubuntu developers.
>
> Eric and Dave both work for STS - Sustaining Engineering (L3 support), a
> department within Canonical. They've both applied to the DMB recently.
> Both are motivated primarily by the need to drive SRUs without
> unnecessary review queue delays. Right now, they get blocked on needing
> sponsorship for most of their work. What should be the path that we
> suggest to STS staff who have the goal of no longer needing sponsorship
> to drive SRUs?
>
> For background, STS (Support and Technical Services) is responsible for
> handling Ubuntu Advantage customer support requests. Most of their
> contributions to Ubuntu are in the form of SRUs. The majority of these
> SRUs are in main, but across desktop, server and cloud packages, and
> include more "core" packages in no packageset. Currently, to fulfil the
> STS goal, they either need sponsorship or need to be core devs.
>
> If the answer is that they need to be core devs, then the problem
> becomes "what is the appropriate path to get to core dev"? One
> expectation seems to be to get MOTU first. But MOTU doesn't seem like
> the right path to me. We get applications aiming down this path (like
> Eric's), but universe uploads aren't really the goal for these
> applicants. Being able to drive SRUs is the goal. It seems inappropriate
> to me to force applicants to contribute through some fundamentally
> unrelated path to get to their goal of directly driving SRUs. We don't
> force other Ubuntu contributors to contribute in area B before they can
> upload directly to unrelated area A. I think we should find a way to
> allow proven contributors to area A to do that directly.
>
> My understanding is that traditionally a large influencer of a DMB
> decision is the consideration of what a successful application would
> unblock. If a contributor is doing good work, we want to get out of the
> way. So we'd usually grant an application for uploads in a particular
> area if endorsers and other relevant people are happy with the
> applicant's track record in that area (on quality, understanding of
> process, team cooperation, etc). Conversely, not having a track record
> of uploads in an area, or not having the intention of continuing uploads
> in that area, has generally always been seen as a red flag. The one
> exception is in the case of an application from the social aspect, but
> this is rare and doesn't apply to my question today.
>
> For this reason, I've been reluctant to vote to award core dev to
> applicants with experience mainly limited to driving SRUs, or to vote to
> award MOTU without seeing a corresponding level of contributions to
> universe. This makes me quite torn with both Eric and Dave's
> applications. I think that the quality of their SRUs is high, and think
> that they should be able to upload SRUs directly (as well as their fixes
> to the development release). But since they don't have a great deal of
> experience apart from SRUs, I'm not sure if I should vote to grant core
> dev to achieve this.
>
> In my experience, STS staff are generally very good at understanding and
> driving the SRU process well. To me, it's clear that if an individual
> applicant has a proven track record of high quality sponsored SRU
> uploads, it should be a no-brainer for the DMB to grant the applicant
> the ability to upload further SRUs without sponsorship. Not doing so
> blocks progress. I distinctly remember the pain of the triple wait
> between the sponsorship review queue, the SRU review queue and the SRU
> verification aging period. And how that increased time increases the
> risk that a security upload will trump the SRU and the whole process
> will have to go round again, which IIRC happened to me multiple times.
>
> How should we unblock SRU sponsorees and get ourselves more SRU
> uploaders? Some points for discussion:
>
> * Is the DMB asking for too much from applicants before granting core
>   dev and/or MOTU?
MOTU shouldn't be required for coredev applications and we have quite a
few examples where non-MOTU got coredev status in the past.

That being said, it is expected that coredev have broader experience
than SRU-only and I'm not suggesting that we lower that standard.

> * Should we just give this category of applicants core dev, on the basis
>   that we trust these applicants won't upload in other areas without
>   seeking advice first? Though in that case, why does the DMB enforce
>   per-package-group limits using ACLs at all? Why don't we make all
>   successful applicants in any area core devs and ask them all to
>   self-police?
>
> * Should we require them to have some wider experience, but less than we
>   might for a more generalist core dev applicant, on the basis that
>   we're bending to unblock the SRUs as we have no other suitable ACL
>   method? In other words, because we don't have an SRU-specific upload
>   ACL, should we lower the bar to make progress?
We can create an ACL which allows archive upload to all released series.

That'd be identical to the "ubuntu-sru" ACL but for upload rather than
queue admin.

> * Should we maintain the bar and require potential SRU uploaders to
>   obtain a more wide breadth of experience appropriate for a core dev,
>   and only then grant them core dev to unblock their SRU uploads?
>   Perhaps requiring them to go through MOTU and make substantial
>   contributions to universe, or through other more limited packagesets
>   first?
>
> * Based on the tooling the DMB uses to grant upload access, it seems to
>   me that Launchpad may be able to allow the DMB to adjust ACLs to
>   permit upload to stable releases but not the development release.
>   Would this work? It wouldn't help with the initial development release
>   upload often required in an SRU, but would help with the subsequent
>   SRU uploads, so would at least relieve some of the burden.
Right and that seems to me like the way to go to deal with those applications.

> I'd appreciate feedback from the wider Ubuntu developer community on
> what the DMB should do here.
>
> Thanks,
>
> Robie (acting for himself as a single DMB member)

--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unblocking SRU uploader permissions

Iain Lane-6
In reply to this post by Robie Basak-4
On Thu, Feb 02, 2017 at 07:09:57AM +0000, Robie Basak wrote:

> If the answer is that they need to be core devs, then the problem
> becomes "what is the appropriate path to get to core dev"? One
> expectation seems to be to get MOTU first. But MOTU doesn't seem like
> the right path to me. We get applications aiming down this path (like
> Eric's), but universe uploads aren't really the goal for these
> applicants. Being able to drive SRUs is the goal. It seems inappropriate
> to me to force applicants to contribute through some fundamentally
> unrelated path to get to their goal of directly driving SRUs. We don't
> force other Ubuntu contributors to contribute in area B before they can
> upload directly to unrelated area A. I think we should find a way to
> allow proven contributors to area A to do that directly.
For what it's worth, I don't think that we've seen there be an (unspoken
or otherwise) requirement for MOTU as a prequisite for core-dev for a
long time now.

I think that I was in the more liberal wing of the DMB during my time,
but I would have been happy to grant core-dev if the applicant has shown
through sponsored uploads to any series that they are a very competent
developer, that upload rights to main are required for their
contributions, and if I was satisfied by some combination of the
interview and their contributions that they understand the policy and
procedure of the distro. That includes knowledge of both SRUs and
development release uploads, and convincing you that they won't
overreach and will ask for help when they need it.

It's possible to create an ACL that expresses what you're after -
ubuntu-sru has it for queue admin currently - but I'm not yet convinced
that creating more classes of developer is required. Not that I need to
be convinced. :)

--
Iain Lane                                  [ [hidden email] ]
Debian Developer                                   [ [hidden email] ]
Ubuntu Developer                                   [ [hidden email] ]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unblocking SRU uploader permissions

Robie Basak-4
A couple of points of clarification:

On Thu, Feb 02, 2017 at 09:29:25AM +0000, Iain Lane wrote:

> On Thu, Feb 02, 2017 at 07:09:57AM +0000, Robie Basak wrote:
> > If the answer is that they need to be core devs, then the problem
> > becomes "what is the appropriate path to get to core dev"? One
> > expectation seems to be to get MOTU first. But MOTU doesn't seem like
> > the right path to me. We get applications aiming down this path (like
> > Eric's), but universe uploads aren't really the goal for these
> > applicants. Being able to drive SRUs is the goal. It seems inappropriate
> > to me to force applicants to contribute through some fundamentally
> > unrelated path to get to their goal of directly driving SRUs. We don't
> > force other Ubuntu contributors to contribute in area B before they can
> > upload directly to unrelated area A. I think we should find a way to
> > allow proven contributors to area A to do that directly.
>
> For what it's worth, I don't think that we've seen there be an (unspoken
> or otherwise) requirement for MOTU as a prequisite for core-dev for a
> long time now.
I haven't seen any evidence of an (unspoken or otherwise) _requirement_
to get MOTU before core-dev, either. But I have seen an unspoken
_expectation_ of this path from multiple applicants (not just Canonical
STS). Not from the DMB; from prospective new developers.

> I think that I was in the more liberal wing of the DMB during my time,
> but I would have been happy to grant core-dev if the applicant has shown
> through sponsored uploads to any series that they are a very competent
> developer, that upload rights to main are required for their
> contributions, and if I was satisfied by some combination of the
> interview and their contributions that they understand the policy and
> procedure of the distro. That includes knowledge of both SRUs and
> development release uploads, and convincing you that they won't
> overreach and will ask for help when they need it.

My "contribute in area B before they can upload directly to unrelated
area A" statement applies to this scenario, too, not just in relation to
MOTU/core dev. We're currently requiring applicants to understand more
than is just required for SRUs in order to upload SRUs. I feel that your
statement above is saying this as well.

Robie

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unblocking SRU uploader permissions

Iain Lane-6
On Thu, Feb 02, 2017 at 09:41:02AM +0000, Robie Basak wrote:
> > For what it's worth, I don't think that we've seen there be an (unspoken
> > or otherwise) requirement for MOTU as a prequisite for core-dev for a
> > long time now.
>
> I haven't seen any evidence of an (unspoken or otherwise) _requirement_
> to get MOTU before core-dev, either. But I have seen an unspoken
> _expectation_ of this path from multiple applicants (not just Canonical
> STS). Not from the DMB; from prospective new developers.

OK, but then there is a task to work towards removing that expectation.

> > I think that I was in the more liberal wing of the DMB during my time,
> > but I would have been happy to grant core-dev if the applicant has shown
> > through sponsored uploads to any series that they are a very competent
> > developer, that upload rights to main are required for their
> > contributions, and if I was satisfied by some combination of the
> > interview and their contributions that they understand the policy and
> > procedure of the distro. That includes knowledge of both SRUs and
> > development release uploads, and convincing you that they won't
> > overreach and will ask for help when they need it.
>
> My "contribute in area B before they can upload directly to unrelated
> area A" statement applies to this scenario, too, not just in relation to
> MOTU/core dev. We're currently requiring applicants to understand more
> than is just required for SRUs in order to upload SRUs. I feel that your
> statement above is saying this as well.
For core-dev I would expect some knowledge of the main parts of Ubuntu's
process. I don't think that I would expect to see contributions in the
form of uploads. If those exist then they might be a demonstration of
knowledge, but that could also happen in another way.

It's up to the DMB. If the group thinks that for core-dev there should
be significant contributions to the development release specifically, as
well as demonstrating an understanding of its process, then you probably
do want to create a new class that doesn't require this. That would
certainly be acceptable. I'm saying that I don't set the bar high enough
to see the required level of understanding as being very difficult to
achieve if you've already contributed via sponsored uploads elsewhere,
so I personally don't see the added complexity as being necessary.

--
Iain Lane                                  [ [hidden email] ]
Debian Developer                                   [ [hidden email] ]
Ubuntu Developer                                   [ [hidden email] ]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unblocking SRU uploader permissions

Louis Bouchard-2
In reply to this post by Robie Basak-4
Hello,

Le 02/02/2017 à 08:09, Robie Basak a écrit :

> I'm writing to ubuntu-devel with my DMB hat because I'd like to hear the
> opinions of existing Ubuntu developers.
>
> Eric and Dave both work for STS - Sustaining Engineering (L3 support), a
> department within Canonical. They've both applied to the DMB recently.
> Both are motivated primarily by the need to drive SRUs without
> unnecessary review queue delays. Right now, they get blocked on needing
> sponsorship for most of their work. What should be the path that we
> suggest to STS staff who have the goal of no longer needing sponsorship
> to drive SRUs?
>
> For background, STS (Support and Technical Services) is responsible for
> handling Ubuntu Advantage customer support requests. Most of their
> contributions to Ubuntu are in the form of SRUs. The majority of these
> SRUs are in main, but across desktop, server and cloud packages, and
> include more "core" packages in no packageset. Currently, to fulfil the
> STS goal, they either need sponsorship or need to be core devs.
>
> If the answer is that they need to be core devs, then the problem
> becomes "what is the appropriate path to get to core dev"? One
> expectation seems to be to get MOTU first. But MOTU doesn't seem like
> the right path to me. We get applications aiming down this path (like
> Eric's), but universe uploads aren't really the goal for these
> applicants. Being able to drive SRUs is the goal. It seems inappropriate
> to me to force applicants to contribute through some fundamentally
> unrelated path to get to their goal of directly driving SRUs. We don't
> force other Ubuntu contributors to contribute in area B before they can
> upload directly to unrelated area A. I think we should find a way to
> allow proven contributors to area A to do that directly.
>
> My understanding is that traditionally a large influencer of a DMB
> decision is the consideration of what a successful application would
> unblock. If a contributor is doing good work, we want to get out of the
> way. So we'd usually grant an application for uploads in a particular
> area if endorsers and other relevant people are happy with the
> applicant's track record in that area (on quality, understanding of
> process, team cooperation, etc). Conversely, not having a track record
> of uploads in an area, or not having the intention of continuing uploads
> in that area, has generally always been seen as a red flag. The one
> exception is in the case of an application from the social aspect, but
> this is rare and doesn't apply to my question today.
>
> For this reason, I've been reluctant to vote to award core dev to
> applicants with experience mainly limited to driving SRUs, or to vote to
> award MOTU without seeing a corresponding level of contributions to
> universe. This makes me quite torn with both Eric and Dave's
> applications. I think that the quality of their SRUs is high, and think
> that they should be able to upload SRUs directly (as well as their fixes
> to the development release). But since they don't have a great deal of
> experience apart from SRUs, I'm not sure if I should vote to grant core
> dev to achieve this.
>
> In my experience, STS staff are generally very good at understanding and
> driving the SRU process well. To me, it's clear that if an individual
> applicant has a proven track record of high quality sponsored SRU
> uploads, it should be a no-brainer for the DMB to grant the applicant
> the ability to upload further SRUs without sponsorship. Not doing so
> blocks progress. I distinctly remember the pain of the triple wait
> between the sponsorship review queue, the SRU review queue and the SRU
> verification aging period. And how that increased time increases the
> risk that a security upload will trump the SRU and the whole process
> will have to go round again, which IIRC happened to me multiple times.
>
> How should we unblock SRU sponsorees and get ourselves more SRU
> uploaders? Some points for discussion:
>
> * Is the DMB asking for too much from applicants before granting core
>   dev and/or MOTU?
>
> * Should we just give this category of applicants core dev, on the basis
>   that we trust these applicants won't upload in other areas without
>   seeking advice first? Though in that case, why does the DMB enforce
>   per-package-group limits using ACLs at all? Why don't we make all
>   successful applicants in any area core devs and ask them all to
>   self-police?
>
> * Should we require them to have some wider experience, but less than we
>   might for a more generalist core dev applicant, on the basis that
>   we're bending to unblock the SRUs as we have no other suitable ACL
>   method? In other words, because we don't have an SRU-specific upload
>   ACL, should we lower the bar to make progress?
>
> * Should we maintain the bar and require potential SRU uploaders to
>   obtain a more wide breadth of experience appropriate for a core dev,
>   and only then grant them core dev to unblock their SRU uploads?
>   Perhaps requiring them to go through MOTU and make substantial
>   contributions to universe, or through other more limited packagesets
>   first?
>
> * Based on the tooling the DMB uses to grant upload access, it seems to
>   me that Launchpad may be able to allow the DMB to adjust ACLs to
>   permit upload to stable releases but not the development release.
>   Would this work? It wouldn't help with the initial development release
>   upload often required in an SRU, but would help with the subsequent
>   SRU uploads, so would at least relieve some of the burden.
>
> I'd appreciate feedback from the wider Ubuntu developer community on
> what the DMB should do here.
>
> Thanks,
>
> Robie (acting for himself as a single DMB member)
>
>
>
Maybe I can share my experience, both as a member of Canonical's STS engineering
team, and as a Coredev that had to follow the full path.

Beforehand, let it be clear that Canonical's customer requirements are
independent of how the Ubuntu community should proceed. It is also important to
outline the fact that bug fixed following requests by Ubuntu Advantage customers
become available to the whole Ubuntu community through the SRU process.

My own motivation behind becoming a core developer was two fold :

 - Help out shorten the SRU turnaround time for our UA customers by having
   upload rights to the SRU queues. I am able to sponsor my teammate's SRU,
   foster best practices through sponsoring and teach Ubuntu development and
   debian packaging to colleagues who may eventually become interested in
   further participation.

 - Participate in the development of the Ubuntu distribution. I am also
   Debian Maintainer of a few packages, have done a few merges, helped out
   on FTBS and community bug fixes. I am also actively working on the
   development of sosreport and kdump-tools.

Only the later motivation requires full core dev upload rights.  Uploading to
the SRU queues also mean that further review will be done to the upload, a
stricter testing scheme will happen. In short, there will be more eyes on the code.

I also don't see any immediate requirements for being fluent in merges, builds
and the whole development ecosystem if only speeding up SRU resolution is the
ultimate goal. A expert understanding of packaging, upgrade path, testing and
regression is to be expected in order to respect the stable nature of the
releases. In other words, someone with upload rights to the stable releases
should be more concerned about the impact of our users and how their SRU upload
will impact the existing userbase than the enhancement of existing functionalities.

The Per-Package Upload rights already exist. Maybe enhancing this nomenclature
to add SRU queue upload rights would be sufficient. I also think that being at
least an Ubuntu Contributing member would allow for a minimal level of
understanding of the Ubuntu community requirements in order to gain access to
such rights.

Along with Robie's analysis, I don't think that going through MOTU is of any use
for STS engineering requirements, as we rarely touch Universe package. In those
cases, the standard sponsoring method is more than adequate.

HTH,

Kind regards,

...Louis

--
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer                       Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (857 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Proposal: new ~ubuntu-sru-uploaders team [was: Unblocking SRU uploader permissions]

Robie Basak-4
In reply to this post by Robie Basak-4
Thank you for the discussion on this. I propose to go ahead and add a
new ~ubuntu-sru-uploaders team that can upload to any main or universe
package in any stable release in the usual way, but not to the
development release. The team would owned and managed by the DMB through
the usual application process. I believe the DMB has the remit to do
this, so I'm now asking for a DMB vote.

My reasoning is as follows:

* We have a number of people who want to upload SRUs for packages in
  main, but haven't yet got core dev. But I am confident in granting
  some of them this new ~ubuntu-sru-uploaders membership, and their
  contributions would be valuable to the project, speed up SRUs that get
  unnecessarily delayed at the moment, and unblock sponsors.

* SRU uploads would still need to have the bug fixed in a development
  release first. No change in process there. ~ubuntu-sru-uploaders
  generally won't be able to do this directly and will need sponsorship.
  However, I still think ~ubuntu-sru-uploaders would be valuable.
  They'll only get stuck in the sponsorship queue once, instead of for
  each SRU. If there's review feedback from ~ubuntu-sru, or if a
  security upload trumps the SRU, then the loop will be tighter and thus
  quicker.

* I think that this also provides smaller steps and more exposure to
  Ubuntu development for contributors to work their way up.

* I feel that as long as we have core dev, MOTU and PPU separate, it
  doesn't make any sense to grant core dev to applicants who need to
  upload SRUs to main and who understand Ubuntu development processes.
  If we did this, then why have MOTU and PPU at all, instead of just
  making them all core devs? By definition, as long these divisions
  exist, we must have some differing requirements and criteria in
  granting applications. And as long as we do that, there are always
  going to be applicants to whom we are not confident in granting core
  dev, but are confident in their SRU uploads. I don't see any other
  path that is self-consistent other than to remove the distinction and
  make everyone binary (upload anything or upload nothing). I don't have
  any particular objection to considering that idea either. I do think
  that either we must remove the divisions or we must accept that some
  worthy contributors will not be able to upload because we don't have
  ACL lines drawn finely enough. Since we aren't considering removing
  the divisions right now, ~ubuntu-sru-uploader seems like a much
  easier, less disruptive and less objectionable path to making ACLs
  finer in order to better get contributions from a group I think is
  significant enough for this to be worth it.

If we don't agree to this, then I think I'm going to be stuck. I believe
there will be applicants to whom I will be reluctant to grant core dev
(so will be -1), would be confident in granting ~ubuntu-sru-uploader but
will be unable to do so.

In answer to some concerns in response to feedback:

* I believe that it is as straightforward to implement this as a
  packageset. The DMB would create the team and the TB would tweak
  (once) the ACL bits for us like they do for new PPU uploaders today.
  If it later turns out to be less straightforward, then I will want to
  rethink my proposal.

* I believe there are multiple contributors ready for this status today,
  who currently get blocked, so it would immediately be useful. There
  has been positive feedback from STS that they would like this.

* I don't think this would increase the burden on ~ubuntu-sru at all. I
  think we should only give this to people we trust can do SRUs
  correctly and with high quality, and have a track record in doing so.
  I'm only looking to remove requirements that clearly don't apply to
  SRUs, but do to core devs. If, in the DMB's judgement of the
  requirements that are left, a candidate doesn't meet them, then I'd
  encourage the DMB to vote -1 for SRU uploader anyway.

DMB members: please vote on creating ~ubuntu-sru-uploaders by responding
to this thread. Further discussion, including opinions from non-DMB, is
always welcome.

rbasak: +1

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: new ~ubuntu-sru-uploaders team [was: Unblocking SRU uploader permissions]

Robie Basak-4
On Mon, Feb 13, 2017 at 07:09:12PM +0000, Robie Basak wrote:
> Thank you for the discussion on this. I propose to go ahead and add a
> new ~ubuntu-sru-uploaders team that can upload to any main or universe
> package in any stable release in the usual way, but not to the
> development release. The team would owned and managed by the DMB through
> the usual application process. I believe the DMB has the remit to do
> this, so I'm now asking for a DMB vote.

The DMB approved this yesterday with four votes (unanimous amongst those
who made the meeting).

We agreed the following policy:

To join ~ubuntu-sru-uploaders, the DMB expects:

1) a good track record of sponsored SRUs, a demonstrated understanding
of SRU policies, requirements and process through that track record
including driving SRUs through to the end, not letting things languish
in -proposed;

2) endorsement from SRU sponsors [by this we mean regular sponsors who
have sponsored the applicant's SRUs];

3) the usual requirements and expectations for any uploader;

4) plus [the application of the usual] DMB member judgement.

There was some concern about potential bad uploads bothering the SRU
team, so to mitigate this we also agreed that individual
~ubuntu-sru-uploaders membership will be removed if any of:

1) ~ubuntu-sru resolves to remove the member (how they do so is up to
them);

2) or the DMB resolves to remove the member by a quorate vote, and a
vote will be held if any member of ~ubuntu-sru requests it.

I hope this will never be required, of course.

I'll create the team and request that the TB add it to the appropriate
Launchpad ACL when the first member's application is approved.

I know there is significant interest in Canonical STS staff joining this
new team, and I have been asked when to start applying and so on.

I think it's fine to apply now, but to ramp this up gradually and be
considerate to applicants applying for membership of other teams, I ask
that the DMB handle a maximum of one ~ubuntu-sru-uploaders application
per meeting until any initial wave is done. This is in addition to the
current two applications per meeting limit we have at the moment.

Eric, as you already have an outstanding application that got held
pending the resolution of this issue, do you want to apply first?

To all potential applicants: please remember that we do still have the
requirements as above. Since this team will grant Ubuntu membership, a
"significant and sustained" contribution to Ubuntu is still required. If
you don't have a nice set of SRUs that you have driven and have had
straightforwardly sponsored, or you don't have existing uploaders who
have sponsored your work and are ready to endorse you, you should
probably continue getting SRUs sponsored and defer your application
until you feel that you do meet these requirements.

I hope this new team will help get good quality SRUs landed with less
delay. And whether you are a member of this team or not, thank you for
helping Ubuntu out.

Robie

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: new ~ubuntu-sru-uploaders team [was: Unblocking SRU uploader permissions]

Louis Bouchard-2
Hello,

Le 28/02/2017 à 13:57, Robie Basak a écrit :

> On Mon, Feb 13, 2017 at 07:09:12PM +0000, Robie Basak wrote:
>> Thank you for the discussion on this. I propose to go ahead and add a
>> new ~ubuntu-sru-uploaders team that can upload to any main or universe
>> package in any stable release in the usual way, but not to the
>> development release. The team would owned and managed by the DMB through
>> the usual application process. I believe the DMB has the remit to do
>> this, so I'm now asking for a DMB vote.
>
> The DMB approved this yesterday with four votes (unanimous amongst those
> who made the meeting).
>
> We agreed the following policy:
>
> To join ~ubuntu-sru-uploaders, the DMB expects:
>
> 1) a good track record of sponsored SRUs, a demonstrated understanding
> of SRU policies, requirements and process through that track record
> including driving SRUs through to the end, not letting things languish
> in -proposed;
>
> 2) endorsement from SRU sponsors [by this we mean regular sponsors who
> have sponsored the applicant's SRUs];
>
> 3) the usual requirements and expectations for any uploader;
>
> 4) plus [the application of the usual] DMB member judgement.
>
> There was some concern about potential bad uploads bothering the SRU
> team, so to mitigate this we also agreed that individual
> ~ubuntu-sru-uploaders membership will be removed if any of:
>
> 1) ~ubuntu-sru resolves to remove the member (how they do so is up to
> them);
>
> 2) or the DMB resolves to remove the member by a quorate vote, and a
> vote will be held if any member of ~ubuntu-sru requests it.
>
> I hope this will never be required, of course.
>
> I'll create the team and request that the TB add it to the appropriate
> Launchpad ACL when the first member's application is approved.
>
> I know there is significant interest in Canonical STS staff joining this
> new team, and I have been asked when to start applying and so on.
>
> I think it's fine to apply now, but to ramp this up gradually and be
> considerate to applicants applying for membership of other teams, I ask
> that the DMB handle a maximum of one ~ubuntu-sru-uploaders application
> per meeting until any initial wave is done. This is in addition to the
> current two applications per meeting limit we have at the moment.
>
> Eric, as you already have an outstanding application that got held
> pending the resolution of this issue, do you want to apply first?
>
> To all potential applicants: please remember that we do still have the
> requirements as above. Since this team will grant Ubuntu membership, a
> "significant and sustained" contribution to Ubuntu is still required. If
> you don't have a nice set of SRUs that you have driven and have had
> straightforwardly sponsored, or you don't have existing uploaders who
> have sponsored your work and are ready to endorse you, you should
> probably continue getting SRUs sponsored and defer your application
> until you feel that you do meet these requirements.
>
> I hope this new team will help get good quality SRUs landed with less
> delay. And whether you are a member of this team or not, thank you for
> helping Ubuntu out.
>
> Robie
>
>
>
A warm thank you to the DMB and to Robie for handling this new addition. With
Dave Chiluk's addition, we now have two Core developers who will be available to
foster the new applications to this new team and keep the quality of our SRU to
the highest level of quality.

Kind regards,

...Louis

--
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer                       Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (857 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: new ~ubuntu-sru-uploaders team [was: Unblocking SRU uploader permissions]

Eric Desrochers
In reply to this post by Robie Basak-4
On 2017-02-28 07:57 AM, Robie Basak wrote:

> On Mon, Feb 13, 2017 at 07:09:12PM +0000, Robie Basak wrote:
>> Thank you for the discussion on this. I propose to go ahead and add a
>> new ~ubuntu-sru-uploaders team that can upload to any main or universe
>> package in any stable release in the usual way, but not to the
>> development release. The team would owned and managed by the DMB through
>> the usual application process. I believe the DMB has the remit to do
>> this, so I'm now asking for a DMB vote.
> The DMB approved this yesterday with four votes (unanimous amongst those
> who made the meeting).
>
> We agreed the following policy:
>
> To join ~ubuntu-sru-uploaders, the DMB expects:
>
> 1) a good track record of sponsored SRUs, a demonstrated understanding
> of SRU policies, requirements and process through that track record
> including driving SRUs through to the end, not letting things languish
> in -proposed;
>
> 2) endorsement from SRU sponsors [by this we mean regular sponsors who
> have sponsored the applicant's SRUs];
>
> 3) the usual requirements and expectations for any uploader;
>
> 4) plus [the application of the usual] DMB member judgement.
>
> There was some concern about potential bad uploads bothering the SRU
> team, so to mitigate this we also agreed that individual
> ~ubuntu-sru-uploaders membership will be removed if any of:
>
> 1) ~ubuntu-sru resolves to remove the member (how they do so is up to
> them);
>
> 2) or the DMB resolves to remove the member by a quorate vote, and a
> vote will be held if any member of ~ubuntu-sru requests it.
>
> I hope this will never be required, of course.
>
> I'll create the team and request that the TB add it to the appropriate
> Launchpad ACL when the first member's application is approved.
>
> I know there is significant interest in Canonical STS staff joining this
> new team, and I have been asked when to start applying and so on.
>
> I think it's fine to apply now, but to ramp this up gradually and be
> considerate to applicants applying for membership of other teams, I ask
> that the DMB handle a maximum of one ~ubuntu-sru-uploaders application
> per meeting until any initial wave is done. This is in addition to the
> current two applications per meeting limit we have at the moment.
>
> Eric, as you already have an outstanding application that got held
> pending the resolution of this issue, do you want to apply first?
Yes, I'll prepare my application for the sru-uploader team for the next DMB meeting.

>
> To all potential applicants: please remember that we do still have the
> requirements as above. Since this team will grant Ubuntu membership, a
> "significant and sustained" contribution to Ubuntu is still required. If
> you don't have a nice set of SRUs that you have driven and have had
> straightforwardly sponsored, or you don't have existing uploaders who
> have sponsored your work and are ready to endorse you, you should
> probably continue getting SRUs sponsored and defer your application
> until you feel that you do meet these requirements.
>
> I hope this new team will help get good quality SRUs landed with less
> delay. And whether you are a member of this team or not, thank you for
> helping Ubuntu out. re
Thank you very much for you effort on this Robie. We really appreciated.
>
> Robie

--
Eric Desrochers
Software Engineer | Sustaining Engineering Team
Canonical Canada, Ltd
www.canonical.com | www.ubuntu.com


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: new ~ubuntu-sru-uploaders team [was: Unblocking SRU uploader permissions]

Robie Basak-4
On Tue, Feb 28, 2017 at 09:32:38AM -0500, Eric Desrochers wrote:
> Yes, I'll prepare my application for the sru-uploader team for the next DMB meeting.

The DMB considered Eric's application on 13 March and I'm pleased to
report that it was successful with a unanimous vote.

Eric is the first member of this new team. Welcome Eric, and thank you
for your contributions to Ubuntu!

I have documented the new team at:
https://wiki.ubuntu.com/UbuntuDevelopers#SRUDevelopers

I also made the executive decision to call the team
~ubuntu-sru-developers instead of ~ubuntu-sru-uploaders, since the team
does grant Ubuntu membership and this naming seems to match the scheme
used in existing teams better. Of course SRU uploads aren't exclusive to
this team; if you can upload to the development release for any package,
you can also upload that package to the stable releases for SRU review.
No change there.

On behalf of the DMB,

Robie

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: new ~ubuntu-sru-uploaders team [was: Unblocking SRU uploader permissions]

Eric Desrochers
Hi,

By any chance, do you guys know when my "SRU Developer" privileges will be effective ?

Regards,

Eric


On 2017-03-20 01:48 PM, Robie Basak wrote:

> On Tue, Feb 28, 2017 at 09:32:38AM -0500, Eric Desrochers wrote:
>> Yes, I'll prepare my application for the sru-uploader team for the next DMB meeting.
> The DMB considered Eric's application on 13 March and I'm pleased to
> report that it was successful with a unanimous vote.
>
> Eric is the first member of this new team. Welcome Eric, and thank you
> for your contributions to Ubuntu!
>
> I have documented the new team at:
> https://wiki.ubuntu.com/UbuntuDevelopers#SRUDevelopers
>
> I also made the executive decision to call the team
> ~ubuntu-sru-developers instead of ~ubuntu-sru-uploaders, since the team
> does grant Ubuntu membership and this naming seems to match the scheme
> used in existing teams better. Of course SRU uploads aren't exclusive to
> this team; if you can upload to the development release for any package,
> you can also upload that package to the stable releases for SRU review.
> No change there.
>
> On behalf of the DMB,
>
> Robie
--
Eric Desrochers
Software Engineer | Sustaining Engineering Team
Canonical Canada, Ltd
www.canonical.com | www.ubuntu.com



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: new ~ubuntu-sru-uploaders team [was: Unblocking SRU uploader permissions]

Robie Basak-4
Hi Eric,

On Wed, Apr 12, 2017 at 09:52:43AM -0400, Eric Desrochers wrote:
> By any chance, do you guys know when my "SRU Developer" privileges will be effective ?

This is waiting for the technical board to change the ACL. See the
technical-board list archive for details.

Robie

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment