Re: Next GNUstep release

[Riccardo Mottola]

Hi,

Ivan Vučica wrote:
> Please also see the other thread for my thoughts so I don't repeat
> them in detail, but just this:
>
> On Mon, Apr 6, 2020 at 2:46 PM David Chisnall <address@hidden> wrote:
>>  Compare these two pages:
>>
>> The ChangeLog file:
>> https://github.com/gnustep/libs-base/blob/master/ChangeLog
>>
>> The Git history:
>> https://github.com/gnustep/libs-base/commits/master
>>
>> The second is easier to skim, easier to jump to exact changes, and
>> easier to use to isolate change in a particular area (only care about
>> changes in the tools?  Look here:
>> https://github.com/gnustep/libs-base/commits/master/Tools instead of the
>> main history page).

I completely agree that the ChangeLog is much easier to skim than the
git history! Even if the one of github is nicely formatted.
I wrote separately about the usefullness of grouping files, comments and
possibly methods together.

> Should we enforce each commit to be larger before publishing? Should
> we enforce commit chains to end up in a merge commit which is
> detailed? Should we enforce updating changelog-equivalent only when a
> particular feature is finished and ready to be added -- but *enforce
> it consistently*?

No please not minimum length...

> Again, I don't want to have to have to distinguish between "this is
> adding a new class", "this is fixing a security bug", "this is
> *partially* addressing a security bug", "this is a quick compile fix",
> "this is a large overhaul of the build system" by having to inspect
> each commit in a really long chain of commits. Not necessarily a tree,
> even.
>
> FWIW ChangeLog entries *when written* were more useful for this
> purpose. The problem was *when they weren't written*.

Mostly because they were a little more thought off.

Of course if you just write "fix implementation" and skim a log, you
don't know what.

Suppose the scenario where you implement feature X and by this solve a
bug B1.

1. clean-up some code
2. implement a new method
3. use the new method
4. clean up some other methods and fix bug.
5. add some boilerplate, comments
6. add a test case

I would have made 6 different commits, with 6 messages. But for a
ChangeLog perhaps just 2 commits are useful. One for the new
implementation, citing the file, the method and reference to feature X.
Then a commit with the usage and bug fix for reference fo B1.
Adding a test case, a fix is "not that useful" in the ChangeLog.


This is, of course, theoretical world.

> Git commits as written today are unsustainable.

And about in most projects (FOSS or not) I see.
Perhaps a good average is in mozilla, with longer messages, bug
reference, etc. However, there, the commits are essentially just
merge-in of patches.
So there is a very strict reference bug-bug-number-commit and the commit
are comprehensive, if done in steps numbered (like my case above would
have bug B1 and then commit 1/6, 2/6 etc etc)
We are not so disciplined and it is a bit the opposite of how he always
worked.


> But maintainers, please just decide something and proclaim that this
> is what will be done. It doesn't have to be consistent among packages,
> but *within* a particular release of an individual package, I'd like
> to see consistency. We can't have some people "opt-out" of the chosen
> process. Maintainers need to be the ones to enforce this, including
> possibly writing the log entries ('blogposts'?) themselves.
>

we need to agree on some sort of common line.
Of course, everybody wants to type and update the least possible during
hacking, but then different developers have different tastes and needs
when looking up the changes during bug hunting or releaseing.

Riccardo