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

Re: clarify FTP master delegation?



Daniel Pocock writes ("clarify FTP master delegation?"):
> The FTP team wiki[1] links to a delegation email[2]
> 
> The delegation email is very light, it just says they are "Accepting and
> rejecting packages that enter the NEW and byhand queues" without any
> reference to the policies they should apply

That means that it is for the FTP team to set that policy.

> The wiki talks about their policies (which are well known to most
> developers), with some comments about the familiar NEW queue:

AFAIAA this is the best description of the FTP team policy:
  https://ftp-master.debian.org/REJECT-FAQ.html

> My impression is that the type of issue currently under discussion is
> not adequately specified in the FTP master delegation, it leaves the FTP
> masters to do more work on something that is actually quite complicated
> and has far-reaching ramifications for the project.  It also means the
> FTP masters are in a situation where whatever they do, some people will
> feel they either did the wrong thing or some people will feel the FTP
> masters were wrong to make any decision without the project having a
> policy on the matter.

I am very happy that the FTP team are making these kind of decisions
for the project.  I definitely don't want the DPL to intervene (for
example, by making the FTP team delegation more prescriptive).

> The absence of policy on this also has other ramifications: for example,
> a DD could upload a non-controversial v1.0 of a package, receive FTP
> master approval and then later v2.0 comes along with controversial
> content and according to the wiki, it will be automatically accepted.

This is surely done for convenience, not as a matter of policy.  If
you are aware of an instance where a package which has already gone
through NEW has been replaced by a new version which the FTP team
would have rejected, you should surely bring this to the FTP team's
attention (probably by filing a bug).

Ian.


Reply to: