Re: Cleaning up bash releases at first directory level

[uzibalqa]

------- Original Message -------
On Tuesday, March 21st, 2023 at 3:18 PM, Koichi Murase <myoga.murase@gmail.com> 
wrote:


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

We are not talking about extreme examples, but only the discussion originally 
brought up.  

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.

I do not see it as serious problem as you suggest.
 
> --
> Koichi