Date   

Development Environment Setup on Linux — Zephyr Project Documentation

luobaidunpaigu@sina.com <luobaidunpaigu@...>
 

Dear All

I got a trouble when installing zephyr SDK on Ubuntu 16.04.2 desktop i386  (32 bit)
The Requirements and Dependencies are installed correctly.
The message is:
----------------------------------------------------------------------------------------------------------- 
peng@ubuntu:~/work$ sudo ./zephyr-sdk-0.9.1-setup.run 
Verifying archive integrity... All good.
Uncompressing SDK for Zephyr  100%  
Enter target directory for SDK (default: /opt/zephyr-sdk/): 
Installing SDK to /opt/zephyr-sdk
 [*] Installing x86 tools... 
 [*] Installing arm tools... 
 [*] Installing arc tools... 
 [*] Installing iamcu tools... 
 [*] Installing nios2 tools... 
 [*] Installing xtensa tools... 
 [*] Installing riscv32 tools... 
 [*] Installing additional host tools... 
rm: cannot remove 'environment-setup*': No such file or directory
mv: cannot stat 'version-*': No such file or directory
Success installing SDK. SDK is ready to be used.
--------------------------------------------------------------------------------------------------------
I checked the default folder.  Only 

info-zephyr-sdk-0.9.1(empty folder)
sdk_version

existed there.

Is there anyone can help me. Is this SDK only for 64bit system?


luobaidunpaigu@...


Re: CAN drivers

Erwin Rol
 

On Wed, 2017-07-19 at 16:55 +0300, Jukka Rissanen wrote:
Hi Erwin,

On Wed, 2017-07-19 at 14:39 +0200, Erwin Rol wrote:
Hallo all,

I am working on a CAN driver for STM32F4 and am having a few
conceptual
problems. How to generalize the interface to hardware that can be
very
different. For example the hardware-msg-filtering, two selectable
receive FIFO's, the second CAN port shares hardware with the first
port,
etc. are rather unique to the STM32 hardware. Other CAN controllers
have other features.

This is not just a CAN-driver problem, a same problem is setting the
multicast-filters of Ethernet hardware, they also come in a lot of
different flavors.

So how do I offer a Zephyr application a generic CAN interface (or
device interface for that matter)? If I make is
lowest-common-denominator generic (for CAN just sending and receiving
CAN frames) a lot of advanced feature will be lost that might really
make a difference between a working and non-working application (for
example hardware filtering that prevents CPU/IRQ overload).
We could follow the same idea as IEEE 802.15.4 radio API is doing. So
each CAN hw driver would need to provide a set of function pointers to
do various CAN operations. See include/net/ieee802154_radio.h for
details.

For doing various management operations, we have the net_mgmt interface
that should be used. See include/net/net_mgmt.h for details.
OK I'll look into that to see how it fits my needs (and if it isn't to
much more work how it would fit other ppl's needs).

For application that wants to send/receive actual CAN data, do we need
to create a new API for that, or could we extend the current
net_context API to support CAN interfaces? So similar way as what Linux
is doing things with SocketCAN.
I am not sure if that is the right way to go for resource constraint
systems like Zephyr.

First CAN frames are really small, they have maximum 8 data bytes, 4 len
bits, 29 ID bits and some flag bits. So a CAN frame struct would be
something like;

struct can_frame {
u32 id;
u8 data[8];
u8 len_flags;
}

And even CAN-FD has only 64 data bytes, so still smaller than a useful
net_pkt buffer size (default 128 bytes I believe). So all stuff to chain
packets/frames is useless for CAN, and just causes memory overhead.

Secondly there can be a lot of frames per second, CAN is a broadcast
bus, and everybody receives everything (unless they have hardware to
filter out certain frames). And with 1Mbit/s you could have almost 10k
frames per second.

Keeping those two things in mind I would want to keep the handling
overhead as small as possible.

But the low level CAN driver is just one part, mostly there will be
something like CANopen (which isn't as open as the name suggests :/)
running on top of it. Maybe CANsockets can also be a layer on top of the
low level CAN driver? I have not yet looked at the net_pkt buffers in
detail, but maybe the CAN-frame buffer could just be the data part, and
so one could do a zero-copy transformation from a CAN-frame into a
network packet ?

- Erwin


Re: CAN drivers

Jukka Rissanen
 

Hi Erwin,

On Wed, 2017-07-19 at 14:39 +0200, Erwin Rol wrote:
Hallo all,

I am working on a CAN driver for STM32F4 and am having a few
conceptual
problems. How to generalize the interface to hardware that can be
very
different. For example the hardware-msg-filtering, two selectable
receive FIFO's, the second CAN port shares hardware with the first
port,
etc.  are rather unique to the STM32 hardware. Other CAN controllers
have other features. 

This is not just a CAN-driver problem, a same problem is setting the
multicast-filters of Ethernet hardware, they also come in a lot of
different flavors. 

So how do I offer a Zephyr application a generic CAN interface (or
device interface for that matter)? If I make is
lowest-common-denominator generic (for CAN just sending and receiving
CAN frames) a lot of advanced feature will be lost that might really
make a difference between a working and non-working application (for
example hardware filtering that prevents CPU/IRQ overload).
We could follow the same idea as IEEE 802.15.4 radio API is doing. So
each CAN hw driver would need to provide a set of function pointers to
do various CAN operations. See include/net/ieee802154_radio.h for
details.

For doing various management operations, we have the net_mgmt interface
that should be used. See include/net/net_mgmt.h for details.

For application that wants to send/receive actual CAN data, do we need
to create a new API for that, or could we extend the current
net_context API to support CAN interfaces? So similar way as what Linux
is doing things with SocketCAN.


If I make a load of stm32_can_set_filter functions every CAN
application
will be different and only run on just that stm32 hardware. 

If I make something like the linux-ioctl we will need some "registry"
to
manage those.

I am sure others have had these "problems" also, but I can't really
recognize a pattern in the Zephyr code to use as an example.

Guidance, hints, and comments are highly appreciated.  

- Erwin
 
Cheers,
Jukka


CAN drivers

Erwin Rol
 

Hallo all,

I am working on a CAN driver for STM32F4 and am having a few conceptual
problems. How to generalize the interface to hardware that can be very
different. For example the hardware-msg-filtering, two selectable
receive FIFO's, the second CAN port shares hardware with the first port,
etc. are rather unique to the STM32 hardware. Other CAN controllers
have other features.

This is not just a CAN-driver problem, a same problem is setting the
multicast-filters of Ethernet hardware, they also come in a lot of
different flavors.

So how do I offer a Zephyr application a generic CAN interface (or
device interface for that matter)? If I make is
lowest-common-denominator generic (for CAN just sending and receiving
CAN frames) a lot of advanced feature will be lost that might really
make a difference between a working and non-working application (for
example hardware filtering that prevents CPU/IRQ overload).

If I make a load of stm32_can_set_filter functions every CAN application
will be different and only run on just that stm32 hardware.

If I make something like the linux-ioctl we will need some "registry" to
manage those.

I am sure others have had these "problems" also, but I can't really
recognize a pattern in the Zephyr code to use as an example.

Guidance, hints, and comments are highly appreciated.

- Erwin


Disabling of the GitHub Issues Feature

Linkmeyer, Mark J <mark.j.linkmeyer@...>
 

The Zephyr Technical Steering Committee (TSC) has not yet made a decision on whether GitHub Issues will be eventually used for issue tracking instead of Jira.  Because of that the Issues feature of GitHub has been disabled for the Zephyr Project.  The TSC has stated, in a recent TSC meeting,  that Jira will continue to be used for issue tracking through the release of Zephyr 1.9.  No potential issue tracking tool change will impact the 1.9 release.  A TSC decision on whether to switch to GitHub Issues is pending.  Until then, please continue to use Jira for all issue tracking on the Zephyr project.
 
The following issues, which were recently found to have been created in GitHub Issues, have been moved to Jira:
 
GitHub Issue # 779
 
GitHub Issue # 758 --->
 
GitHub Issue # 752 --->
 
GitHub Issue # 729 --->
 
GitHub Issue # 652 --->
 
Please continue any discussions on these issues and all tracking of them to completion using Jira.  I did my best to copy-and-paste all content and comments into Jira.  If anything is missing or incorrect, please fix it.
 
If you have issues/concerns with the use of Jira, please submit your specific issues to the Zephyr Process Working Group using the Process WG’s mailing list (process@...).  Or, even better yet, use Jira to submit bugs against the process.  The Process WG actively monitors Jira for any bugs submitted against Zephyr processes (and this includes tools used to facilitate the process, like Jira).  Simply create a bug in Jira, describe the issue you encounter, and be sure to set the Component/s field to ‘Process’.  It will then be driven to closure by the Process WG members.
 
Thanks,
Mark
 
Mark Linkmeyer
Intel Corporation
Open Source Technology Centerà Zephyr™ Software Project Manager
 
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or attorney-client privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message.
 
 
 


Re: What happened to github issue tracker?

Paul Sokolovsky
 

Hello Andrew,

On Tue, 18 Jul 2017 16:04:01 +0000
"Boie, Andrew P" <andrew.p.boie@intel.com> wrote:

Why were bugs being filed on Github instead of JIRA?
It would be interesting to ask someone who posted a first bug on Github
why they did that. But I'd imagine the answer would be "The project is
on github, bug tracker is on github, where else should I post bugs???"

I can explain why I gave up and started to submit bugs on Github too,
like other people did - because it's awfully practical, can be
done quickly, allows to xref other bugs/pullreqs/commits, etc.

Having two simultaneous bug tracking systems in use seems insane to
me.
I guess we can always switch to github tracker ahead of schedule.


But the question is why Github tracker, containing important
information (down-to-earth, daily bugs vs mostly "something for
[distant] future" in Jira) was disabled without a prior notice.



Andrew


-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of
Paul Sokolovsky Sent: Tuesday, July 18, 2017 3:07 AM To:
devel@lists.zephyrproject.org; Nashif, Anas <anas.nashif@intel.com>
Subject: [Zephyr-devel] What happened to github issue tracker?

Hello,

Some people started to use Github's project issue tracker at
https://github.com/zephyrproject-rtos/zephyr to file routine issues
(*not* epics or user stories) - for example, regression reports after
recently merged patches.

Today, suddenly, access to Github issue tracker is blocked,
corresponding tab is removed from the page above. And nothing here on
the mailing list.

Please re-enable the issue tracker, as it already contains important
information required to work on the quality 1.9 release.

Thanks.

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro:
http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg
- http://www.linaro.org/linaro-blog
_______________________________________________ Zephyr-devel mailing
list Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: What happened to github issue tracker?

Boie, Andrew P
 

Why were bugs being filed on Github instead of JIRA?
Having two simultaneous bug tracking systems in use seems insane to me.

Andrew

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky
Sent: Tuesday, July 18, 2017 3:07 AM
To: devel@lists.zephyrproject.org; Nashif, Anas <anas.nashif@intel.com>
Subject: [Zephyr-devel] What happened to github issue tracker?

Hello,

Some people started to use Github's project issue tracker at https://github.com/zephyrproject-rtos/zephyr to file routine issues
(*not* epics or user stories) - for example, regression reports after recently merged patches.

Today, suddenly, access to Github issue tracker is blocked, corresponding tab is removed from the page above. And nothing here on the mailing list.

Please re-enable the issue tracker, as it already contains important information required to work on the quality 1.9 release.

Thanks.

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Development is hard if you can't trust your compiler (aka gcc6 did it again)

Paul Sokolovsky
 

Hello Daniel,

On Tue, 18 Jul 2017 14:30:06 +0100
Daniel Thompson <daniel.thompson@linaro.org> wrote:

On 18/07/17 13:50, Paul Sokolovsky wrote:
Hello,

Previously, there already were examples of the compiler fanciness:
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-March/007426.html

Here's another one, which is a pure bug. Given code like:

int i;
if (pollnum < NUM_FDS) {
i = pollnum++;
} else {
for (i = 0; pollfds[i].fd >= 0; i++) {
if (i >= NUM_FDS) {
return -1;
}
}
}
What is the definition of pollfds; if is has NUM_FDS elements then
the bug is in the code above rather than being in the compiler!
Heh, removing all I wrote in the unsent version of this reply, indeed,
it's my bug. It's the "for" played bad trick on me, seeing its surface
form one can forget that first "for"'s condition is checked, then "if"
inside is checked, and only then "for"'s trailing operation is executed.
Apparently, I subconsciously wanted the inside "if" to run after
increment, d'oh!

So, I withdraw "the real bug" valuation, it's just another case when
very well defined "undefined" behavior is turned by outsmart
compiler into truly undefinable behavior (all for programmer's good, as
in this case - I of course rewrote that loop before submitting it, btw
it was written like that in the first place to avoid "goto" (or
checking the same var twice, which is no-no!)).

Daniel.
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


rom_report total size doesn't match section sizes

Timothee Jurie <timothee.jurie@...>
 

Hello,

I tried using the rom_report make option but the output seems very strange.

The size of each section (e.g. kernel, driver), doesnt match the total size at the end of the report. The difference is quite huge, in my test app the total size is 5.3 kB, whereas when adding each section manually I get 3.5 kB.

Is this a bug ? did I miss something ?

While trying to understand the size_report python script I found this commentary :136 #Actual .bin size, which doesn't not always match section sizes, is this related ?

Best Regards,

Timothée Jurie


Re: Development is hard if you can't trust your compiler (aka gcc6 did it again)

Daniel Thompson <daniel.thompson@...>
 

On 18/07/17 13:50, Paul Sokolovsky wrote:
Hello,
Previously, there already were examples of the compiler fanciness:
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-March/007426.html
Here's another one, which is a pure bug. Given code like:
int i;
if (pollnum < NUM_FDS) {
i = pollnum++;
} else {
for (i = 0; pollfds[i].fd >= 0; i++) {
if (i >= NUM_FDS) {
return -1;
}
}
}
What is the definition of pollfds; if is has NUM_FDS elements then the bug is in the code above rather than being in the compiler!


Daniel.


Development is hard if you can't trust your compiler (aka gcc6 did it again)

Paul Sokolovsky
 

Hello,

Previously, there already were examples of the compiler fanciness:
https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-March/007426.html

Here's another one, which is a pure bug. Given code like:

int i;
if (pollnum < NUM_FDS) {
i = pollnum++;
} else {
for (i = 0; pollfds[i].fd >= 0; i++) {
if (i >= NUM_FDS) {
return -1;
}
}
}

i586-zephyr-elf-gcc (gcc 6.2.0), as used for qemu_x86, completely
removes "if" inside the loop. Volatile for i helps and makes it
generate the correct code.

Just checked arm-zephyr-eabi-gcc and it has the same problem (well, the
core generated appears event weirder).

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


What happened to github issue tracker?

Paul Sokolovsky
 

Hello,

Some people started to use Github's project issue tracker at
https://github.com/zephyrproject-rtos/zephyr to file routine issues
(*not* epics or user stories) - for example, regression reports after
recently merged patches.

Today, suddenly, access to Github issue tracker is blocked,
corresponding tab is removed from the page above. And nothing here on
the mailing list.

Please re-enable the issue tracker, as it already contains important
information required to work on the quality 1.9 release.

Thanks.

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: STM32F0 nucleo board support.

Bobby
 

Hello Maciej,

I'm interested in STM32F091x support and would like to contribute. 
Do you have a git repository to clone (and coordinate) the basic work on STM32F0x?

Bobby


Schedule change for Zephyr 1.9 affects M2 and M3 Milestones

Linkmeyer, Mark J <mark.j.linkmeyer@...>
 

Per the Zephyr Technical Steering Committee’s (TSC) recent guidance, there are schedule changes for the M2 Checkpoint and the M3 Milestone that I want to make you aware of.  Both M2 and M3 have been pushed out by one week.  The schedule change also shortens the Stabilization Period by one week.  See the trend dates in the current 1.9 schedule found here: https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management#planned-trend-and-actual-dates.
 
If you need a reminder about what the different milestones mean and what is expected to be done by each of them, please look at the definitions here: https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management#milestone-definitions
 
Key takeaways:
  • Major Features should be ready for code review by M2 (July 19th instead of July 12th) – yes, that’s two days from now
  • The Feature Merge Window for 1.9 closes at M3 (Aug 9th instead of Aug 2nd)
 
If you have any questions about this, please let me know.
 
Thanks,
Mark
 
Mark Linkmeyer
Intel Corporation
Open Source Technology Centerà Zephyr™ Software Project Manager
 
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or attorney-client privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message.
 
 
 


Re: Docker Image for ARM Boards

Agustin Henze
 

Hi Kumar,

On 07/14/2017 12:57 PM, Kumar Gala wrote:
We do have a docker environment that we use for CI as part of the project that we don’t really advertise much. Have you taken a look at:

https://github.com/zephyrproject-rtos/ci-dockerfiles

The one we use for CI is under shippable/

Also:

https://hub.docker.com/u/zephyrprojectrtos/
I have taken a look at it and I saw some things a little bit weird like

```
wget https://launchpad.net/ubuntu/+archive/primary/+files/ccache_3.3.3-1_amd64.deb
dpkg -i ccache_3.3.3-1_amd64.deb
```

or

```
add-apt-repository ppa:ubuntu-toolchain-r/test
wget -O - http://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add -
apt-add-repository "deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-3.9 main"
apt-get update
apt-get install gcc-6 g++-6 clang-3.9 lldb-3.9
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 50 --slave
/usr/bin/g++ g++ /usr/bin/g++-6
update-alternatives --install /usr/bin/gcov gcov /usr/bin/gcov-6 50
```

Maybe it is really needed I don't have the enough context here but I think that
it is a little bit messy to maintain. I just dropped some commits modifying my
first approach and splitting into three images.

zephyr-docker-core[0]
/\
/ \
/ \
/ \
/ \
zephyr-arm zephyr-docker-ci

`zephyr-arm is`[1] for development, it has openocd, gdb and qemu installed for arm.

`zephyr-docker-ci`[2] it has the same or try to have the same recipe that the
current image `zephyrprojectrtos/ci` but inheriting from `zephyr-docker-core`
image. I couldn't test it on the current environment because I never used
shippable, so if anyone want to test it or tell me how it'd be great. The main
difference is debian:stretch based not ubuntu. It removes the hardcoded version
installed of ccache, gcc and llvm.

If there is any interest on this, I'd be glad sending PRs to ci-dockerfiles
repository.

[0] https://github.com/agustinhenze/zephyr-docker-core
[1] https://github.com/agustinhenze/zephyr-arm
[2] https://github.com/agustinhenze/zephyr-docker-ci

--
TiN


Re: Docker Image for ARM Boards

Kumar Gala
 

On Jul 14, 2017, at 10:13 AM, Agustin Henze <tin@aayy.com.ar> wrote:

Hello, today I have started my first steps on zephyr and I am completely happy
to see an RTOS prepared for the future :).

After my first steps, I don't know... 5 minutes? :D. I decided to write the
recipe to have an environment ready to build and run application (emulated or
via jtag). Here it goes https://hub.docker.com/r/agustinhenze/zephyr-arm/

I hope that someone else find this useful and of course any suggestion,
improvement, contribution, etc is welcomed.

We do have a docker environment that we use for CI as part of the project that we don’t really advertise much. Have you taken a look at:

https://github.com/zephyrproject-rtos/ci-dockerfiles

The one we use for CI is under shippable/

Also:

https://hub.docker.com/u/zephyrprojectrtos/

- k


Docker Image for ARM Boards

Agustin Henze
 

Hello, today I have started my first steps on zephyr and I am completely happy
to see an RTOS prepared for the future :).

After my first steps, I don't know... 5 minutes? :D. I decided to write the
recipe to have an environment ready to build and run application (emulated or
via jtag). Here it goes https://hub.docker.com/r/agustinhenze/zephyr-arm/

I hope that someone else find this useful and of course any suggestion,
improvement, contribution, etc is welcomed.

--
TiN


Re: Issue #682

Luiz Augusto von Dentz
 

Hi,

Second try:

https://github.com/zephyrproject-rtos/zephyr/pull/777


On Sun, Jul 9, 2017 at 6:02 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
Hi,

Since it seems this issue is flying under the radar lets have it first
discussed here since there might be implemented for the general design
of many kernel objects:

https://github.com/zephyrproject-rtos/zephyr/pull/682

So many of the insert/push APIs do end up doing the following:

if (first_pending_thread) {
prepare_thread_to_run(first_pending_thread, data);
if (!_is_in_isr() && _must_switch_threads()) {
(void)_Swap(key);
return;
}
} else {
sys_slist_insert(&queue->data_q, prev, data);
if (handle_poll_event(queue)) {
(void)_Swap(key);
return;
}
}

So the first part just basically bypass the list entirely and post the
data directly into thread's swap_data, thus making it impossible to
cancel. There is however a way to fix this in case of k_work, but it
does involve using k_poll instead of k_fifo_get, as in that case the
list insert is used we can, in fact, remove the items, though the
workqueue thread still wakes up but using k_fifo_get would return NULL
which we could basically ignore as it seems to be an acceptable
behavior since it is the current way to wakeup waiters.

If we do decide to use k_pool in k_work we will obviously need to
rework the kconfig to add a dependency, so either k_work is no longer
built-in by default and we do have a config option for it, e.g:
CONFIG_WORK, or we remove CONFIG_POLL and make it always available.
Both ways there will be an increase in the memory requirements.

In case we do want k_poll to be built-in by default we may as well
redesign this code around posting data directly to thread's swap data,
instead, everything would be done via k_poll then we only need
handle_poll_event to do its magic.

--
Luiz Augusto von Dentz


--
Luiz Augusto von Dentz


Re: GitHub workflow issue: Dismissing your own review

Paul Sokolovsky
 

Hello Yannis,

On Thu, 13 Jul 2017 14:20:30 +0300
Yannis Damigos <giannis.damigos@gmail.com> wrote:

I spotted a following issue: if I gave negative ("change requested")
review (or just the same, positive review), I don't seem to be able
to change it back to "no review".
[]

https://help.github.com/articles/dismissing-a-pull-request-review
mentions "repository administrators or people with write access can
dismiss a review"
Thanks for confirming this. I by now also submitted a Github report,
it borders on a bug that a review author can't dismiss their own review.


Yannis


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: GitHub workflow issue: Dismissing your own review

Yannis Damigos
 

On Thu, Jul 13, 2017 at 2:12 PM, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:
Hello,

I spotted a following issue: if I gave negative ("change requested")
review (or just the same, positive review), I don't seem to be able to
change it back to "no review".

For example, if I looked at some patch and spotted a glaring typo, I'd
feel that warrants "requesting a change". But once submitter fixes it,
I can't reset my review to the neutral state. The only choice is to
approve the PR, but often, that's not a choice because I didn't review
PR in full, or not familiar enough with some subsystem.

https://github.com/blog/2265-dismissing-reviews-on-pull-requests
tells that review dismissal is possible, but doesn't document who can
dismiss a review. I definitely don't see "Dismiss review" links like
shown there, and can't dismiss my own review (which is of course a bug
in Github).

Can someone give suggestions what to do in this case? In particular,
can people with merge permissions check if they're shown "Dismiss
review" links like above?


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
Hello,

https://help.github.com/articles/dismissing-a-pull-request-review
mentions "repository administrators or people with write access can
dismiss a review"

Yannis

5401 - 5420 of 8517