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

  • From: Alexander von Gluck IV <kallisti5@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 19 Feb 2014 11:45:41 -0600

On 2014-02-19 at 00:32:54 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
wrote:
>On 2014-02-19 at 00:32:54 [+0100], Jonathan Schleifer 
><js-haiku-development@xxxxxxxxxxx> wrote:
>> 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.
>
> No matter just how much boldness you insert into the argument, I fail
> to see what damage it does to a port to move it to a github fork.
> Someone has to do merge in the upstream changes, but that is work that
> has to be done in any case. 

Did you see how far we got set back when WebKit dropped all of the Haiku
code?

>> 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…

> Huh? Ingo and me had to maintain the package management branch
> externally for a long time and we did manage to get some actual work
> done, didn't we? 

I think several developers (including me) were tiptoeing around anything
that could be modified by PM (I distinctly remember saying that in IRC
as well along with others... so I'm not 100% sure this argument stands
when compared to architecture ports.)

> I believe that the burden of keeping a non-complete port up to date
> should indeed be on the maintainer of that port, not everyone else.
> It's not as if there's a huge amount of upstream changes that cause
> masses of merge conflicts.

You make it sound like any change to any source file in the entire tree
will result in an architecture breakage. The only real issue is when we
go and structurally revamp entire core parts of the kernel. (aka
scheduler)

> My view is this: only complete and actively maintained ports should be
> part of the main tree (at the time of writing, this is x86_gcc2, x86
> and x86_64). With "actively maintained" in this context I mean that if
> there's  a change in the tree that require adjustments to the
> arch-specific code which the committer of the change doesn't know how
> to do, the maintainer is expected to have the knowledge and motivation
> to apply the required adjustments within a short timeframe, such that
> the port doesn't rot in-tree.

>> 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?

> That argument applies to both maintainers of the kernel and
> arch-specific code, so in order to not spoil the fun for either of
> these groups, please let's try to come up with a decent compromise.

> I'm not saying the following is a good compromise, but it is my POV:
> With Ithamar, the person who has put most effort into the ARM port
> has already stated that he's just fine with doing his work externally,
> and the PPC port doesn't actually have a maintainer. As a result, I'm
> all for  moving everything but x86-based ports to github or any other
> external playground.

Ithamar isn't the only one working on ARM.  So this really isn't a valid
argument either:

http://cgit.haiku-os.org/haiku/log/src/system/kernel/arch/arm

There are 6 people there making commits to the arm arch directory in the
kernel alone.

I still stand by wanting to see ARM and x86 remain in tree.  I'd hate to
see PowerPC go as it was so close pre-scheduler / pre-PM. (booting into
the kernel / Haiku spash)

 -- Alex


Other related posts: