Re: extensive patching

[Barry deFreese <bddebian@comcast.net>]

Martin Uecker wrote:
> little.miry@gmail.com wrote:
>
>   
> > I disagree. The cause of the disaster was not that Debian does its own
> > patching, but the fact that that patch was buggy.
> >     
>
> Buggy patches happen all the time. The question is, how could 
> something as bad as this slip through? And one important
> reason is IMHO, that splitting up the development/bug fixing/review
> by creating different software branches is bad.
>
>   
Different software branches in what respect?  Just by nature of having a 
distro "package" ?
> > On the whole I think that Debian benefits a lot from custom patches,
> > and in fact many packages would be severely buggy and/or wouldn't
> > integrate properly with the rest of the system without them.
> >     
> > It's not a secret that many projects benefit from Debian patches, 
>   
> > so there might be something good with them. 
> >     
>
> Clearly, Debian adds value by its patches. If those patches would be
> integrated upstream, then the whole free software community would 
> benefit. 
>
>   
Which brings up at least two issues.  Upstream not wanting the patches 
or dead upstream.  Speaking from the games team alone I would bet that 
50% or more of the packages have no upstream anymore.  Should those 
packages be removed?  Also, obviously, there are changes that make no 
sense to upstream that are strictly distro specific.

> > Also, I don't think we should always wait for upstream's new releases 
> > for adding them if we have them available. It might depend on every case.
> >     
>
> I would prefer if only security fixes and bugs which might cause
> data loss would fixed directly in Debian. Everything else should
> go upstream first. 
>
>   
Sounds good but again, what about unresponsive/dead upstreams.  Do you 
leave your users to "suffer" ?  Is Debian here to service the user 
community or not?
> > Maybe there's a problem with the fact that some of those patches are
> > just reviewed by just one person, but then again, I seriously think
> > that it would have been quite difficult to discover that there was a
> > problem with this one. The proof that it wasn't evident is not only
> > that upstream didn't see the problem either, nor any other developer
> > or derivative distribution or independent reviewers in 2 years.
> >     
>
> Did you look at the code? This was not exactly a deeply hidden flaw
> in some obscure looking code. Upstream didn't see the patch. That's 
> exactly the problem. And I doubt that there was any review of this code
> in all this 2 years.
>
>   
I have seen links where "upstream" was asked about/notified of the patch 
so this isn't an entirely true statement.  Egos play a big part in all 
of this as well.

> <snip>
> > Of course, the development and checking of the patches should be done 
> > as cooperatively with upstream as possible, as upstream might see 
> > something we're not seeing, but the way to the solution, in
> > my opinion, is not to avoid patching but to develop a way to check
> > them as extensively as possible.
> >     
>
> Checking something extensively is much easier if there
> is one canonical branch which everybody agrees on.
>
>   
Sounds like Utopia but I can't see it happening.
> Regards,
> Martin
>
>   
Barry deFreese