On Tue, 2 Apr 2024 at 00:31, Chet Ramey wrote:
> On 3/31/24 8:34 PM, Martin D Kealey wrote:
> > That's a good start, but it seems incomplete, and there's little --
> perhaps
> > no -- overlap with bug reports in this list.
>
And this is still the most fundamental problem; the submission of bug
reports, the discussion around them, and the proposed fixes currently are
split between multiple platforms that don't talk to each other. So *very*
few people actually track everything.
> > Has bashbug always sent email to bug-bash@gnu.org, or was it previously
> fed into Savannah?
> bashbug long predates savannah.
>
We are instructed to submit bug reports via bash-bug, or by posting to this
mailing list, but none of those reports reach Savannah.
When Savannah became the primary repository, bash-bug should have been
updated to post to Savannah, and/or an email receiver should have been
created to inject into Savannah's "support" queue. Likewise, details
entered directly on Savannah should be sent to the mailing list. ("Overdue"
would be an understatement.)
First impressions when I sign into Savannah:
- There's no "dashboard" or "overview" of stuff that I personally am
likely to need. In particular, there's no mention of any projects I'm
trying to engage with. OK I'll try to add some:
- The sidebar has a (relatively) obvious link "My Groups", taking me to
"My Group Membership".
Nope, "You're not a member of any public group".
- The right panel has "Request for inclusion", which sounds about right.
OK, let's search for Bash. Yay, found ... oh wait, nope, "Bash Bear Trap"
is not "Bash".
- Let's back up, and use the site search in the side bar.
OK, *this* time I see "The GNU Bourne-Again SHell" (and the Bear Trap
again, and 13 other projects).
Let's follow that link and ... yay, found it.
At this point I save a bookmark, because that was the short-and-simple
version of what was actually a much longer and far more tedious process of
discovery.
The summary page says that this project has:
- 3 mailing lists
- an SVN repository (which turns out to be empty)
- a Git repository
- a "tech support manager" (which turns out to be a general inquiries
queue)
- a "patch manager" (which turns out to be a bug-reporting and
feature-request queue)
- 3 mailing lists
Initial impression good.
Well okay.
For all of 10 minutes, by which time I've discovered that these facilities
have no mutual integration.
It seems like the "support" queue is intended for interactions with users
and the "patches" queue is for interactions between designers, developers
and Q/A reviewers. That arrangement could have some benefits, but
unfortunately:
- The support and patch queues don't talk to each other. Once an actual
bug is identified from a support request, a separate "patch" issue has to
be opened, without any automatic cross referencing. And therefore when a
bug fix finally makes it into a release, there's no automated process to
close any original support requests.
- Neither the support queue nor the patches queue has any integration
with this email list (nor, I suspect, with any others).
- Any cross-referencing between them is up to project members to perform
manually.
- The git repo has a fixed set of branches created by the members; other
users cannot create their own branches.
- When it says "patch", it really still means an actual context diff
text file.
Anyone used to using a modern source management system (e.g. Piper,
Perforce, Bitbucket, Gitlab, or GitHub) would expect "patch" to mean a git
branch or equivalent, which can be amended (with additional commits),
merged, or rebased, all while being subject to regression testing, and then
merged into the "master" branch once it has QA approval. (A major effect of
this lack is that a textual patch can "go stale" while the master branch in
the git repo moves on, without any tracking of how far out of date it's
become.)
But there is no linkage between the patch queue and any git repo, nor is
there a branch per active patch issue.
- We cannot use ssh to connect to git.savannah.gnu.org, despite the
instructions for cloning the repo saying we should use
@git.savannah.gnu.org:/srv/git/bash.git rather than just
git.savannah.gnu.org:/srv/git/bash.git
.
This combination of missing features (and outright mis-features) amounts to
the antithesis of how one should design a modern collaborative development
process.
And that's a big part of why a one-man-band running the whole show is the
only feasible support model.
> Savannah seems too simplistic [...]
>
> If you have suggestions for the savannah maintainers, I'm sure they would
> be receptive.
>
Given that my first suggestion would amount to "dump the entire existing
codebase and adopt a fork of [insert name of existing project]", I rather
doubt that they'd be as receptive as you suggest.
It would tak
