On Tue, 2 Apr 2024 at 00:31, Chet Ramey <chet.ra...@case.edu> 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
<username>@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 take a gargantuan effort to bring Savanna up to reasonable feature
parity with Gitlab, much less Github.
And any lesser effort would be wasted on what amounts to an in-house system
with a tiny number of installations.
Given that Gitlab is already "good enough" as a workable platform, *I* am
certainly not prepared to waste my time bringing Savannah up to scratch.
But I might be convinced to write a migration tool; I might even be
convinced to write a "Savane Skin" for Gitlab.
> > perhaps Bugtraq or Gitlab would be acceptable, or maybe some other
> project management tool?
> That's a GNU community decision. GNU projects use GNU tools.
>
> Are we building a cathedral with gatekeepers, or a bazaar where the
> masses can contribute?
>
Just so we're clear on this juxtaposition...
The requirement for contributor licensing agreements and/or copyright
assignment might well make sense in terms of defending copyleft, but it's
acting like a wall around the bazaar and slowly turning it into a cathedral.
Once upon a time Bash was one of the FSF's flagship projects, being the
only free alternative to the proprietary Ksh and Bourne shells. Now it's
just one among several free POSIX-compatible shells. Which leads me to
wonder, is it time to start planning for its eventual retirement, allowing
other shells to focus on adding new features?
What about savannah is keeping the masses from contributing? If you want to
> work on a bug, work on it.
>
Firstly, "working on a bug" is not just about writing a patch.
Secondly, there's a single human as a gatekeeper. Having to deal with a
human - any human - can be off-putting.
Thirdly, where does one look to *find* a bug that's worth working on? If
the answer is "look in both Savannah and the mailing list archives", well
that just proves my point.
-Martin
PS: the excessive use of "save" buttons makes the entire site *feel* at
least ten years out of date.
