[Bug 1925759] Review Request: disorderfs - FUSE filesystem that introduces non-determinism

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1925759

Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |POST



--- Comment #3 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> ---
> Yes they are, notably I've reviewed it with upstream and also ask them to publish the keyring. I've updated the code accordingly the guidelines.
> I've added the keyring hash into "sources" file too. Should I add it into the git repo too?
The docs say:
- Any detached signature file (e.g. foo.tar.gz.asc or foo.tar.gz.sig) must be
uploaded to the package lookaside cache alongside the source code, while the
keyring must be committed directly to the package SCM.

So the keyring should *not* be in 'sources' file.

> NEWS is older and looks like some kind of changelog.
Ack.

> I propose you to help upstream in updating the current README
Well, the debian upstream does have a problem with good NEWS files. I'm annoyed
by the
changelog in diffoscope: it's better than nothing, but it's full of debian-only
bits,
information about individual commits and their reverts, etc. The only thing
that is
useful for the user (or a non-developer packager) is a file that list big
high-level
user-visible changes. So even stuff like a major refactoring or new tests that
have
no user-visible impact should not be mentioned, except maybe if it results in a
massive
efficiency change. But to create this kind of file, a really good understanding
of what
was happening in the repo is needed. I.e. I think it only makes sense to let
the main
developers do this. In my experience, even a semi-frequent contributor, who
didn't look
at every patch as it came in, would have a hard trouble putting this file
together
correctly.

Continuing from https://bugzilla.redhat.com/show_bug.cgi?id=1925759#c1:
+ package name is OK
+ latest version
+ license is acceptable for Fedora (GPLv3+)
+ license is specified correctly
+ builds fine in mock
+ B/R/PR seem to be specified correctly
+ fedora-review and rpmlint find no issues

Package is APPROVED.

--

I'll add you to the packagers group.
Please consider changing your settings in fas to non-private, so that other
people can see 
your real name. (It can be guessed from the email anyway…)

You will need to use 'fedpkg request-repo' and then 'fedpkg import', etc. See
https://fedoraproject.org/wiki/New_package_process_for_existing_contributors if
you
haven't already.

Please close the two review bugs after the packages have been built in rawhide.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux