On 19 May 2008, Juliusz Chroboczek verbalised: >>> 1. You did apply a patch relating to security without an explicit ack >>> From upstream. > >>> I hope it is clear from the recent OpenSSL debacle why this must not >>> be done. > >> Sorry, but no, it isn't. > > Julien, you're trolling. Among the DDs I know, you're one of the most > active in making sure your non-trivial changes end up upstream.
As an aside, in the specific instance of the OpenSSL patch, the maintainer *did* get an ack from upstream. Another member of upstream disavowed the ack ack after the hole was uncovered with the ridiculous claim that their development list was not in fact the list on which development was discussed, despite claims to the contrary on their own webpage and in the OpenSSL source tree. It's all really quite grotty and nobody comes out of it looking very good. > Let me restate this: debian/patches/ is a way for lazy maintainers to > short-circuit the proper patch submission procedures of an upstream > project. Proper procedure, as obeyed by quality DDs, among which > I count [EMAIL PROTECTED], is to go through the normal upstream > channels. Heh. This very much depends on the project. An awful lot of upstreams are *much* less responsive than you are, are outright dead (e.g. Vixie cron), respond to patches with an explosion of not-invented-here syndrome, or simply have intense biases against e.g. patches which allow portability to particular platforms, regardless of their technical merits (I could name names of major package upstreams with all these attitudes, some with more than one of these at once). The proper relationship with upstream depends on the maintainer and on the upstream. There is no one right way, although obviously what you describe is one type of ideal relationship. (The most extreme case has the package maintainer and the upstream as the same person, as is the case with e.g. e2fsprogs in Debian.) -- `If you are having a "ua luea luea le ua le" kind of day, I can only assume that you are doing no work due [to] incapacitating nausea caused by numerous lazy demons.' --- Frossie ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Polipo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/polipo-users
