On Tue, Feb 27, 2024 at 05:48:47PM -0700, Bob Proulx wrote: > > I believe the most important change from Savannah admins' viewpoint > > wasn't in fact in the code. ... > That's a good example of a fundamental change which had no > communication nor coordination. Though it is a change that I would > generally support. But the result is that it leaves everyone else > lost at sea without any footing. > > > I did it on Jan, 31, when migrating to frontend2, and I mentioned > > I was going to do that even earlier, when the fundraiser was > > running. > > This detail must have been missed in the communications.
That's true, I'm a lousy communicator. I beg for indulgence. > > > Just on the surface I see the following confusing things. > > > > > > * All of the .gitignore files have been deleted. This causes a large > > > amount of noise files to appear in the git status. What's the plan > > > for this? > > > > When I use a separate build tree, git status only shows these files > > [reordered]: > > > > configure Makefile.in frontend/Makefile.in lib/Makefile.in > > po/Makefile.in autotools/m4/Makefile.in > > aclocal.m4 autom4te.cache/ autotools/install-sh autotools/missing > > po/stamp-po po/savane.pot > > po/ca.po~ po/de.po~ po/es.po~ po/fr.po~ po/he.po~ po/it.po~ > > po/ja.po~ po/pt_BR.po~ po/ru.po~ po/sv.po~ > > > > I don't think the amount is really large and noisy. > > Really? Yes, those are all the items git status shows, and no, I don't think it's too many. > I was seeing at least three pages of differences! 22 lines fit in one standard page; ten of them are backup PO files, perhaps it wouldn't be hard to avoid generating them. > Requiring > the use of a pager to skip over files that should not be committed is > not a good thing. What about recommending VPATH builds? https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html Missing files that should be committed is a bad thing, too. > And now documentation can be > updated to make it possible for other people who are not you to clone > the repository and do work with it. PHP built-in web server isn't intended to be a full-featured server; instead, INSTALL refers to a script that runs Apache from a non-root account. > > The files in /opt/savannah/savane are leftover from the times when > > frontend2 served as frontend. > > That's quite the pitfall to leave behind. It may be, but it isn't extremely unusual for Savannah. > > mgt1:ChangeLog does include some records; general setup is now > > outlined in <https://savannah.gnu.org/maintenance/SavaneSetup/>. > > I see that is a new file created on Feb 24. I wrote my message on the > 25th so of course being new I would not have known abou it. It's only > the 27th today. That's really a very new file! mgt1:ChangeLog is no way new, and it contains sufficient info; its daily diffs are forwarded to a mailing list. SavaneSetup.mdwn is new, but it only finalizes the unification that started in 2023-05, according to mgt1:ChangeLog records. then, the wiki repository has a log feature, and a mailing list for the commits is functioning. worst comes to worst, your humble servant is responsive as a rule of thumb. > Writing that as if it > has been there for a long time is again disingenuous at best. I'm sorry, I wasn't clear. I wrote 'now', and I implied that it was a recent development. ... > The files you work with in your local sandbox may have > been there for years and no one else will have been able to see them, > to view them, to comment upon them, or even to know if they are > happening at all. Those private dates do not matter. The only dates > that matter are the dates when they become visible to us. ... I'm glad you recognize that. I have no habit of working on Savane privately, I rarely push later than the same day I write the commit. and in particular, preliminary but functional versions of the commit I mentioned, 9fd58ef254ab, and the subsequent 91cf0c8012, were in the official Savane repository on 2023-09-19 or earlier (I've just checked the oldest occasional backup I have). IIRC Jing Luo commented upon them in December, and I don't recall reports for any issues with finding the development sources. And I hope your note applies to other people to a degree.
signature.asc
Description: PGP signature
