Patch Statuses in Launchpad (re-visited)

[Daniel Holbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Emmet Hikory schrieb:
> Daniel Holbach wrote:
>> In those cases you can still use an empty upstream task to mark the bug
>> as "this affects upstream" - of course you need to check manually if it
>> was accepted upstream.
> <...>
>> Reinhard Tartler schrieb:
>>> I'd be interested to know how many bugs with patches are affected by
>>> these problems though.
>> Hm? Ask Sébastien how often he asks patch submitters to get their stuff
>> upstream first because the patches are just too big to carry them as a
>> delta.
>>
>> I think this is pretty common if you don't deal with "./debian/-only
>> patches".
> 
>     This is very upstream-specific.

Well, it's the "patch needs upstream review" case. :-)

> In cases where there are large
> active upstream communities (e.g. GNOME, KDE), this may make sense.
> For the vast majority of packages, upstream is relatively inactive, or
> even if active, unlikely to make a release within the next six months.
>  While patches are appreciated, they often do not get review, so much
> as belated integration.  There are also a number of packages for which
> upstream is unwilling to consider a patch (even for a bug that makes
> the package unusable) if it is not submitted against VCS trunk (in
> some cases where there has been no release in > 1 year).

I'm not sure I can agree with your view on how most upstream developers
deal with their code, releases and patches.

In most cases a new release is not even necessary, a "yes, this looks
good - go ahead and apply it for version x.y.z" is good enough. The
point is that we have patches where we are not the best to judge if it's
good to integrate it - in all cases upstream are the ones with the best
knowledge of their own code.


>     Note that some of this is mitigated by considering Debian
> upstream, and working with Debian maintainers to get patches into
> Debian, but there are some cases where changes required to prevent
> FTBFS in Ubuntu would cause FTBFS in Debian, or similar arrangements,
> even outside debian/.  Further, not all Debian maintainers are very
> active, and applying a patch in Debian when a maintainer is away can
> be very complicated for those not familiar with Debian processes.

Some documentation on when to forward which portion to whom would be
great. As a rule of thumb: if a patch only concerns ./debian/ it might
make sense to send it to Debian too - depending on
https://wiki.ubuntu.com/UbuntuPackagingChanges else it's good to let
upstream know about it or ask them for advice.


Maybe I should have made this clearer in my initial proposal. As I see
it, there are a few reactions we can have towards submitted patches:
 - it's OK - upload it (and ask to send it to Debian/upstream)
 - it's NOT OK - we ask for clarification, a fix or a rewrite
 - we don't know - we ask Upstream for advice

I can't tell how often which case will occur, but we should have a
solution in place that can deal with all of them and that does not lose
us information.

"bugs-with-patches-attached ZERO" FTW!

Have a nice day,
 Daniel


- --
My 5 today: #234288 (grub2), #234992 (apturl), #235373 (mtools),
#229864 (ttf-unfonts), #234457 (ygraph)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIPRWORjrlnQWd1esRAhJLAJ9/053d7rvCb5+o5mxm+POUIsUdSACfcEqO
kMoWQctXH41nRzSRK+K0ums=
=vbiT
-----END PGP SIGNATURE-----