modular -> monolithic

[JoJo jojo]

Read a lot of interesting points in this thread,
here are my thoughts :-

Problem statement: Maintaining Huge Legacy codebase,
(bonus problem - how to attract & develop new x.org developers)

Constraints: Few Developers (whose minds really warps around issues
like portability too),
Lack of top notch upto date documentation(besides code i.e ),
X.org foundation bureaucracy Vs. Linux/OpenBSD Dictatorships,
QA Automation & maintenance

Solution: This is where we picture S. Ballmer goin'
"Developer..Developers......"
Collaboration issues with x.org wiki,
Revisiting documentation by seasoned x.org developers
Setting small but clear milestones for the whole X.org project.

....and achieving them.

-JoJo


On Jan 21, 2008 12:50 AM, Bernardo Innocenti <bernie at codewiz.org> wrote:
> To summarize, it seems there's interest in merging the
> drivers back into the server tree.
>
> However, I see a few downsides that need solving before
> we can say it can be done:
>
> 1) build time and build complexity
>
>    The Linux kernel can afford to ship thousands of drivers
>    thanks to the very fine-grained Kconfig infrastructure,
>    so that developers don't necessarily need to pay the full
>    price of a big rebuild every so often.
>
>    Autoconf is clearly not up to solve this issue.
>    My configure command line for the xserver already spans
>    5 lines and one can't paste it on IRC without being kicked
>    from the channel.
>
>    Switching to Kbuild also doesn't seem like a bright idea,
>    because unlike the kernel we *need* to run autoconf tests
>    for portability.
>
>    I don't know enough about cmake to comment on it, but
>    switching to a totally different build system would be a
>    huge amount of work that I guess nobody would be willing
>    to do.
>
> 2) packaging
>
>    Distributions are very likely to prefer packaging drivers
>    separately from the server.  Especially on embedded
>    platforms, this can be very important.
>
>    Not a big issue, but we'll receive some interesting hate
>    mail from downstream packagers for moving things around
>    once again when some distributions are still migrating to
>    the modular layout :-)
>
>
> 3) spreading the development burden
>
>    Some refactorings are deemed to break the driver API.
>    We've seen it with the pci-rework and the input changes.
>
>    While it seems logical that whoever broke things ought to work
>    on fixing them, I see it as a *huge* drag on development if
>    we impose a perfectionist policy that discourages any big
>    change.
>
>    Remember the story of the broken Iomega Zip driver in
>    Linux 2.6.0?  Some people wanted called for delaying the
>    release indefinitely to fix this "regression".  Others
>    wanted to revert the patches that broke it.  Linus had
>    this interesting position that if nobody cared to send
>    a patch in months, he could not care less about the
>    Iomega Zip because he did not even have one!
>    {{citation needed}}
>
>    Xorg has an impressive heritage of severely bitrotting
>    hardware drivers.  And the reason few people care to fix
>    them simply reflects the fact that few people actually
>    *use* that hardware!  Letting the old cruft slowly bitrot
>    and die based on how much love they spontaneously attract
>    is a nice and natural way of evolving any large codebase.
>
>    So what I'm suggesting here is that whoever is willing to
>    rework the core server takes *reasonable* steps to fix the
>    major driver regressions, possibly in collaboration with
>    the driver maintainers.
>
> Unless we settle (1), (2) and (3) in a satisfactory way,
> my $0.02 opinion is that merging the drivers back would
> cause more struggle than the advantages we all see.
>
> --
>  \___/
>  |___|   Bernardo Innocenti - http://www.codewiz.org/
>   \___\  One Laptop Per Child - http://www.laptop.org/
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>