Upstream

[David Farning]

On Mon, 2007-02-19 at 00:18 +0100, Alexander Sack wrote:
> 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 successfully
> > 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. 

agree, "if we accept (or we successfully push the patch upstream)" both
depend on mozilla approval


> However, as downstream cannot distribute patched firefox package
> without re-branding 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.

agree, hence the phrasing "valuable common patch." If it is not of use
to Ubuntu their is no need for us to worry about it further.  If
downstream feels the patch is valuable to them.  They will need to have
it approved them selves or re-brand.


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

> k the contributor to submit them to upstream on their
>   own. 

agree all above

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

Was not referring to code, rather to passing issue reports upstream.  I
was including all of our different upstreams here.  Mozilla, Sun, FSF,
Adobe...  I believe that we should start by attempting to work with all
of the different organizations to push issue reports upstream.  Thus, we
can in good faith attempt to fix all issues users come across. If any of
these organizations are not interested in accepting reports from us, we
will have to consider tagging issue reports to their product 'can't
fix.'  

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

Ahh. I think I see our misunderstand.  My concern is with organizations
that are value added resellers.  I am hesitant to have the users of
derivative distros report issues directly to our issue system.

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

I don't mean to imply a special system for us.  I mean that a derivative
_should_ have it's own issue tracker.  Downstream triagers should make a
reasonable effort to bring the issue to the needconfirm state before
pushing it up to us.

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

This starts with the launchpad integration mdz was talking about last
week.  Most applications in Ubuntu have a 'report bug' item under the
help menu.  Martin has extended apport to cause this to automatically
file a bug report.  This automatic report already provides has some
general system information.  We can extend the information collected on
a package by package basis using package-hooks.  Thus, when the bug is
filed most of the commonly requested information will be already
provided.

The next step is to get retrace working correctly.  Crash reports are
not particularly helpful without debug symbols.  We need to get to the
point were we can a least manually run retrace against our crash
reports.  I don't think this will be all that difficult.

The third step will be running bug helper against our correctly
symbolized issue reports.  Bug helper can look at the contents of
attachments.  While triaging, this will allow us to look across bug
reports for similarities.  Once identifying characteristic of a bug are
identified we will be able to quickly identify duplicates. 

thanks
-- 
David Farning <dfarning at gmail.com>