On Thu, Aug 16, 2018 at 5:04 PM Stephen Gallagher
<sgallagh(a)redhat.com>
wrote:
>
>
>
> On Thu, Aug 16, 2018 at 8:30 AM Michal Novotny <clime(a)redhat.com> wrote:
>>
>> On Thu, Aug 16, 2018 at 10:49 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl> wrote:
>>>
>>> f-r currently fails to build (#1603956), it has a bunch of bugs open
[1]
>>> and many issues and unhandled pull requests in the upstream repo [2,
3].
>>> The last upstream commit was 2 years ago.
>>>
>>> f-r has is annoyingly outdated and gives often outright bad advice
>>> (for example about BR:gcc or BR:g++). The situation would be
significantly
>>> improved if the outstanding PRs were merged.
>>>
>>> f-r is also python2-only now, which will be a problem soon since
>>> support for python2 is waning [4].
>>>
>>> Is there any hope of upstream and downstream activity on f-r?
>>
>>
>> I was thinking about getting the fedora-review checks rewritten into
the standard Test interface
>> (
https://qa.fedoraproject.org/docs/libtaskotron/latest/standard-test-inter...)
so that they
>> can be run in Taskotron. We can also just probably run one big
fedora-review check from
>> a taskotron test, well, this just came to my mind recently, getting the
actual solution ready
>> might take a little bit of time.
>> '
>
>
>
> I'd *really* like to see us get to a point where package review is
fully-automated. Basically we could just have a web-service that you pass a
URL to an SRPM plus authenticate with your FAS account and it will perform
all of the validity checks and if they all pass would go ahead and request
the branches for you and import the SRPM.
>
> Once this is fully automated, we can then *also* add the same checks to
CI (taskotron, OSCI or whatever) so that on each build it gets rerun, which
will allow us to help reduce the rate of packages falling out of compliance
(as well as being updated whenever the checks get made more comprehensive).
>
> Historically, we've had human review mainly to protect against two
things, bundling and unacceptable licenses. In both of these cases, I'd
like for us to move towards a culture of assuming goodwill on behalf of our
packagers. Most of the packagers in Fedora have been doing it for a long
time and know what is and is not acceptable. Optimizing for the minority
case is wasteful, especially when it adds hurdles and delays to getting
software delivered.
>
> I think what we should instead do is allow things through immediately
following automated review and just assume that those few cases that slip
through that should not will get handled after the fact as soon as they are
noticed (either by someone noticing or an improvement in the automated tool
discovering the problem).
>
> I feel strongly that automated, continuous review would be of far
greater value to Fedora than front-loading the review process the way we
have been doing (which serves mostly to discourage people from even
starting).
I fully agree with this, which is why Tom (Cc'd to this email) and I
have been sketching out a plan to start moving towards this.
It won't be particularly easy, but we're looking at a step-by-step
approach to get there. However, if more people are interested in
contributing to make the end-goal possible, we might be able to get
there more quickly.
Copr team is willing to help.
I think my colleagues will agree with me.
clime
--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...