Re: Extremely large change wave?

[Ineiev]

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