Queued updates


 

Just wandered how long it takes updates put in the release cue like addons to appear?


Luke Davis
 

Shaun Everiss wrote:

Just wandered how long it takes updates put in the release cue like addons to appear?
As long as it takes. Literally, that's the only answer there is.

Currently, each add-on update has to be manually approved by Reef Turner, one of the NV Access core developers.

To my knowledge, he has never stated publicly what his schedule is for looking at those. Maybe Quentin has some better information, but it seems to happen whenever Reef decides to do it. I think the average may be something like once per month, but it varies.
There are only so many hours in the work day, and only one person doing that in addition to his core development work.

That may be inconvenient for those of us who depend on add-ons (I.E. pretty much everyone), but that's just the way it is.

Luke


 

On Sat, Mar 19, 2022 at 06:29 PM, Luke Davis wrote:
As long as it takes. Literally, that's the only answer there is.
-
And it's not only the answer for NVDA add-ons, either.  

The number of factors that can influence when something that's considered a release-ready piece of software is actually released are myriad.  There are also going to be certain things that are "rubber stamp" type approvals versus others that require a lot more review.

Every time someone asks a, "When will . . .?," question related to software of any sort my answer is always, "It will be released when it is released. And when that happens, you're likely to be alerted to that."
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

Constantly insisting on “my rights” with no consideration of “my responsibilities” isn’t “freedom” — it’s adolescence.
     ~ Commenter, Evangelos, in comments for
         America 2022: Where Everyone Has Rights and No One Has Responsibilities,
        New York Times, February 8, 2022

 


 

Well, I do wander if maybe more people need to be approving stable updates.
What does one need to do to manually approve this stuff or whatever.
I have heaps of time and I can check daily or whenever something is
loaded, maybe I could even help once things get put over or transfer
over things to approve.
I mean once its stable and put as such then you should be able to just
put them out.
I mean how do normal software makers, etc like microsoft run
successfull updates once or so a month.

On 20/03/2022, Luke Davis <luke@...> wrote:
Shaun Everiss wrote:

Just wandered how long it takes updates put in the release cue like addons
to
appear?
As long as it takes. Literally, that's the only answer there is.

Currently, each add-on update has to be manually approved by Reef Turner,
one of
the NV Access core developers.

To my knowledge, he has never stated publicly what his schedule is for
looking
at those. Maybe Quentin has some better information, but it seems to happen

whenever Reef decides to do it. I think the average may be something like
once
per month, but it varies.
There are only so many hours in the work day, and only one person doing that
in
addition to his core development work.

That may be inconvenient for those of us who depend on add-ons (I.E. pretty
much
everyone), but that's just the way it is.

Luke






 

Shaun,

The fact that you could even, for a single moment, muse why a multinational company, such as Microsoft, with more employees in one building than NVAccess has in its entirety, can do things differently shows you have zero grasp of how things work in the world of software development.

That, and you can't just pull "more people" out of your posterior.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

Constantly insisting on “my rights” with no consideration of “my responsibilities” isn’t “freedom” — it’s adolescence.
     ~ Commenter, Evangelos, in comments for
         America 2022: Where Everyone Has Rights and No One Has Responsibilities,
        New York Times, February 8, 2022

 


 

Hi,

In order to review add-ons posted on community add-on files repository, you must:

  1. Balance things: you must be willing to balance between code and human intentions.
  2. Balance things again: you must be willing to balance priorities between add-on authors, users, and NV Access.
  3. Balance things yet again: you must be willing to balance between philosophies of technological progress and backward compatibility.
  4. Balance things a fourth time: you must be willing to balance between the ideal versus reality when it comes to add-on release policy.

In all seriousness, reviewing add-ons (or for that matter, code written by someone else) require balancing and thinking about many things at once. Some of the prominent ones are:

  1. Knowledge and expertise: you may be an expert in your add-on source code but may not be so for code written by others. Sometimes you must (to use a more direct term) wrestle with code written by someone else i.e. it takes time to fully grasp what others are saying to you in a way that could be translated into code both human parties cannot read easily. Just because you feel you can read Python code like a book written in your native language does not mean you can fully grasp what's going on unless you invest some time (sometimes days) to figure out the intentions behind the code you are reading. For this reason, I usually do not advise new add-on authors to review others code unless they have proven that they can explain their own code to a new author (which can take weeks to months to practice).
  2. Understand release policies: there was a discussion on NVDA Add-ons list about unavailability of add-ons declaring themselves ready for NVDA 2022.1 changes. While some add-ons are ready (including mine), due to add-on release policy regarding new NVDA beta releases, authors are holding off on broad availability i.e. approve queued add-ons until NV Access makes an announcement about 2022.1 beta 1. While you can review add-ons and tell others that add-ons are ready for upcoming (vast) changes, others may take your notice as a confirmation rather than a definitive declaration because, again, due to add-on compatibility declaration policy from NV Access (hold off on changing last tested version flag in the manifest until beta 1 is out).

In other words, just because you are telling the community that you will review add-ons does not necessarily mean people would welcome your proposal at once. As I once wrote when talking about GitHub issues and pull requests, you must think, think, and think again carefully before telling people, "okay, I can review add-ons." People would welcome your proposal if you do have a track record of actually writing and maintaining add-ons and understands policies. But reviewing add-ons for sake of compatibility flag... That, to me is, to say it with honesty and sincerity (and bluntly), not welcome (and to use a phrase many businesses and organizations use, "thanks for your interest and applying but we hired someone already"); I'm telling you like this so you can understand reality, or to paraphrase Brian V's response, "the grass is not always greener on the other side".

Cheers,

Joseph


 

But if the addons are reviewed, transfered, used, and are established and are in the publishing cue to go all you would have to say is ok or is there more to that.

I'm no dev though just a user maybe I think of it to simply.



On 20/03/2022 4:58 pm, Joseph Lee wrote:

Hi,

In order to review add-ons posted on community add-on files repository, you must:

  1. Balance things: you must be willing to balance between code and human intentions.
  2. Balance things again: you must be willing to balance priorities between add-on authors, users, and NV Access.
  3. Balance things yet again: you must be willing to balance between philosophies of technological progress and backward compatibility.
  4. Balance things a fourth time: you must be willing to balance between the ideal versus reality when it comes to add-on release policy.

In all seriousness, reviewing add-ons (or for that matter, code written by someone else) require balancing and thinking about many things at once. Some of the prominent ones are:

  1. Knowledge and expertise: you may be an expert in your add-on source code but may not be so for code written by others. Sometimes you must (to use a more direct term) wrestle with code written by someone else i.e. it takes time to fully grasp what others are saying to you in a way that could be translated into code both human parties cannot read easily. Just because you feel you can read Python code like a book written in your native language does not mean you can fully grasp what's going on unless you invest some time (sometimes days) to figure out the intentions behind the code you are reading. For this reason, I usually do not advise new add-on authors to review others code unless they have proven that they can explain their own code to a new author (which can take weeks to months to practice).
  2. Understand release policies: there was a discussion on NVDA Add-ons list about unavailability of add-ons declaring themselves ready for NVDA 2022.1 changes. While some add-ons are ready (including mine), due to add-on release policy regarding new NVDA beta releases, authors are holding off on broad availability i.e. approve queued add-ons until NV Access makes an announcement about 2022.1 beta 1. While you can review add-ons and tell others that add-ons are ready for upcoming (vast) changes, others may take your notice as a confirmation rather than a definitive declaration because, again, due to add-on compatibility declaration policy from NV Access (hold off on changing last tested version flag in the manifest until beta 1 is out).

In other words, just because you are telling the community that you will review add-ons does not necessarily mean people would welcome your proposal at once. As I once wrote when talking about GitHub issues and pull requests, you must think, think, and think again carefully before telling people, "okay, I can review add-ons." People would welcome your proposal if you do have a track record of actually writing and maintaining add-ons and understands policies. But reviewing add-ons for sake of compatibility flag... That, to me is, to say it with honesty and sincerity (and bluntly), not welcome (and to use a phrase many businesses and organizations use, "thanks for your interest and applying but we hired someone already"); I'm telling you like this so you can understand reality, or to paraphrase Brian V's response, "the grass is not always greener on the other side".

Cheers,

Joseph


 

Hi,

Reviewing queued add-ons is a collaborative process that involves:

  • Ad-on author: the author is responsible for documenting changes and making sure the download link is working properly.
  • Reviewer: the reviewer is reponsible for checking to make sure the download link is working and manifest information is consistent with what the add-on author has provided and NV Access's add-on release policy.
  • NV Access: to make sure the add-on info is consistent and merging the data for an add-on that was approved by a reviewer.

Cheers,

Joseph


Russell James
 

Hi Joseph

Thanks for sharing your view of that process

I have often wondered what that would be like in an open source project like nvda

It sounds like software quality assurance on the fly while you're reviewing incoming changes from multiple developers all having different styles and approaches

Do you have any tools that you can use during this process to scan and review the code for conventions or static analysis and security?

I can't help wonder, is the pull request process usually interactive between the reviewer and the author?

Then of course is the availability of the reviewer in the author to do things in a timely manner..

Sounds challenging! :-)

Russ


On Sun, Mar 20, 2022, 4:19 AM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

Reviewing queued add-ons is a collaborative process that involves:

  • Ad-on author: the author is responsible for documenting changes and making sure the download link is working properly.
  • Reviewer: the reviewer is reponsible for checking to make sure the download link is working and manifest information is consistent with what the add-on author has provided and NV Access's add-on release policy.
  • NV Access: to make sure the add-on info is consistent and merging the data for an add-on that was approved by a reviewer.

Cheers,

Joseph


 

Hi,

I'm approaching this question from both software engineering and human communication perspectives (I must confess, if I was to answer this question say, five years ago, I would not have given much thought into the communication aspect of pull requests):

Pull requests are communicative in nature. That is, they involve communication between the host project, project members, pull request authors, users, and passersby/observers/other projects and other external stakeholders. We often think of pull requests as someone posting new features, changes, and bug fixes in the form of code changes. But when we think about the fact that pull requests involve communication, it changes the picture as it introduces concepts such as culture, persuasion, group dynamics, reputation, and ethics.

When searching Google for terms such as "pull requests", "pull request best practices" or similar terms, some of the top results will advise readers to use collaborative approach to pull requests. At least that's a good starting point, but what's often not mentioned is understanding the project culture. In other words, it isn't advisable to submit a pull request that fixes a security issue without first understanding how an open-source project that you are submitting a pull request to operates.

For example, suppose you come across a feature request that you can implement on the spot (as in it will take you hours to implement and test changes since you know what to change in project source code), and this is your first ever contribution to this particular project. After posting your pull request, project members, users, and outside stakeholders will view your changes and provide feedback. If the project itself is known to be friendly toward newcomers (as in feedback is constructivc and members show empathy and genuine concern), then you may feel welcomed to submit changes in the future. On the other hand, if the porject is known to be skeptical of newcomers, then you may need to change your strategy a bit by trying to immerse yourself more into the project culture and build trust before submitting future changes. In the worst case, if the project is okay but its members are not, then you might think about showcasing your talent somewhere else.

The above example highlights an important aspect of pull requests: the success of a pull request depends not merely on code quality, but also on the attitude of project members and the project culture as a whole. Both attitude and culture matter because:

  1. Attitude: software projects are organized by humans from diverse backgrounds, attitudes, and skills. Take NVDA, for example - although the stewards of NVDA screen reader project is NV Access, when you look at Git commit log and contributors list, far more contributions were made by third parties. As humans, developers have differing skill sets, attitudes, and background - some might be kind toward other contributors, while others might not (no, I don't want to single out anyone here). To some degree, member attitude is reflected in pull request feedback, and that can have an impact on how pull request authors feel about the project.
  2. Project culture: as software projects grow, they will create and specify values, norms, and rules for its members, including current and would-be pull request authors. These can include coding standards, ideas about rigor, pull request policies, among others. Therefore, it is normal for pull requests by newcomers to be scrutinized more or not acted upon on a timely manner partly because of the tendency for members to look at changes from in-group members unless the newcomer somehow finds a way to persuade project leaders about the importance of their work (this is why I advise newcomers to build trust and credibility with project members before submitting pull requests).

While I view that member attitude is important, I tend to view culture as a more important factor. Software projects are subcultures under the general culture of software development, and members of the latter culture set expectations about contributions, rigor, code quality, and related concepts. From the viewpoint of someone submitting and reviewing pull requests, it can be stated like this:

  1. Viewpoint of the submitter: you are effectively immersing yourself in a culture that might be different than your own. I'm not talking just about cultures arising from languages, nationalities, class, and other identity markers. Software projects are cultures of their own, and your idea of software rigor and code quality may not be the same as a project's idea of rigor and quality. For this reason, it is important to take time to understand how a project operates before suddenly telling people that you have code changes to be included in the main branch of a given software (tasks such as reading Git log, communicating with users and developers, and reviewing contributino documents can help you understand what is going on).
  2. Viewpoint of a reviewer and project member: you are effectively an ambassador of the project culture you are a part of. As an in-group member, you know how the project operates and understands project expectations. Therefore, when meeting new pull request writers, it is your responsibility to help them get acquainted with norms, values, and rules of the project in a way that is acceptable to newcomers.

Does this mean NVDA is a good software project to send pull requests to? Depends. While NV Access and third-party contributors have set standards such as pull request templates (or rather, NV Access has learned a thing or two from other projects), there could be improvements. This prompts a follow-up question: am I a good and reputable member of NVDA project culture? I'll let you decide (despite Greek philosopher Socrates telling humanity to know yourself, I still have to discover other things about myself).

You might be wondering, why didn't I answer anything about collaboration tools. Tools such as linters and collaborative IDE's (integrated development environments) are important, but I wanted to emphasize and get people to think critically about my opening statement: pull requests are communicative in nature. I know that I took you on a long road to arrive at this point, but when you think about it carefully, you will realize that the best collaborative tool is understanding where others are coming from.

I don't expect all new pull request writers to read my "chapter" above from cover to cover. But one key takeaway is this: treat developers as fellow humans first before telling them about your next code change idea. In other words, understand that people come from different backgrounds. It is not code changes that unites a software project, but having the ability and willingness to accept and build trust with others.

Hope this answers and clarifies hundreds of questions.

Cheers,

Joseph


Dave Grossoehme
 

Hi:  I have to agree with you Russ.  As a coder from many years ago, it brings to view something that all my instructors advised.  Could you advise the coders of the add on programs to give their coding good notes to help a reviewer with this task.  I know, that noting won't help %100, for this.  However, any noting of what is done is better than no notes at all.

Dave


On 3/20/2022 10:38 AM, Russell James wrote:

Hi Joseph

Thanks for sharing your view of that process

I have often wondered what that would be like in an open source project like nvda

It sounds like software quality assurance on the fly while you're reviewing incoming changes from multiple developers all having different styles and approaches

Do you have any tools that you can use during this process to scan and review the code for conventions or static analysis and security?

I can't help wonder, is the pull request process usually interactive between the reviewer and the author?

Then of course is the availability of the reviewer in the author to do things in a timely manner..

Sounds challenging! :-)

Russ


On Sun, Mar 20, 2022, 4:19 AM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

Reviewing queued add-ons is a collaborative process that involves:

  • Ad-on author: the author is responsible for documenting changes and making sure the download link is working properly.
  • Reviewer: the reviewer is reponsible for checking to make sure the download link is working and manifest information is consistent with what the add-on author has provided and NV Access's add-on release policy.
  • NV Access: to make sure the add-on info is consistent and merging the data for an add-on that was approved by a reviewer.

Cheers,

Joseph


 

On Tue, Mar 22, 2022 at 01:35 PM, Dave Grossoehme wrote:
As a coder from many years ago, it brings to view something that all my instructors advised.  Could you advise the coders of the add on programs to give their coding good notes to help a reviewer with this task. 
-
And as a former coder, and project leader, myself I echo this 100%.  Almost all of us eventally learn this, the hard way, when we have to go back and update code we wrote a long while back.  And all the more so if it is in languages (e.g., C and its relatives) that allow you to sometimes be "too clever by half" as far as using the most compact and inscrutable syntax possible for something.

There is no such thing as "self-documenting code."  Some is certainly easier to follow than others, but you still need to have comments, generally brief, but sometimes not so, to describe chunks of code that follow them.  Where those go is a function of what amounts to a logical chunk that does some certain thing within a bunch of code that may do many things overall.

And some of the very best programmers are the ones who, early on, resist commenting because, "I don't need it."   Sure, you probably don't need it while everything is fresh in your mind and you've been working on the same thing for months in one form or another.  But once it's put aside, and you're called back to look at it many months to years later, believe me you will!

You also bless other programmers who've had the courtesy to do appropriate commenting in their code when you have to pick up that code later yourself, or are someone who is doing code review.  Code review is not about trying to figure out what code does.  It's supposed to be about making sure that what the code is claimed to do (which should be commented and/or otherwise documented) is actually done, and in a way congruent with the conventions of the coding house(s) involved.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

Constantly insisting on “my rights” with no consideration of “my responsibilities” isn’t “freedom” — it’s adolescence.
     ~ Commenter, Evangelos, in comments for
         America 2022: Where Everyone Has Rights and No One Has Responsibilities,
        New York Times, February 8, 2022