FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-16-2008, 12:27 PM
Neil Williams
 
Default Should SONAME bumps always go through NEW

On Wed, 2008-04-16 at 13:34 +0200, Bas Wijnen wrote:
> On Wed, Apr 16, 2008 at 01:08:05PM +0200, Ondrej Certik wrote:
> > if I want to packge a new upstream version of DM-Upload-Allowed
> > library (for example [1]), it changes the name of the binary package
> > and thus goes to NEW.
> >
> > Last time I asked it wasn't possible for me, as a DM, to upload it and
> > I had to search for a sponsor.

(and that is just as it should be).

> > Is there some policital reason for that,
>
> Yes. DMs are not as thoroughly checked as DDs, and thus have less
> rights to change things in the archive. The idea is that they should be
> allowed to upload packages they already maintain, but not add new ones.
> This is true both for new source, and new binary packages.

What kind of new binary package can be more disruptive than a SONAME
bump??? The restrictions exist for good technical reasons. SONAME bumps
need careful management across a number of different packages.

> A library soname transition is a binary package name change for
> technical reasons. IMO there isn't really a good reason to send them
> through NEW at all, but that's how the scripts work.

It does give others watching NEW a chance to see a pending transition -
bumping a SONAME should not be done lightly (especially now). I think
that is a good reason.

> If you can build consensus on the fact that soname bumps shouldn't go
> through NEW, then you could implement that technically.

Personally, I think that SONAME bumps in NEW get "fast-tracked" through
the queue anyway and I think it is a worthwhile safeguard that should be
retained. If SONAME bumps are not to go through NEW in the future, I
think it should be mandatory that SONAME bumps go through some other
"holding" phase instead - there should be technical restrictions on
library transitions and that DM's should still not be allowed to make
uploads that involve a SONAME bump. Such a "holding" phase would just be
another name for NEW anyway, hence I think it should stay as-is.

Dropping this merely for the convenience of DM's when the real problem
is delays in NM is trying to fix the wrong problem in the wrong place,
IMHO.

> But I don't
> think you will be able to. In fact, most people might well think that
> soname bumps should indeed go through NEW, and that that is not a bug.

:-) Most definitely not a bug, IMHO.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 04-16-2008, 01:59 PM
"Ondrej Certik"
 
Default Should SONAME bumps always go through NEW

On Wed, Apr 16, 2008 at 2:27 PM, Neil Williams <codehelp@debian.org> wrote:
> On Wed, 2008-04-16 at 13:34 +0200, Bas Wijnen wrote:
> > On Wed, Apr 16, 2008 at 01:08:05PM +0200, Ondrej Certik wrote:
> > > if I want to packge a new upstream version of DM-Upload-Allowed
> > > library (for example [1]), it changes the name of the binary package
> > > and thus goes to NEW.
> > >
> > > Last time I asked it wasn't possible for me, as a DM, to upload it and
> > > I had to search for a sponsor.
>
> (and that is just as it should be).
>
> > > Is there some policital reason for that,
> >
> > Yes. DMs are not as thoroughly checked as DDs, and thus have less
> > rights to change things in the archive. The idea is that they should be
> > allowed to upload packages they already maintain, but not add new ones.
> > This is true both for new source, and new binary packages.
>
> What kind of new binary package can be more disruptive than a SONAME
> bump??? The restrictions exist for good technical reasons. SONAME bumps
> need careful management across a number of different packages.
>
> > A library soname transition is a binary package name change for
> > technical reasons. IMO there isn't really a good reason to send them
> > through NEW at all, but that's how the scripts work.
>
> It does give others watching NEW a chance to see a pending transition -
> bumping a SONAME should not be done lightly (especially now). I think
> that is a good reason.
>
> > If you can build consensus on the fact that soname bumps shouldn't go
> > through NEW, then you could implement that technically.
>
> Personally, I think that SONAME bumps in NEW get "fast-tracked" through
> the queue anyway and I think it is a worthwhile safeguard that should be
> retained. If SONAME bumps are not to go through NEW in the future, I
> think it should be mandatory that SONAME bumps go through some other
> "holding" phase instead - there should be technical restrictions on
> library transitions and that DM's should still not be allowed to make
> uploads that involve a SONAME bump. Such a "holding" phase would just be
> another name for NEW anyway, hence I think it should stay as-is.
>
> Dropping this merely for the convenience of DM's when the real problem
> is delays in NM is trying to fix the wrong problem in the wrong place,
> IMHO.


Thanks for the reply. As I said, I am not questioning new SONAME bumps
going into NEW.

The question is, whether the DMs should be allowed to upload SONAME
bumps to NEW by themselves or not. I agree there should be a special
attention to SONAME bumps and that's what the NEW is for (or any other
queue as you said).

It's all about how much trust you give to DMs. Imho if they are
allowed to upload new revisions and even new upstream (if the name of
all the binaries and the number of them stays the same), they can
screw up a lot of things. So giving them the right to also upload new
binary packages to NEW imho belongs to the same cathegory. Either you
trust him to maintain the package, or not. Imho.

Ondrej


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org