[haiku-development] Re: [RFC / Important] Removing extra architectures

  • From: Jonathan Schleifer <js-haiku-development@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 19 Feb 2014 00:32:54 +0100

Am 18.02.2014 um 20:52 schrieb Alexander von Gluck IV:

Ok, how about Tiers?

Tier 1:  x86, x86_64, x86_gcc2   -- Can bootstrap, in Buildbot.
Tier 2:  ppc, arm  -- Not yet bootstraped, code in tree.
        Development should be somewhat active with potentially useful
        code someday.
Tier 3:  Everything else -- not in tree, not bootstrapped.
        (external forks welcome, we'll even link to them on the
         website ports page)

I think that categories are not really well. This does not consider how much a port is progressed at all. E.g. MIPS didn't even have a bootloader. But PPC really shouldn't be dropped, as it's one of the most progressed ports. Heck, I even have getting it to boot on my PowerBook on my TODO :). But I don't want to be under pressure that I *have* to do it in order to save the port and not losing the ability to someday run it on my PowerBook. Because let's face it: Once it's gone, it's gone *forever*. Nobody will revive it, as it will be a *huge* amount of work. If it's even much work without it being removed, then it's damn sure nobody will get it to work after it has been removed.

So while for MIPS I can't really disagree as it seems to have been an early port, I can't think of any good reason to ever drop an architecture that has progressed quite a lot and is very common. There's so much PPC hardware still out there, hardware more capable than ARM hardware.

And for m68k, I do think it's not that useful, but it is maintained by mmu_man. If it's maintained, why drop it? To increase the burden on the maintainer? Because that's all it will do. mmu_man then not only has to work on the m68k part, but also solve merge conflicts all the time, leaving no time to work on the actual port…

So, -1 on this from me. A strict set of rules for ports is stupid, it should be decided port-by-port.

Really, we're a small team and should not unnecessarily make it harder for others to work on the stuff that's fun for them. It's all about fun after all, right?

--
Jonathan

Other related posts: