[haiku-development] Re: [RFC / Important] Removing extra architectures
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 19 Feb 2014 10:31:35 +0100
Hi,
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.
> 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 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.
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.
cheers,
Oliver
Other related posts:
