sparc/debian/linux procedures

sparc/debian/linux procedures

[Brian Thompson]

All,

First I have to say this email isn't targeted at any specific people by
name but rather to all of those who are interested in seeing further
linux sparc development (and especially Debian sparc development).

I've been trying to follow the current debate regarding niagara testing/
bug fixes and I have to admit that the bureaucracy is a bit intimidating
at best.

I've recently (over the past year or so) started focusing on Debian now
that Canonical no longer officially supports sparc on Ubuntu, figuring that
although most of our hardware here is older hardware, moving towards
Debian directly will at least give the OS a chance at remaining up to
date.

It's my understanding that there are a team of people who are focused
on the sparc kernel itself (which is used by Debian as well as some of
the other distributions - Aurora, etc).

It's also my understanding that there are a team of people who are
focused on making sure that the sparc port of Debian works properly
as a complete Debian OS distribution for sparc.

In addition, I understand that there's also a team of people who are
focused on making sure that the Debian distribution as whole
(non-arch specific) functions properly and that changes on one port
don't end up inadvertently causing problems for other Debian ports.

Likewise I understand that there's a team of people who are focused
on making sure that the linux kernel as a whole functions properly and
that changes specific to one arch don't end up inadvertently causing
problems for other linux kernel archs.

My question is - when I find things that worked in Ubuntu sparc
but not on Debian, what is the proper procedure for resolving the
issue? Is there a checklist or flowchart anywhere public that should
be followed when issues are found?

I'm guessing the first step is probably to determine whether it's a
kernel issue or an issue external to the kernel so that a bug report can
be filed with the correct team (while also checking to see if the issue
has already been reported), but again that's just a guess.

And, I'm by no means asking for professional assistance or intending to
criticize anyone's prior efforts. I really would like to understand the big
picture though so that I know all of the steps starting with discovering a
new issue to the issue being resolved in the next Debian release. That
way I can follow through and assist where I can while at the same time
not stepping on anyones toes.

Any guidance would be greatly appreciated.

Thanks,
Brian

Re: sparc/debian/linux procedures

[Martin]

[ Apologies for the cross post ]
On Mon, 2009-05-04 at 15:26 -0400, Brian Thompson wrote:
> All,
<snip>
> It's my understanding that there are a team of people who are focused
> on the sparc kernel itself (which is used by Debian as well as some of
> the other distributions - Aurora, etc).
This is a subset of the kernel developers.  David Miller is (I believe)
the key man.

> It's also my understanding that there are a team of people who are
> focused on making sure that the sparc port of Debian works properly
> as a complete Debian OS distribution for sparc.
It's more of a loose affiliation, but yes, these are some of the Debian developers on the debian-sparc list.

> In addition, I understand that there's also a team of people who are
> focused on making sure that the Debian distribution as whole
> (non-arch specific) functions properly and that changes on one port
> don't end up inadvertently causing problems for other Debian ports.
Again, more a loose affiliation - this is essentially the work of the
Debian developers.  A small number of developers have responsibility for
over all integration (i.e. the release team, buildd maintainers, etc.)
but most work is done on a package by package basis with a small number
of folks working on each (often one or two).

> Likewise I understand that there's a team of people who are focused
> on making sure that the linux kernel as a whole functions properly and
> that changes specific to one arch don't end up inadvertently causing
> problems for other linux kernel archs.
This is, in general the Linux kernel developers; although, again, their responsibilities and organisational structure vary.

> My question is - when I find things that worked in Ubuntu sparc
> but not on Debian, what is the proper procedure for resolving the
> issue? Is there a checklist or flowchart anywhere public that should
> be followed when issues are found?
> 
> I'm guessing the first step is probably to determine whether it's a
> kernel issue or an issue external to the kernel so that a bug report can
> be filed with the correct team (while also checking to see if the issue
> has already been reported), but again that's just a guess.
A general procedure might be:

1. Identify which package(s) are causing the problem.
2. Attempt to identify what conditions / factors / circumstances trigger
the issue.  All the normal rules about writing bug reports apply.
3. File a bug report against the relevant Debian package.
4. Assist the package maintainer with any follow up queries.

If you have time and access to a version of the package that does work,
it might be helpful to track down which differences are causing the
problem, and if possible, submit a patch.  Certainly, including a
reference / pointer to the nearest version of Ubuntu package that works
would be helpful.

If the bug turns out to be something that is not specific to Debian and
is a more general problem then the packages maintainer may forward it
("upstream") to the main developers for that package.

> Any guidance would be greatly appreciated.
Does the above help?  I'm far from an expert on this; I'm just an
end-user, but the above procedure has worked for me.

HTH

Cheers,
 - Martin