Re: Re: Canonical's business model
On 1/15/06, Martin-Éric Racine <q-funk@iki.fi> wrote:
> > Many patches are submitted via the BTS, though not every patch published in
> > the patch archive is submitted this way, for reasons which have been
> > discussed to death in previous threads.
>
> What I think could be done in a significantly better way is for Ubuntu
> to have an explicit commitment to always discuss with the "upstream"
> Debian maintainer of a package before introducing an Ubuntu-specific
> diff, especially in cases where the patch would likely benefit Debian.
>
> This could take the form of an extra paragraph in the Ubuntu community
> pledge (I forgot exactly how it's called, sorry) that people must sign
> before being allowed to contribute packages to Ubuntu. That paragraph
> would state that:
I think you mean the ubuntu code of conduct. I think it is out of its
scope, but I nevertheless really think they are good ideas.
> 1) diffs should be avoided unless absolutely necessary and
I completley agree with this.
> 2) such divergences from the Debian package must always be discussed
> with the Debian maintainer and submitted as a patch to the BTS, before a
> decision is made to fork.
This has been problematic in the past with some (unresponsive)
maintainers in the past. This, and the fact that ubuntu has strict
deadlines which are not easy break lead to the necessity, to introduce
hopfully temporary divergence. This is what I call 'unneeded
divergence', which should be avoided or even better fixed, where
possible.
> 3) Debian should be treated as upstream, meaning that the Ubuntu
> developer that decided to fork must track the Debian package and
> contribute patches on a regular basis, just like the Debian maintainer
> would with the upstream developer of software he packaged for Debian.
>
> The explicit goal, in both cases, is to reduce diffs and streamline the
> task of merging useful patches from Ubuntu.
This is what I'd also like to establish. There are practical reason,
why this is not acheivable in the near future: First, the line if a
patch is worth submitting is not sharp. Often, it is not clear if a
patch is really worth submitting to debian, or if the DD would be
rather annoyed. Second, many of us do not have the same training,
skill and experience as Debian Developers. So a misestimation about
the situation is not that unlikley. Third, the deadlines about freezes
do create in noticable abount of pressure to get a somehow working
package in the archive, even though it is technically not the best
solution. Forth, MOTUs are notorously understaffed.
That said, I completley agree that the universe team should make
'reducing divergence from debian' one of the top objectives. There are
indeed people (including me) working on improving workflows in order
to reduce divergence for the profit of both projects.
One first step could be indentifying the types of divergence we
introduced. After that, we (as in the motu team) can systematically go
through the package lists and work on reducing divergence.
> Here's two examples of where such a course of action could have been
> useful, taking two of my own packages as an example:
>
> 1) rus-ispell
>
> Patched by doko to introduce a new upstream release. Never submitted to
> the BTS and required asking #ubuntu-motu to manually sync to my recent
> uploaded of an even newer upstream release, after repeated attempts to
> contact doko failed to produce results.
>
The current procedure of syncing packages is via requesting them via
email or irc. As I understand this is going to change with the switch
of our infrastructure from katie to soyuz. This can faciliate issues
like this.
> 2) numlockx
>
> Patched by Reinhard Tartler to adjust compile paths for X.org 7.0 libs.
> Never submitted to the BTS and unnecessary since, as pointed out by a
> recent message from the X Task Force, the proper way to do this is to
> relibtoolize against autoconf version greater than 2.59a-4.
Right, I have to apoligize. That time, I didn't know about the
necesity about the autoconf/libtool issue, now I know better. In the
mean time, according to the changelog, the package looks to me
unnecessarily diverged. I think it should be synced on the next upload
to sid.
> Thus, I think that if Ubuntu placed an obligation upon its developers to
> always try discussing with the Debian maintainer before patching, a lot
> of unnecessary diffs could be avoided, just like in the above two cases.
(most) ubuntu developers are just like debian developers volunteers.
The code of conduct seems to be out of scope for such an obligation,
since it applies to all ubuntu members, not just developers. It should
be actively encouraged, though.
> Just my two bits.
Thank you for your analysis and suggestions, I found them very encouraging.
--
regards,
Reinhard
Reply to: