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

Re: NEW handling ...



On Wed, Mar 16, 2005 at 04:21:56AM -0500, Joey Hess wrote:
> Sven Luther wrote:
> > After reading the mention of it in debian-weekly-news, i read with interest :
> > 
> >   http://kitenet.net/~joey/blog/entry/random_idea_re_new_queue-2005-03-02-21-12.html
> > 
> > And i am not sure to get the hang of it.
> > 
> > You mention that not all packages will be able to do go to this new.debian.org
> > archive, but that not-really-new packages are good candidates. How would one
> > decide, is it the maintainer doing the upload who takes the decision ?
> 
> Yes of course, the same as a maintainer makes that decision before
> putting a NEW package up on people.d.o right now.
> 
> > will there be an automated check during initial queue processing (for new binary
> > packages for a same source package for example, or wildcarded packages for
> > soname changes or kernels) ?
> 
> As far as the idea goes, I guess DD's who care about speeding that up
> could automate or semi-automate their advocations for such packages in the
> new queue. (If they weren't throttled.)
> 
> > Also, i don't understand what you get more this way, apart from added
> > bureaucrazy, over simply accepting not-really-new packages out-of hand
> 
> My idea is not particularly targeted at that, it was more trying to
> see how we could decentralise the whole new queue processing issue. I
> don't really understand the benefits of requring NEW processing for
> binaries, so I'm not going to try to second-guess the ftp-masters on it.

Ah, so your proposal is fully for really-new-packages, and the only problem
would be for package that contain potentially licence or patent issues, which
makes it impractical in the first place.

A solution for this would be to place all NEW package (which are really-NEW,
the not-really-NEW ones would be automatically processed) in a server outside
the US (so as to not have to care for stupid crypto export rules), and in an
area needing a valid DD signed key to access it. In this way we could claim
they are used for internal review, and not trip any legal problems at all for
illegally distributing them. Then we can base your vote system on this for NEW
packages, again with a week or whatever is judged reasonable delay so the
ftp-master can review and oppose the decision of a certain amount of
developers.

Ideally we would see forming a little NEW-reviewing comittee which would
facilitate the job of the ftp-masters. This is also in accordance of the
small-team proposal in debian.

It would be nice to have the opinion of the ftp-masters on this, if this seems
credible, and if there are design issues with it.

Friendly,

Sven Luther



Reply to: