Streamlining package set management

[Micah Gersten]

On 11/05/2011 07:43 AM, Mark Shuttleworth wrote:
> On 10/10/11 21:27, Iain Lane wrote:
>> An issue highlighted in the developer survey was that package set
>> management is a bit too bureaucratic. We just discussed this at the DMB
>> meeting[0] and I proposed some relatively minor changes to the process
>> that should streamline it a bit.
>>
>>   - As a matter of policy, each package set has a single uploader, which
>>     is a team. The DMB can either handle applications to the team or
>>     delegate to an appopriate council if one is set up.
> Can the upload processing system handle multiple uploaders/teams? If so,
> then the DMB also has the option of compositing teams. I say this
> because we've generally found it's better to have an ACL than to try and
> construct a new team every time you want to give a permission to two teams.
Yes, but this is only possible for the TB.  The idea is that this
packageset team can have multiple teams as members, so the TB only has
to modify the ACL once.  This also makes it easier to see at a glance
who can upload this packageset.
>>   - Applications for new package sets must come with some clear criteria
>>     that the DMB can apply when adding subsequent packages in future.
>>     The criteria must make it clear how the DMB is to check whether
>>     proposed additions are suitable. The criteria forms part of the
>>     package set application, along with the initial list of packages,
>>     and will be recorded in the uploader team's description.
>>   
>>   - Package additions are done by requesting on devel-permissions. Any
>>     DMB member will check against the criteria and add if it matches (or
>>     feed back if not).
> Similarly, can a package be in multiple package sets? It should be
> possible, and if so, the DMB might also want to check if adding the
> package to the packageset would impact on other teams, and ensure
> there's mutual awareness and coordination.
Yes, a package can be in multiple packagesets.  This is a very good
point that uploaders need to be considerate of others that can be
affected by the package(s) in question.  The DMB should also be careful
when deciding to add a package that not only it's appropriate to be in
the packageset, but that these uploaders are capable of understanding
the impact the package might have on others.
>>  - (Added since the meeting) Requests for package additions will be
>>     aged for three(?) days on devel-permissions, in order to allow time
>>     for DMB members to object. If there are objections that cannot be
>>     resolved over email then the matter will be taken to the next DMB
>>     meeting.
>>
>> TB & DMB, what do you think of this?
> +1 from me, apologies if that comes too late to be useful.
+1 from me as well, although, I'd like to have it be one week.  Some
people don't check their Ubuntu E-Mail on weekends and I would think
some only check their Ubuntu E-Mail on weekends.  In addition, I think
the DMB should make sure that affected existing teams are copied when a
request like this is made and the time limit in question should start
once they are copied.  We're not necessarily bound by their feedback,
but there could be a piece of information we're missing.  Should the
team(s) not object, I'd suggest we take action a week after the initial
mail was sent.

Thanks,
Micah