requesting for changes to be sent to debian before sponsoring an upload

[Jordan Mantha]

On Thu, Jun 19, 2008 at 6:35 AM, Sebastien Bacher <seb128 at ubuntu.com> wrote:
> Hello everybody,
>
> Everybody will agree that sending changes to Debian is good thing, we
> still have many packages that could be in sync but are not though
>
> One example from today's upload:
>
> " libofx (1:0.9.0-2.2ubuntu1) intrepid; urgency=low
>  .
>   * Merge from debian unstable, remaining changes (LP: #238266):
>     - Rebuild with libcurl4-gnutls (change build-depends from
>       libcurl3-gnutls-dev to libcurl4-gnutls-dev).
>     - debian/control: Change Maintainer to XSBC-Original-Maintainer."
>
> I don't want to point anybody there, but that's typically the sort of
> change which should have been sent directly to Debian so we could have
> this package in sync again

I would think that pretty much every Ubuntu developer agrees with the
desire to get things upstream. However, there is a fair amount of
variance in how strong of a desire :-) Especially as we are fast
approaching DIF, if we have one shot at touching a package it's better
to carry the divergence in almost all cases.

> The issue is partially an educational one and that's why I would like to
> suggest to change the sponsoring policy to request to have changes which
> make sense for Debian sent to the bts (and bonus points if you send
> those upstream and tag the distribution patches too) before sponsoring
> an upload, this way we don't create delta and contributors learn that
> sending changes to debian and upstream is useful
>
> What do other people think about the idea?

Well, it sounds good on paper, but in practice it's not nearly so
black-and-white. In Universe at least, many Debian maintainers are
"dead" (we're merging NMUs) or quite unresponsive (we won't have time
to sync again before release) or are busy with a new release (Debian
tends to not take patches as readily when they're trying to freeze) so
I would have a really hard time blocking perfectly good packages from
being uploaded because of that. Additionally, it's not always easy to
gauge responsiveness ahead of time. The same issues can crop up with
working with upstreams. Many don't use bug trackers, some not even
mailing lists. It can be overly time-consuming to push changes in
these situations.

While I totally agree that contributors should learn that sending
changes upstream is good, we also don't want them to learn that we are
Draconian and unflexible. Can we set some sort of "bar" where we can
"give up" and carry the divergence? Something like "file a bug in BTS
and if you don't get anything within a week we'll upload" perhaps? The
problem with that is that means that the package enters the
sponsorship queue twice, which is not good when we're trying to get
through the current queue even once. Any other ideas?

-Jordan