+1

I feel I ought to put a -1 here, lest it was thought I wasn't paying attention. But it feels rather improper to do so.

+1

Philip, this ticket is for FESCo members to vote on the proposal.

+1

Philip, this ticket is for FESCo members to vote on the proposal.

From that I should understand ngompa is a FESCo member? So he wasn't simply voting on his own proposal, which is generally considered not a done thing in England.

FESCo policies do not stipulate that members who are associated with a Change Proposal cannot vote on it. This ticket is for FESCo members to vote, please refrain from adding further comments. If you want to discuss changing our voting policy, please start a discussion on the mailing list instead.

+1

Philip, this ticket is for FESCo members to vote on the proposal.

From that I should understand ngompa is a FESCo member? So he wasn't simply voting on his own proposal, which is generally considered not a done thing in England.

That's a correct understanding. The current members are listed here

@phillip-lougher The question of voting on one's own Change proposals was covered by a formal resolution a few years ago. (I can dig up the reference if you wish.) The conclusion was that FESCo members are generally knowledgeable on the topic, also because they proposed a change related to the topic, and that abstention is not expected. Since then, we vote on our own Changes, and usually put "(as owner)" or something like that for clarity.

Hmm, so I'm a bit surprised here. I didn't stay on top of all of discussions, so I'm reading them right now.

Squashfs may not be particularly actively developed, but it's a special-purpose filesystem… so not having any development for years and years would be completely fine.

In the "Benefit to Fedora" there is only a vague statement about some possible enhancements in the future. This is very weak. In fact, I'd say that the expected cost of a switch of one of the underlying components in the stack is non-zero… Problems crop up if we switch the spelling of a component name or the kerning of a font, and this is a much bigger change. So we need some real justification and benefit to outweigh the costs of a switch.

And finally, problems with compression and decompression time and ratios were reported. Some measurements and an evaluation of this needs to be present in the Change page.

-1 right now. Sorry, doesn't seem to make much sense at this point.

Marking to be discussed at meeting tomorrow due to -1 vote.

17UTC in #meeting:fedoraproject.org matrix room.

will defer to next meeting.

I won't be around tomorrow unfortunately, so can we defer this to the meeting next week?

If it is discussed in tomorrow's meeting, I'd like to note that @dustymabe and I have added some data about this to the Change document itself.

will defer to next meeting.

The missing data was provided in the change page (tl;dr: live media compression on-par with SquashFS; slightly better compression and build times, other media slightly better compression; but compression times worse up to ×2). So this is good enough.

+1 now.

Dropping meeting tag since there are no -1 votes.

+1

Has this change reached a decision yet?

This is effectively APPROVED now. (+4, 0, -0)