On Tue, 7 May 2024, at 5:24 AM, Phi Debian wrote:
> On Mon, May 6, 2024 at 7:51 PM Kerin Millar <k...@plushkava.net> wrote:
>>
>>
>> I'll put it in a little more detail, though no less plainly. I find the
>> terminology of "libraries" and "modules" to be specious in the context of a
>> language that has no support for namespaces, awkward scoping rules, a
>> problematic implementation of name references, and so on. These foundational
>> defects are hardly going to be addressed by a marginally more flexible
>> source builtin. Indeed, it is unclear that they can be - or ever will be -
>> addressed. Presently, bash is what it is: a messy, slow, useful
>> implementation of the Shell Command Language with an increasing number of
>> accoutrements, some of which are fine and others of which are less so (and
>> virtually impossible to get rid of). As curmudgeonly as it may be to gripe
>> over variable and option names, this is why the import of library, as a
>> word, does not rest at all well in these quarters. That aside, I do not find
>> the premise of the patch series to be a convincing one but would have little
>> else to say about its prospective inclusion, provided that the behaviour of
>> the posix mode were to be left unchanged in all respects.
>>
>> --
>> Kerin Millar
>>
>
> Thanx @Kerin, I got an intuitive reluctance with the patch series, but
> could not formalize it that way, that is exactly it (specially the
> nameref to me :-))
>
> That brings up some questioning about the bash dev workflow. I
> personally only monitor bash-bug (not the others bash-*), specially to
> be aware of new incoming patches.
>
> Generally, the few patch that shows up here are patches that fix a
> specific standing bug, or on some occasion, the declaration of a bug
> along with a patch to fix it, they are generally reply with 'thanx for
> the report and patch!'
>
> I rarely see patches about "Hey guys I got this great idea what do you
> think", so I wonder for this kind of request does git{lab,hub,whatever}
> be more appropriate? or may be I should say convenient, a public git
> project (clone) generally have all the infrastructure for discussions,
> enhancement and fix.
I don't think that there is anything wrong with the workflow that has recently
been in evidence. In case you're not fully aware, it goes something like this:
1) git clone https://git.savannah.gnu.org/git/bash.git
2) enter the local working copy and checkout the "devel" branch
3) optionally create a new branch to contain the intended changes
4) hack on the code and apply some commits
5) use git-format-patch(1) to generate a series of patches based on those
commits
6) post the patches to the list, either manually or by using git-send-email(1)
7) allow the patches to undergo discussion and review
8) return to step 4 if necessary
Let's say that Chet is prepared to accept the most recently posted patch
series. In that case, all he need do is use git-am(1) to apply the commits from
the posted messages directly to his own working copy of the devel branch.
Similarly, anyone that would like to try out the patches themselves can do the
very same thing and (re)compile bash. Perhaps even iterate on them.
There are a few characteristics of this workflow that are worth noting. There
is no requirement for a specialised platform or service to be involved. Only
the git software is required, along with some medium by which to convey the
am-formatted patches to whomsoever is to review them. Of course, it is sensible
to gauge whether there is any potential interest in a proposed feature prior to
submitting patches. Matheus tried to do exactly that on the 21st April. I may
think that the resulting patches have been oversold but I would not fault his
process.
I don't wish to take this thread out into the weeds but would add one more
thing. Not everyone is content with the encroachment of proprietary services
such as GitHub. Increasingly, it is becoming the bar that must be cleared for
open-source participation of any kind. Do we really want for a future in which
one cannot even send a simple patch without agreeing to GitHub's terms and
conditions, signing up, forking a project then opening a pull request? Or where
maintainers won't even stoop to communicate with would-be contributors unless
opening an issue on such a platform?
>
> The bash code owner can then pull the great idea when the demand for it
> start roaring?
For more ambitious feature branches, it might be more convenient. Ultimately,
if Chet is content to review patches in the present fashion then that's all
that really matters.
>
> Just questioning, I really have no idea what is the bash dev team way
> of receiving enhancement request.
The description of this list is as follows.
"This list distributes, to the active maintainers of BASH (the Bourne Again
SHell), bug reports and fixes for, and suggestions for improvements in BASH."
As such, proposing enhancements here shouldn't be a problem. Whether they end
up being implemented is another matter, of course.
--
Kerin Millar
