Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #11859 > unrolled thread

libAWSL: Improving Human Efficiency for debian/copyright Reviewer

Back to article view | Back to linux.debian.project

Contents

  libAWSL: Improving Human Efficiency for debian/copyright Reviewer Mo Zhou <lumin@debian.org> - 2020-05-23 15:10 +0200
    Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer Olek Wojnar <olek@debian.org> - 2020-05-23 23:30 +0200
    Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer Mo Zhou <lumin@debian.org> - 2020-05-24 09:10 +0200
    Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer Sam Hartman <hartmans@debian.org> - 2020-05-26 14:20 +0200
      Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer Michael Lustfield <michael@lustfield.net> - 2020-05-26 21:40 +0200
        Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer Sam Hartman <hartmans@debian.org> - 2020-05-26 22:50 +0200
          Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer Mo Zhou <lumin@debian.org> - 2020-05-27 03:10 +0200

#11859 — libAWSL: Improving Human Efficiency for debian/copyright Reviewer

[Multipart message — attachments visible in raw view] — view raw

Hi Debian Project,
(Human Efficiency Problem is non-technical)

As we know, the human efficiency in the debian/copyright reviewing process
can be optimized, reducing the development cost of the community. However,
the possibilities of performing that kind of optimization are left uncharted.

I'm hereby presenting my "libAWSL" specification, aiming to shed some light
on the software/workflow designing issues on improving human efficiency while
doing the reviewing work on `debian/copyright`:

  https://salsa.debian.org/lumin/awsl/-/blob/master/specification.md

Exhaustive details can be found in the above link. In the following part of
this mail I'm presenting some of the key points in my specification. Note,
I'm trying to do some THEORETICAL discussion on the possibility to improve
human efficiency, INSTEAD OF proposing to enforce anything.

Proposed Principles in Human-Understandable Language
----------------------------------------------------

* The reviewer does not have to review the IDENTICAL file more than once.

* The time complexity for going through a package should be less or equal
  to O(num-of-files).

Explanations can be found at:
 https://salsa.debian.org/lumin/awsl/-/blob/master/specification.md

How Can We Benifit from LibAWSL in Practice
-------------------------------------------

* Instant acceptance for source packages with merely binary package rename
  (without change in upstream code)

* More verbose and structured feedback from ftp team

* Accumulation of precious educational resources, and reducing training cost
  for ftp-trainees

* Convenient new-upstream-release checks for maintainers and reviewers

* Making the reviewing process interruptable

* Possibility for open/collaborated reviewing workflow

Explanations can be found at:
https://salsa.debian.org/lumin/awsl/-/blob/master/specification.md

---

This thread is for non-technical discussions. If it turns out that the
community can reach some common agreement, we can move to the technical
(implementation) discussions on -devel.

Mo,
For sake of a more efficient Debian Community.

[toc] | [next] | [standalone]

#11862

[Multipart message — attachments visible in raw view] — view raw

Hi Mo,

I love this idea, thanks for putting it together! I have not read the
details (yet) but I strongly support your overall purpose. Specifically, I
think that automating repetitive and structured parts of the review process
for both sponsors and the ftp team is a great idea and will benefit our
entire community greatly!

-Olek

[toc] | [prev] | [next] | [standalone]

#11864

Some people are interested in a demonstration program. But sorry, to
make it clear, I confirm that this is merely a theoretical proposal, and
I'm at no liberty and in no position to write the demo program. I have
run out of my motivation to go any further, since I have already done
what I'm willing to do.

I understand that doing nothing is the most comfortable choice for a
human being, but that does not prevent me from thinking constructively.
Though, I quickly found that the negative feelings against the theory
overweighs the positive ones. Anyway, as a cheap theoretical discussion
(talk is cheap), it should not impose pressure and unhappiness on anyone.

I shall call it the end of my participation in this thread. I didn't
violate the code of conduct, and I'm not going to find trouble for anyone.

On Sat, May 23, 2020 at 12:46:45PM +0000, Mo Zhou wrote:
> This thread is for non-technical discussions. If it turns out that the
> community can reach some common agreement, we can move to the technical
> (implementation) discussions on -devel.

[toc] | [prev] | [next] | [standalone]

#11868

Hi.

I've reviewed most of the spec you point to on salsa.

I think you might be getting some of the details before the basic
principles.

I agree with the principles you state, but would  probably state them
differently:
* Incremental review is valuable and is likely to improve our processes
* Minimizing duplicate review or unnecessary re-review is valuable
* getting reviewers the information they need so that they are not being
slowed down searching for it is valuable

* Better tooling can help with the above.

I tend to agree with all those principles and believe they are similar
in spirit to what you state.

Unfortunately, being a member of Debian, I find myself getting stuck in
the details and think you may have gotten a few things wrong.

* I think that reviewing a file every time the salt changes is too
  frequent.
  It is a sign that we might need to review, not that we certainly do.
  We don't tend to review files every time they change today, and I
  think pushing toward this would be problematic.

* Unfortunately the srcpkg-bool problem does not decompose into a set of
  file-bool problems the way you describe.
  The issue is license compatibility.
  Two licenses may be DFSG-free, but their combination may not be
  distributable (and thus not DFSG-free).



Next Steps

The biggest thing I see missing here is what are the next steps?
If we agree with your principles, what next?
How does this work go forward?

[toc] | [prev] | [next] | [standalone]

#11869

On Tue, 26 May 2020 08:13:24 -0400
Sam Hartman <hartmans@debian.org> wrote:

> Unfortunately, being a member of Debian, I find myself getting stuck in
> the details and think you may have gotten a few things wrong.
> 
> * I think that reviewing a file every time the salt changes is too
>   frequent.
>   It is a sign that we might need to review, not that we certainly do.
>   We don't tend to review files every time they change today, and I
>   think pushing toward this would be problematic.

At the moment, when a package hits binNEW or NEW, *all* files need to be
re-checked by the reviewer. There is no single-file review. This is appropriate
because there are many times where code copies have been added to the source
but not added to d/copyright. Some of these code copies are even embedded in
previously-reviewed files that have another license.

Pushing this direction would reduce efforts, not increase them.

> * Unfortunately the srcpkg-bool problem does not decompose into a set of
>   file-bool problems the way you describe.
>   The issue is license compatibility.
>   Two licenses may be DFSG-free, but their combination may not be
>   distributable (and thus not DFSG-free).

Two DFSG-free but incompatible licenses is a non-trivial concern and likely
only caught in more extreme cases. This is really something that should become
a lintian check that only reads through d/copyright.

> Next Steps
> 
> The biggest thing I see missing here is what are the next steps?
> If we agree with your principles, what next?
> How does this work go forward?

Mo has made it clear that his ambition has run out. However, we had many
discussions, including with ftpteam members, prior to either of our
announcements. In a sense, libAWSL is aimed at being both a stand-alone utility
as well as a module usable by the project I previously described.

It's probably worth noting, based on previous conversation, I don't expect
anyone in ftpteam would want to see anything discussed implemented as a formal
review tool. Therefor, my own goal is to ultimately build a tool that focuses on
package uploaders, so that they can be confident their package will be approved.

If there are developers interested in working on this tool, I'd be happy to
discuss further in #debian-review and write an actual requirements document to
aid collaboration and development.

[toc] | [prev] | [next] | [standalone]

#11870

>>>>> "Michael" == Michael Lustfield <michael@lustfield.net> writes:

    Michael> On Tue, 26 May 2020 08:13:24 -0400
    Michael> Sam Hartman <hartmans@debian.org> wrote:

    >> Unfortunately, being a member of Debian, I find myself getting
    >> stuck in the details and think you may have gotten a few things
    >> wrong.
    >> 
    >> * I think that reviewing a file every time the salt changes is
    >> too frequent.  It is a sign that we might need to review, not
    >> that we certainly do.  We don't tend to review files every time
    >> they change today, and I think pushing toward this would be
    >> problematic.

    Michael> At the moment, when a package hits binNEW or NEW, *all*
    Michael> files need to be re-checked by the reviewer. There is no
    Michael> single-file review. This is appropriate because there are
    Michael> many times where code copies have been added to the source
    Michael> but not added to d/copyright. Some of these code copies are
    Michael> even embedded in previously-reviewed files that have
    Michael> another license.

    Michael> Pushing this direction would reduce efforts, not increase
    Michael> them.

I think you and Mo are a bit stuck in the ftp-team mindset with the
above.  *whenever new or bin-new is triggered, all files are reviewed.*
But to an outsider, what it sounds like Mo is proposing is that whenever
the salt is changed, review needs to be triggered, even if new would not
be triggered in the current model.

My thoughts are that
1) I think it's worth being clear that you're not proposing increasing
the rounds of new review.

2) Long term, having a persistent database of review state might allow
us to have better criteria for when to trigger license review.

--Sam

[toc] | [prev] | [next] | [standalone]

#11871

[Multipart message — attachments visible in raw view] — view raw

Hi Sam,

Even if I said I'll no longer participate, there are some
substantial misunderstandings to correct.

On Tue, May 26, 2020 at 04:44:49PM -0400, Sam Hartman wrote:
> I think you and Mo are a bit stuck in the ftp-team mindset with the
> above.  *whenever new or bin-new is triggered, all files are reviewed.*

It's designed for people who "review all the files" when the package
turns to be NEW. For example, one who is about to upload a NEW package.
This aims to speed up a **rigorous** review, instead of a much less
rigorous review. Generally reviewing things quickly and carelessly makes
the life of every uploader much easier -- but that means more burden for
our last shield, ftp team.

Again, the specification talks about how the status of files are changed
in the status space {"N/A", "outdated", "ACCEPT", "REJECT"}, which is a
pure interpretation of the modeling of the process, and it did not say
any preference on political stuff such as "when the review should be
triggered" -- I have no intention to talk about it. My specification is
invariant to the review whatever frequency people prefer. If people
prefer to do the review after every git commit, libawsl can be useful.
If people prefer to slack off and only do the review when the package
has to go through the new queue again, libawsl can also be useful.

> But to an outsider, what it sounds like Mo is proposing is that whenever
> the salt is changed, review needs to be triggered, even if new would not
> be triggered in the current model.

Talking about how the file status move in the status space
  {"N/A", "outdated", "ACCEPT", "REJECT"}
does not imply any preference on the frequence of review.

Why not take git as an example?

 "N/A": the user didn't git add <this-file>
 "outdated": <this-file> has been changed, stage and commit it when user
             sees appropriate.
 "accept": <this-file> has not been changed, nothing to do
 "reject": ? no analogous concept, but it does not matter.

When did git urge people to stage files, do commits, or push when it
gets unhappy about the modified files and unsynced tree status?  Is the
git efficiency seriously impacted by "how frequent the user does
commits", "how frequent the user does commits"?

Similarly, when did libawsl urge people to do the review once the file
status has been changed?
 
> My thoughts are that
> 1) I think it's worth being clear that you're not proposing increasing
> the rounds of new review.

No. libawsl is independent and ignorant to the review frequency. It is
designed to **help human** when they need to do a review, not designed
to **prod or force people** to do review once it gets unhappy.
 
> 2) Long term, having a persistent database of review state might allow
> us to have better criteria for when to trigger license review.

libawsl can use a persistent database to reduce redundant reviews, as
long as the salthash do match. There is no design consideration on given
answers to questions such as "when to trigger a review". Whatever the
review frequency is, libawsl is invariant and will do its job.
 
> --Sam

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web