On Thu, Oct 25, 2012 at 7:19 PM, Russ Allbery wrote: >> As I've said many times now, the liberal NMU would not be a license for >> packaging style changes. In fact, no NMU is allowed to make those >> changes (the fact that people are doing it is apparently a social issue, >> and solutions to those are hard). It is instead more of a license to go >> ahead and fix real issues with the package including new upstreams. > > I don't think adoption via liberal NMUs will work in the volume that we'd > like because they invert the natural workflow involved in improving a > package.
I think this is where language is important. In my opinion, the term "adoption" will continue to mean taking on full responsibility for a package as its new maintainer. The term "salvage", in my opinion, we can define as a process for becoming a co-maintainer on a package with a long-term possibility of becoming its maintainer. For adoption, the existing adoption processes will continue for those who prefer that approach. For salvaging, the new procedures will be available. > The first thing I want to do when adopting is to clean up the package, > modernize the packaging, sort through the patches and figure out which > ones are unnecessary or already merged, and get the package into a > maintainable state. *Then* I'd update to the latest upstream. Again, I think it comes down to language. If we view salvaging as a process that is initially meant to help the existing maintainer, then it makes sense to continue to work with the package as he/she intended. When the 3 month clock expires, and the salvager becomes an uploader, then any change becomes allowable. It may be that some salvagers will start out with some more minor work for the 3 months before becoming an uploader and jumping to a new upstream and at the same time they change packaging style, but then again some may want bump upstreams right away, and this process makes it possible for the person actually doing the work to decide their own fate. I think autonomy is incredibly important. That's what we did with wine, and it was entirely possible although not as pleasant (for us salvagers) than if we could have redesigned the packaging style. We wanted to work as well as we could with the existing maintainer to avoid conflict arising from changes that would modify the way things work that he was familiar with. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MMUgQf0JGfTCRioPErQqAvcbgSbgbSCAT8aVOw=+jf...@mail.gmail.com