On 08/03/22 at 16:11 +0200, Adrian Bunk wrote: > On Tue, Mar 08, 2022 at 11:39:04AM +0100, Andreas Tille wrote: > > Hi Adrian, > > Hi Andreas, > > > Am Mon, Mar 07, 2022 at 11:42:42PM +0200 schrieb Adrian Bunk: > >... > > > lintian already warns or has info tags that should be upgraded to warning, > > > > I absolutely agree here. > > > > > and then there will be slow migrations usually happening when someone > > > anyway does (and tests!) larger packaging changes. > > > > This "someone anyway does larger packaging changes" did not seem very > > probable for the packages I've touched (see my other mail in this > > thread). > > > > > Ensuring that all relevant lintian tags are warnings would be the > > > appropriate action (which is not yet true[1]), but there is no urgency > > > on getting everything "fixed" immediately. > > > > I agree that there is no real urgency for immediate action - but this > > seemed to be the case for other bugs on the packages I've touched the > > case as well. > > what time frame do you have in mind when you write "no real urgency" > and "did not seem very probable"? > > For me a reasonable time frame for changes that are neither urgent nor > supposed to create user-visible changes in the binary packages would be > to ensure it is a lintian warning now, and then wait 10 years. > > Many maintainers touch their packages at least once per release cycle > and also check lintian warnings, so many packages will get fixed within > the next 1-2 years. > > Most packages will get a new maintainer or a new team member in an > existing maintainance team within the next 10 years, and with the > help of a lintian warning this is the natural time for doing such > changes.
Hi, I believe that the arguments in favor of this MBF fall in three categories: 1/ the arguments about using patches to track changes to upstream code. Among the ~600 packages in that potential MBF, there are still many that make changes to upstream code, which are not properly documented. I believe that it is widely accepted that seperate patches in debian/patches/ are the recommended way to manage changes to upstream code (good way to help with those changes getting reviewed, getting merged upstream, etc.) 2/ the arguments about other advantages of the 3.0 (quilt) format: newer compression algorithms, multi-tarball support, debian/ dir in upstream code, etc. (but I agree that those arguments don't work well here, because the packages in question don't seem to need those improvements) 3/ the arguments about standardization/simplication of packaging practices, that make it easier (1) for contributors to contribute to any package (think security support, NMUers, but also derivatives); (2) to develop tools that process all packages. You argue that it's fine to wait 10 years for a transition such as the switch to 3.0 (quilt). Actually, it has already been 11 years, since 3.0 (quilt) was introduced around 2011 (see https://trends.debian.net/#source-formats ). What we are talking about here is the "end game": there are less than 2% of packages in testing that are still using 1.0, and many of those look abandonned or of relatively low interest (see https://people.debian.org/~lucas/format1.0/packages.txt ). I'm pushing for it now because I believe that it is a good timeframe to finish that transition before the release of bookworm. Yes, it requires some effort, and some maintainers might make mistakes and introduce bugs in the process. However (1) if we start that work now, we still have plenty of time to uncover issues before the bookworm freeze; (2) if the maintainers use this opportunity to modernize the packaging, switch to the best current practices, and for example add tests to their packages, it also means less bugs in the future. Lucas
