On Tue, Jun 11, 2013 at 07:04:30AM -0400, Stephen M. Webb wrote: > > Normally you would keep the old version's changelog. But even if you don't, > > there's no need for an ITP in cases like this, or when part of a package starts > > to be shipped from a different source upstream. It's like opening an ITP for > > every upstream release. You can still do it but people are going to complain if > > it starts to happen very often... > Perhaps what is not clear is that there is no old version. The SDL2 family of libraries is not a new version of the SDL > family of libraries so much as a new set of incompatible libraries serving the same purpose, from the same people. > There is no common code base and the libraries are one hundred percent parallel-installable. Ah, then this is a different case and I agree that it deserves an ITP. > I for one appreciate seeing an ITP for the long-anticipated libsdl2 packages, so at least I know someone is intending to > package them. It may not be Policy to require closing a bug when putting a package on the NEW queue, but it's > established documented practice. After all, isn't that one of the purposes of filing a bug against WNPP? I see ITP bugs as an (albeit advisory) locks on new upstream software, that are just meant to prevent duplicate independent work on packaging. I also think that nothing except for the new-package-should-close-itp-bug lintian tag requires you to file ITP bugs and the only thing that this tag is based on is devref 5.1, which lists only several non-technical reasons to do this. In other words, uploading a NEW package should be preceded by filing an ITP only in most cases. (on a side note, this advisory locking mechanism fails, as new packagers sometimes file ITP bugs either after running lintian on an almost finished package or just ignore the tag completely and there is no other technical way to force them to file ITP bugs/look for existing ones before starting to work on a package) -- WBR, wRAR
Attachment:
signature.asc
Description: Digital signature