Apport Hooks Task Force
sense at qense.nl
Thu Sep 24 10:45:19 UTC 2009
2009/9/21 Brian Murray <brian at ubuntu.com>
> On Mon, Sep 21, 2009 at 06:26:27AM -0400, John Vivirito wrote:
> > On 09/20/2009 10:00 AM, Sense Hofstede wrote:
> > > Hello,
> > > Recently Brian Murray asked for more Apport hooks to be added to as
> > > packages as possible, because of the choice for Apport as the
> > > way to report bugs. (For more information, have a look at the QATeam
> > > )
> > >
> > > The move away from the web interface ought to make our lives easier
> > > now more relevant information is (going to be) attached to bug reports,
> > > reducing the length of the correspondence, making bug triaging and
> > > more efficient. However, if we want to have the full benefit of the
> > > possibilities Apport gives us, we need to do some work.
> > >
> > > High-profile packages probably will get Apport hooks in time for the
> > > release, but there are many more packages that could benefit from both
> > > and symptoms. I therefore suggest to set up an operation that makes
> sure we
> > > do give as many packages as possible a nice hook.
> > > What should this operation do? The idea is to create an 'apport-hook'
> > > report bugs against all packages (that don't have a hook yet) and start
> > > watching the bugs. Then we can write hooks and watch the tag for bugs
> > > have a proper one attached. The Bugsquad could do the buggy part of the
> > > task, the MOTU and Ubuntu Developers can afterwards add the hooks to
> > > packages (and help writing them).
> > >
> > > If we'd get the greatest part of our archive to have Apport hooks,
> it'll be
> > > much easier for us to cope with the many bug reports that inevitably
> > > going to come when Karmic is released and we'd be able to learn how to
> > > with those kind of bug reports before the LTS will be there.
> > >
> > > Maybe it would be a good idea to devote a HugDay to this? It would at
> > > be useful to create a wiki page an send an announcement to explain the
> > > procedure of adding hooks to packages.
> > >
> > > 
> > >
> > >  https://wiki.ubuntu.com/QATeam/Specs/IncreaseApportAdoption
> > >
> > > Kind regards,
> > >
> > At the moment there is no hook for source package
> > lightning-sunbird. I have never written a hook and last i
> > looked (a while ago) and it looked hard to do. I lost link on
> > how to write them. If someone can give me an idea or example
> > it would be great. There are other Mozilla packages that are
> > missing hooks, however at this time i cant remember what ones
> > off hand. I'm on a honeymoon number 1. not sure when im going
> > to get back.
> I actually gave a class on this at the most recent Ubuntu Developer week
> and there is a log of it available. It has become much easier to
> write one with the convenience functions available in apport.
>  https://wiki.ubuntu.com/MeetingLogs/devweek0909/ApportPkgHooks
> Brian Murray @ubuntu.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> -----END PGP SIGNATURE-----
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at:
You're probably right about the problems that creating 16,000 bugs,
including bug reports against packages that don't need a hook at all.
I change my proposal: I suggest to devote a HugDay to Apport hooks. Instead
of pre-reporting bugs, instead we could encourage people to look at packages
of their choice(s) and write hooks for it. Afterwards a bug could be filed
against that package asking for the inclusion of that hook.
We can list all these bugs on the HugDay wiki page, but rather than one we
could add two name columns: one for the hook author and one for the uploader
of the pacakge with hook.
This could give Apport hook adoption a boost and is less work.
Still standing: what to do with Apport hooks after we've added them to our
packages? Should they be sent to the upstream projects or should they be
collected in a central directory for all distributions using Apport? Or
I would go for a central directory because that solution wouldn't require
upstream to include a piece of code that may be in a different language than
their project's and it wouldn't require them to maintain something using a
technology they might not be acquainted with.
A central directory would provide a central place to look for when projects
use hooks, it would allow them to fetch every hook at once and it would be a
good way to colectively create, extend and manage them.
However, the last issue, albeit an important and interesting one, is
probably too much out of the scope of this mailist, instead we(or here maybe
I) should talk more about actually creating the hooks first.
PS: Apologises for the mail formatting, the combination of Internet Explorer
and GMail ruined it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-devel-discuss