On Thu, Jan 3, 2013 at 9:03 AM, Adam Williamson <awilliam@xxxxxxxxxx> wrote:
> 3. In the longer term, how can we get anaconda, i18n, systemd, GNOME etc
> folks all pointed in the same direction and working so that there's far
> less suckage and far more smooth interaction going on here? Should we
> try and run some sort of session at FUDCon?
It seems to me similar problems occur increasingly frequently; and
it's often not "pointing projects into the same direction" (AFAICS
even here it's not the case that we have various projects that want
conflicting things), but "not losing the features and ideas from the
past".
In many aspects of Linux, there is no available record of the design
decisions - no documentation of what problems need solving, how they
were solved, what is the purpose of each individual thing. The
original authors probably know all of these things, or at least know
where to find them in some project-specific documentation, but they
may not be around to help, and even if they are around, it's not
obvious who to ask.
So, with an increasing frequency, somebody new encounters the problem
space, has no idea why the things look like it does (or even does not
know about some of the components), and we end up with regressions and
rediscovering things.
(This is not an anaconda/i18n/systemd/GNOME thing, this happens even
in the "core UNIX": about a month ago it turned out that we don't know
what the precise intended semantics of the "tty" group are; it seems
not to be documented anywhere directly, and the indirect documentation
in the man-pages package is contradictory.)
I'm not sure how to solve this well... Fedora isn't a great place to
document such things (although better than no place, certainly), and
finding informed volunteers to create such documentation won't be
easy.
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
