Summary for the upload package rules GR

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

Summary for the upload package rules GR

Bill Allombert-3
Dear Debian voters,

I was asked to provide a summary of the current GR.  Please keep in mind
that the discussion period is over and that I am the proposer.

Background: for as long as a I am DD, developers were allowed to
perform binary-only upload. The FTP masters have removed this right for
ARM in December and alpha in January. I consider uploading packages to
be a basic developper priviledge and I don't think the FTP masters
have authority to remove it without the project approval.
The GR address that. (if the GR does not pass, I will assume that the FTP
masters have the project approval.)

Questions raised in the discussion period that are relevant to the GR.

Q) This GR is restraining the action of the FTP masters.

A) It does, but very minimaly:

  1) The FTP masters can still reject broken binary packages, as long as
  the reason is not merely the identity of the uploader.
 
  2) The FTP masters can still bar a rogue DD/buildd from uploading binary
  packages by blocking both sourceful and sourceless upload.

Q) This GR force the Debian Archive kit to accept packages that are
broken/without matching source etc.

A) It does not. The fact that a developer is allowed to upload a package
does not mean the package will be accepted, only that it will not be
rejected merely due to the identity of the uploader.

Q) The FTP masters will simply remove sourceful upload right on ARM and alpha!

A) I don't want to speculate on the FTP masters actions in this way.
People concerned about that should have proposed an amendment.

Q) We should only allow source-only upload!

A) This is orthogonal to this GR. If developers are not allowed to do
combined source and binary packages uploads, this GR is moot.

To conclude:

The GR says that developer are _allowed_ to do binary-only upload, it
does not says when they are appropriate and what policy should apply to
them. Theses are technical matters outside the scope of the GR. (The
same apply to sourceful upload obviously).

References for the technical aspect that motivate this GR:  

The post from James Troup "update on binary upload restrictions"
<http://lists.debian.org/debian-devel/2007/01/msg00760.html>).

My answer:
<http://lists.debian.org/debian-devel/2007/02/msg00241.html>

Cheers,
--
Bill. <[hidden email]>

Imagine a large blue swirl here.

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

Re: Summary for the upload package rules GR

Manoj Srivastava
On Sun, 4 Mar 2007 22:43:21 +0100, Bill Allombert
<[hidden email]> said:  


> Background: for as long as a I am DD, developers were allowed to
> perform binary-only upload. The FTP masters have removed this right
> for ARM in December and alpha in January. I consider uploading
> packages to be a basic developper priviledge and I don't think the
> FTP masters have authority to remove it without the project
> approval.  The GR address that. (if the GR does not pass, I will
> assume that the FTP masters have the project approval.)

> The GR says that developer are _allowed_ to do binary-only upload,

        Sorry, that is not what the GR actually says. The full tect of
 the GR, for reference is:
   The Debian project resolves that Debian developers allowed to
   perform combined source and binary packages uploads should be
   allowed to perform binary-only packages uploads for the same set of
   architectures.

        So, it says the lists of architectures for which a developer
 can do a sourceful upload has to be the same as the  list of
 architectures the developer can do a binary only upload.

        If there is a discrepancy in the two lists, it can be resolved
 two ways:
   a) Allow the developer to do bin uploads on the architectures that
      they can not,
   b) Remove their privilege to do a sourceful  upload on the
      architectures they can not do bin uploads for.

        In one case the develoeprs privileges are extended, an the
 other case the developers privileges are reduced; the GR gives no
 direction which action the ftpmasters must take.

        manoj
--
Live fast, die young, and leave a flat patch of fur on the highway!
The Squirrels' Motto (The "Hell's Angels of Nature")
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Summary for the upload package rules GR

Bastian Venthur-3
In reply to this post by Bill Allombert-3
Bill Allombert schrieb:
> Questions raised in the discussion period that are relevant to the GR.
[...]
> Q) We should only allow source-only upload!
>
> A) This is orthogonal to this GR. If developers are not allowed to do
> combined source and binary packages uploads, this GR is moot.

I've voted against the GR solely because of this reason. I think we
should aim for source only uploads in the long run, so consequently
voting in favor of this GR would be a step in the wrong direction.


Cheers,

Bastian

--
Bastian Venthur                                      http://venthur.de
Debian Developer                                 venthur at debian org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Summary for the upload package rules GR

Sven Luther
On Sun, Mar 04, 2007 at 11:41:26PM +0100, Bastian Venthur wrote:

> Bill Allombert schrieb:
> > Questions raised in the discussion period that are relevant to the GR.
> [...]
> > Q) We should only allow source-only upload!
> >
> > A) This is orthogonal to this GR. If developers are not allowed to do
> > combined source and binary packages uploads, this GR is moot.
>
> I've voted against the GR solely because of this reason. I think we
> should aim for source only uploads in the long run, so consequently
> voting in favor of this GR would be a step in the wrong direction.

Why did you not propose an amendment to the GR then, which allowe for
source-only uploads ?

Or propose a new GR on the subject ?

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Summary for the upload package rules GR

Julien Cristau-6
In reply to this post by Bastian Venthur-3
On Sun, Mar  4, 2007 at 23:41:26 +0100, Bastian Venthur wrote:

> Bill Allombert schrieb:
> > Questions raised in the discussion period that are relevant to the GR.
> [...]
> > Q) We should only allow source-only upload!
> >
> > A) This is orthogonal to this GR. If developers are not allowed to do
> > combined source and binary packages uploads, this GR is moot.
>
> I've voted against the GR solely because of this reason. I think we
> should aim for source only uploads in the long run, so consequently
> voting in favor of this GR would be a step in the wrong direction.
>
I fear you don't understand what "orthogonal" means.  This GR is neither
a step in the "right" direction, nor a step in the "wrong" direction.
It's completely unrelated to the issue of source-only uploads.

Cheers,
Julien

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

Re: Summary for the upload package rules GR

Frans Pop-3
In reply to this post by Bill Allombert-3
On Sunday 04 March 2007 22:43, Bill Allombert wrote:
> Questions raised in the discussion period that are relevant to the GR.

This summary is all very nice, but IMHO does not reflect what this GR is
about.

The background is that a number of developers saw a problem (an architecture
lagging somewhat behind) and found a creative solution to work around that.
This solution involved doing a big number of binary uploads, thereby
circumventing the official buildd network that is the basis for the quality
of our archive. The FTP-masters did not like that and decided to block
these irregular uploads.
Unfortunately the FTP-masters could not not block uploads only from the DDs
doing the mass uploads, but instead had to block all excluding a few. This
had an unfortunate effect on e.g. experimental builds.

Note that the binary uploads were not strictly necessary: the issues behind
arm and alpha falling behind were being dealt with. As we all know that
could have been communicated better, but the issues in question have not
caused any real problems, nor caused a delay in the release of Etch.

I do not think there is any basis to assume that the FTP-masters are trying
to block binary NMUs by porters in general, but I do know that they do very
much prefer that porter NMUs are only used if there is a very good reason.

What this GR is about that the DDs who originally started this creative
solution, together with a group who have long been discontent with the
FTP-masters are now trying to prevent the FTP-masters from doing their job:
guarding the quality of the archive.

I do agree with a lot of people that some changes in the way FTP-masters
(and DSA) work are needed, but I don't feel a GR like this is needed to
force that. I have a lot of respect for the amount of work that the
FTP-masters do and the general quality of that work.
What I would be very much in favor of is the addition of one or two new
members who start out as junior members with limited responsibilities (not
necessarily technically enforced), who are mentored by current FTP-masters
and who are allowed to gain their trust and thus gain more
responsibilities.

As I personally feel that this GR is a misplaced attempt from the
disgruntled DDs to get their way, I have voted for "further discussion".

Cheers,
FJP

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Summary for the upload package rules GR

Julien Cristau-6
On Mon, Mar  5, 2007 at 00:22:55 +0100, Frans Pop wrote:

> Unfortunately the FTP-masters could not not block uploads only from the DDs
> doing the mass uploads, but instead had to block all excluding a few. This
> had an unfortunate effect on e.g. experimental builds.
>
I'm not sure why you say they could not do that.  AFAICS it would have
involved a list of keys to block instead of a list of keys to allow, and
removing a "not" in a test, which doesn't seem all that complicated.

Puzzled,
Julien

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

Re: Summary for the upload package rules GR

Frans Pop-3
On Monday 05 March 2007 00:32, Julien Cristau wrote:
> I'm not sure why you say they could not do that.  AFAICS it would have
> involved a list of keys to block instead of a list of keys to allow, and
> removing a "not" in a test, which doesn't seem all that complicated.

OK. I may be wrong about that. I did not really look into the technical side
of it. Does not really affect the main points of my message though.

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Summary for the upload package rules GR

Bastian Venthur-3
In reply to this post by Julien Cristau-6
Julien Cristau schrieb:
> I fear you don't understand what "orthogonal" means.  This GR is neither
> a step in the "right" direction, nor a step in the "wrong" direction.
> It's completely unrelated to the issue of source-only uploads.

Maybe I just disagree with the independence between "don't allow
binary-only uploads" and "aim for source-only uploads". Forbidding
binary-only uploads *could* force us to improve our buildd net, which
would in turn bring us a step closer to source-only uploads.

After all I'd still prefer source-only uploads and don't see why I
should support the opposite, orthogonal or not.


Cheers,

Bastian

--
Bastian Venthur                                      http://venthur.de
Debian Developer                                 venthur at debian org


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Summary for the upload package rules GR

Aurelien Jarno
Bastian Venthur a écrit :
> Julien Cristau schrieb:
>> I fear you don't understand what "orthogonal" means.  This GR is neither
>> a step in the "right" direction, nor a step in the "wrong" direction.
>> It's completely unrelated to the issue of source-only uploads.
>
> Maybe I just disagree with the independence between "don't allow
> binary-only uploads" and "aim for source-only uploads". Forbidding
> binary-only uploads *could* force us to improve our buildd net, which
> would in turn bring us a step closer to source-only uploads.

This *could* also lead to removal of some architectures because the
corresponding build daemons are not maintained correctly.

> After all I'd still prefer source-only uploads and don't see why I
> should support the opposite, orthogonal or not.

That's also something I want to see, along with giving the right to at
least one porter of an architecture an access to the wanna-build database.

But we, as simple DD, can't decide about that.

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   [hidden email]         | [hidden email]
   `-    people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Summary for the upload package rules GR

Clint Adams
In reply to this post by Frans Pop-3
On Mon, Mar 05, 2007 at 12:22:55AM +0100, Frans Pop wrote:
> As I personally feel that this GR is a misplaced attempt from the
> disgruntled DDs to get their way, I have voted for "further discussion".

I personally feel that the changes to dak were a misplaced attempt by
the ftp-team to get its way.  How should I vote on this issue?


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Summary for the upload package rules GR

Manoj Srivastava
On Sun, 4 Mar 2007 20:27:08 -0500, Clint Adams <[hidden email]> said:

> On Mon, Mar 05, 2007 at 12:22:55AM +0100, Frans Pop wrote:
>> As I personally feel that this GR is a misplaced attempt from the
>> disgruntled DDs to get their way, I have voted for "further
>> discussion".

> I personally feel that the changes to dak were a misplaced attempt
> by the ftp-team to get its way.  How should I vote on this issue?

        I don't think the GR addresses your concern at all, since it
 could well be taken as a GR to force restriction of sourcefull
 upload privileges for all maintainers to match the already limited
 binary upload privileges on some architectures.

        manoj
--
Would a fly without wings be called a walk? George Carlin
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Summary for the upload package rules GR

Bill Allombert-2
In reply to this post by Frans Pop-3
On Mon, Mar 05, 2007 at 12:22:55AM +0100, Frans Pop wrote:
> On Sunday 04 March 2007 22:43, Bill Allombert wrote:
> > Questions raised in the discussion period that are relevant to the GR.
>
> This summary is all very nice, but IMHO does not reflect what this GR is
> about.
>
...
>
> What this GR is about that the DDs who originally started this creative
> solution, together with a group who have long been discontent with the
> FTP-masters are now trying to prevent the FTP-masters from doing their job:
> guarding the quality of the archive.
>
...
>
> As I personally feel that this GR is a misplaced attempt from the
> disgruntled DDs to get their way, I have voted for "further discussion".

I drafted and submitted this GR alone (with little internet access at
the time). I won't prejudge of the motivation of each seconders, but as
far as I am concerned the motivations I gave in the summary were
accurate. I take offense that you are implying this is not the case, and
that I am somehow part of some "disgruntled DDs" cabal with an agenda.
This is just your conspiracy theory.

To the voters:
--------------

I posted this summaries because some undecided developers asked me for a
summary in order to vote. I should probably have abstained to do that
especially since I drafted the GR this way to avoid tangential
discussions.

Apologies,
--
Bill. <[hidden email]>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]