[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: extensive patching

Barry deFreese wrote:

> > 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" ?

By having a large diff against the upstream source with changes
unrelated to packaging.

> > 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? 

If upstream is dead or unable to do his job well, somebody should fork
the project (or take ownership). But this has nothing to do with
packaging software and should in my opinion not be intermixed.
> Also, obviously, there are changes that make no sense to
> upstream that are strictly distro specific.

Requiring distro specific changes feels wrong anyway.
Software should be coupled by standardized interfaces.
But I might be naive here. What are the distro specific
changes we are talking about?

> 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 think there should be a policy. I propose:

> > 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?

Fork it. But not as part of the packaging work.

> > > 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.

Upstream answered that it is okay too remove the seeding of the PRNG
with uninitialized memory, but the concrete patch which additionally and
erranously removed all seeding was never posted on openssl-dev.


Attachment: signature.asc
Description: Digital signature

Reply to: