[Development] Qt 6.1.0 release note

[Alex Blasche]

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Giuseppe D'Angelo via Development
> I must say, I don't quite like the format used here.

I totally agree and in fact I still believe moving to this one-file system in some unrelated repo is a disservice for Qt. It is an optimization for release purpose with detriment to Qt developers and users.

It doesn't make it easier to get a complete review by developers because it increases the ownership for one file too many many developers. 
Everybody is responsible is the same as nobody is responsible to final cleanups.
This was the problem for qtbase in the first place and this makes it even worse.
 Smaller modules didn't have the problem but they do now.
 
> While having the commit SHA might be useful if someone wants to look up the
> commit corresponding to each changelog entry, there's a few things that don't
> quite sound OK to me.
> 
> 0) No 72 columns wrapping. There, I said it.
> 
> 1) Quoting the commit message of a given change is hardly useful. That's why
> we mandate a [ChangeLog] entry, after all; commit messages must fit in 72
> columns, so they'll use a bunch of shortcuts that shouldn't be read as-is by end
> users:

+1 

Normally I am not a stickler for 72 or 80 columns but here it is needed. I don't want to scroll left 
and right every 5 lines just to read everything. After git commit is already wrapped like this. 

If there is a changelog the first line of the commit log should be discarded

> 3) The messages are grouped by submodule. But submodules are not relevant
> for end-users, end of story. Why there isn't a grouping per Qt module instead?
> We force people to add that to ChangeLogs, only to throw away that
> information?

A very strong +1 from me too. I could understand that 6.0.1 release notes didn't have this because
we changed system but the data is there, we could process it in 5.x we should use it here too.

If the qt module is really missing or wrong then add a catch all section at the end of a submodule's list.
 
> 3a) What about "meta" changes, like the ones we list under [Important Behavior
> Changes], or [Third-Party code] or whatever? Now they're thrown into the mix,
> so they don't stand out as things to watch for. I can hardly imagine that I need
> to dig into the middle of [qtdeclarative] only to find a behavioral change in the
> QML language.

Same here +1

 
> 4) Also why not grouping by class? If now I want to find all the changes to
> QString, I have to read the entire [qtbase] thing. Again this is information
> present in the [ChangeLog]s that is getting binned.

+1

> 
> The listing of the Fixes is also questionable as well. Why not using JIRA's bug
> description, rather than the commit description? At least
> *that* could give better information. Is it really necessary repeating "fixes" a
> thousand times?

Aspirational target. We have not done that so far and it needs new scripting.

 
> I don't see the changes to QList/QVector/QString/QByteArray behavior that
> have just landed, for one.

Please be fair. This landed just about the same time the logs were generated. We should update of course.

--
Alex