> "Martin J. Bligh" wrote:
> >
> > > While I have this on my mind I want to express this now since the
> > > very first bug that hit my mailbox had this issue.
> > >
> > > I want to suggest that all reported bug in the database must be
> > > reporducable with some release done by Linus or his BK sources.
> > > And also that we can automatically close any BUG submissions that
> > > have other patches applied.
> >
> > Hmmm ... I'm not sure that being that restrictive is going to help.
> > Whilst bugs against any randomly patched version of the kernel
> > probably aren't that interesting, things in major trees like -mm,
> > -ac, -dj etc are likely going to end up in mainline sooner or later
> > anyway ... wouldn't you rather know of the breakage sooner rather
> > than later?
>
> So people will need to use their judgement as to whether the
> problem is in 2.5.47, or in the -bk snapshot which was taken from
> Linus, or in the -mm addons.
>
> If in doubt, people should go for the mailing list first. Because
>
> a) the response time will be better
> b) more people will see it
> c) the owners of the add-on patches can screen it quickly.
Has my 2.5 Problem Report Status postings been useful? If so, when I
discussed this with Martin one of the roles we agreed I would play was
taking bug reports from the list and adding them to bugzilla. I'll also
be a "filter" for some of the issues discussed in this thread, sort of a
janitor if you will.
My question is how should compile failures figure into the bug database?
Most of the compile failures are typos or thinkos that get quickly fixed.
Should they get tracked, or dismissed quickly unless they linger on. I
didn't track simple compile failures in my list.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/