Re: orion5x housekeeping
On Sat, Jan 02, 2016 at 10:26:40AM +0000, Ian Campbell wrote:
> On Wed, 2015-12-30 at 18:51 -0800, Martin Michlmayr wrote:
> > I was looking at debian-installer and thought it would be good to see
> > if there are maintainers (and if not, at least users) for the orion5x
> > devices we supposedly support.
>
> I wonder if, for armel generally (or even arm* generally), we should
> take a leaf out of the u-boot package's book[0] and require a specific
> person from the community to agree to be listed as a tester for any
> platform we intend to Support, meaning that they would agree to
> occasionally try things on the named system or to do so when prodded
> regarding a specific change (e.g. big kernel transition).
While I certainly agree that it would be nice to have a tester for
each platform, I fear that making having a tester a prerequisite for
adding support for a platform would produce a kind of chicken-and-egg
problem. This depends of course a bit on what "support" means in
detail.
On armhf, we have a multiplatform kernel and there is a rather high
influx of newly supported platforms with every kernel release.
Adding basic support for a new armhf platform to d-i nowadays usually
involves making sure that all necessary modules are enabled in the
kernel and included in the corresponding module udebs, and that the
flash-kernel machine database is supplied with the necessary entries.
On armhf there is no danger in adding additional modules or enabling
additional kernel options as storage space for kernel and initrd as
well as RAM size is not a problem, so adding basic support for a new
platform causes no harm for existing platforms.
This is different on armel, where we have strict storage and RAM
restraints and e.g. using a newer kernel version or adding a module
to the initrd might make the installation fail on a number of
different platforms. Therefore breakage for existing platforms has
an a lot higher probability than on armhf.
Requiring a dedicated tester for a new platform before adding support
for it produces a chicken-and-egg problem. Normal users who would be
interested in trying Debian on their system won't do so if it isn't
supported firsthand, and the chance of some normal user contacting us
to be registered as a tester without any existing support is probably
rather slim.
For what I would call "extended" support in d-i, i.e. us providing
dedicated SD-card images including u-boot, we already have the
situation that a tester is required as Vagrant will only enable
a u-boot target if somebody has committed to testing it.
As a personal note: I am happy for everybody who uses d-i to install
a proper Debian instead of using a pre-made installation in the form
of an SD-card image that some unknown entitiy on the internet has
uploaded to some share-hoster, which is unfortunately rather common
in the armhf world and which is a security nightmare. Putting up
additional hurdles for adding platform support in d-i will probably
end up in more people going the dangerous but easy route of using
pre-made installation images from questionable sources, and I think
that we surely don't want that.
As discussed above, for armel requiring dedicated testers would make
more sense than for armhf, but on the other hand actually performing
the tests on armel is a lot more problematic than on armhf. While
one can usually just temporarily swap in another SD-card on armhf,
testing d-i on armel in most cases requires overwriting the internal
flash memory of the device, so this cannot be easily done with a
device in production use. I suppose most users only have one system
of a type, so once the system is up and running, doing regular d-i
testing poses a practical problem.
In summary, as much as I would like to have dedicated testers for
each platform, IMHO making that a requirement is not a route that we
should take.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: