Upstream

[Alexander Sack]

On Sun, Feb 18, 2007 at 02:00:43PM -0600, David Farning wrote:
> 
> In terms of patching, I would like to develop a relationship with those
> distros to push valuable 'common' patches upstream to us.  The benefit
> to us will be a regular supply of patches to improve our code.  The
> benefits for downstream is two fold, if we accept (or we sucsesfully
> push the patch upstream) they don't have to worry about carrying the
> patch forward in their code.  As our code base improves from all of the
> various downstream contributors, so will theirs.

We cannot take arbitrary patches, apply them and then ship an
upgrade without getting approval first. 

However, as downstream cannot distribute patched firefox package
without rebranding it, we can offer to do the upstream approval
process for them. Of course, those issues must be of relevance for
ubuntu as well; so we can only work for patches upstream that we want
to integrate on our own.

Just to give some guidelines
  1. we consider all patches that only affect our packaging work. So
  improvements on how we package our application or how we add desktop
  integration hints (e.g. .desktop files) are always welcome.
  2. for general gnome/ubuntu integration changes to the core codebase
  we will review each single issue and if we find that this feature is
  worth having, we will ask the author to provide a well documented
  patch which we will try to get approval for. Once this is done, we
  will integrate that patch so downstream distributors get their patch
  in the official branding firefox.
  3. for all other feature requests that affect the mozilla code base
  we kindly ask the contributor to submit them to upstream on their
  own. 

> 
> Issue triage is a bit more thorny be cause it is not so clear cut.  Just
> as we work to push good issue reports forward, we expect our directives
> to push good issue report up to us.  I am willing to start out working
> in good faith with everyone.
> 
> One of the reasons that I am interest in setting up the mozilla council
> is to set policies on how to work with third parties. For example, if a
> group shows unwillingness to work with us pushing 'good' issue reports
> up to them, I believe that it is reasonable to start rejecting their
> issues as 'can't fix.'  On the other extreme are organization who are
> interested in having some of the developers join the Mozillateam;)  In
> this case will need to develop kernel development like policies where we
> have the reputation of accepting 'good' code and rejecting 'bad' code
> whatever the source.

Code will be approved by mozilla. However, as long as downstream
distributors don't have their own agreement with mozilla, we can
mediate if they have a good patch.

> 
> Back to issue reports...  We will need to find the fine line between
> helping our downstream and being taken advantage of by having their QA
> issues dumped on us.      
> 

I don't think this is a real issue. If they report a bug properly,
then fine, there is nothing bad about it. We should process them in
the same way as bugs posted by "normal" ubuntu users.

However its in their best interest to help in order to get bugs
resolved they finally want to see resolved. But thats up to them and
imo we don't need a special procedure on how bugs are processed for
downstreams.

> This takes us back to our upstream relationship.  We should expect our
> downstream to treat us the same way we treat our upstream.
> 
> Forward good issue reports. Push patches, etc...
>  
> 
> With this in mind I would not like to push issues forward until they
> have make it through our needinfo process.  By the time an issue has
> made it through the needinfo process, it should have everything a
> upstream dev would need to find and fix the issues.  Hence my strong
> push towards automated issue processing.

Exactly. I think our normal procedures should be good enough to deal
with any kind of bug report. The more the reporter contributes the
faster a bug can be tackled. We don't need anything special for
downstreams, except that they are more likely to submit patches which
we need to approve upstream.

But what do you mean by "automated issue processing" ? Can you explain
a bit your ideas on that?

 - Alexander