help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cleaning up bash releases at first directory level


From: Koichi Murase
Subject: Re: Cleaning up bash releases at first directory level
Date: Tue, 21 Mar 2023 12:18:30 +0900

2023年3月21日(火) 8:31 Lawrence Velázquez <vq@larryv.me>:
> On Mon, Mar 20, 2023, at 6:40 PM, uzibalqa wrote:
> > I noticed, but with all those source files it is quite a mess not to
> > put them in an src directory.
>
> I don't really understand how pushing them all one level down would
> be a meaningful improvement.
>
> > I favour a cleaner organisation.
>
> Your personal preferences are not a good reason to churn a huge
> chunk of someone else's repository.
>
> > Would be an improvement to everybody.
>
> Speculative assertion.
>
> > And newcomers could delve around the package better.
>
> Speculative assertion.

Though Chet will finally decide, I totally agree with Lawrence. Even
if we are not the maintainers, it is important to express our opinion
to help the decision of the maintainers. Otherwise, impractical and
problematic changes only requested by a single insistent person, like
`localvar_unset', would easily enter the codebase.

How much the logical structure should be reflected in the source tree
is a matter of degree, and the optimal level of the organization
depends on the toolset used for the development, the skills and
personal preferences of the developer, etc. I guess one of the factors
that determine "the optimal level of the organization" is the size of
the search scope with the currently available toolset and the skill.
In my experience, beginners tend to request too much organization.

For an extreme example, sometimes they suggest putting every function
in a separate file, but that will soon end up with thousands of files
and become unmanageable in the realistic size of the codebase. They
probably ``search'' files and functions with their eyes and memories
(e.g. by clicking the items in a GUI tree view of the filesystem with
a mouse), so they need some assistance from the filesystem structures
with a small number of files at once, but this soon becomes
unmanageable when the codebase becomes large. We usually search files
and functions with a search command, where too much organization would
make it troublesome to quickly specify the scope of the search. Also,
not all programmers are GUI programmers. I personally never use GUI
editors because I wouldn't like to take my hands off my keyboard to
switch to the mouse, which is just slow.

Putting every source file in the src subdirectory is not that extreme,
but it's still a matter of degree. I guess putting them inside src
might help people who read the entire file list of the directory from
top to bottom one by one, but I'm not sure if we should care about
that level of users. The repository is primarily for the developers
and secondarily for the users who want to compile Bash from the source
and who are familiar with the files README, INSTALL, ./configure, etc
For those people, whether to put the source in a subdirectory or not
does not make any difference. Rather, switching the entire source
location would make the tracking of history changes discontinue (or
requires special options, etc.), invalidate existing patches, etc.
They might not be serious problems but would increase the maintenance
cost. I don't think the original poster has shown any sufficient
reason to make changes compromising that point.

--
Koichi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]