[Vote] Combined vote about kernel, releases, lists, new logo, dev platform and bugs removal

Petr Štetiar ynezz at true.cz
Mon Jan 20 05:17:51 PST 2020


Hello,

below you can find a combined voting for 5 different topics for the first time
in the voting history, in order to save time and move forward faster without
any doubts. Please note that only one choice from multiple choices is
possible. Try to make voting results machine readable, so use only [x] or [X]
as a mark for your choice in the answer to the question, for example:

    Question: Foo?

       0.1 [x] Yes!
       0.2 [ ] Never
       0.3 [ ] None of the above

This voting should be ideally finished within 7 days, please kindly try to
provide your response in time.  Double check, that you've provided answer to
all 5 topics, so count number of [x]s, which should be 5 :-)

Happy voting!


1. Selecting kernel version for the next release

 The 19.07 release was delayed by a few months, so this has affected the
 subsequent release as well, impacting previously selected LTS kernel 4.19 as
 another LTS kernel 5.4 has been released in the meantime. So we're now facing
 a tough choice, which kernel should we use in the next release.

 Pros for kernel 5.4 (released 2019-11-24, projected EOL 12/2021):

   * staying closer to upstream 5.x version, where all the development happens
   * lower maintenance effort, decreasing the amount of backported patches
   * longer upstream support period
   * we would have more time to rebase/test ramips/layerscape targets from 4.14 to 5.4

 Pros for kernel 4.19 (released 2018-10-22, projected EOL 12/2020):

   * it's possible to have 20.03 release
   * we're not partially throwing away many months of work and testing
   * it has been tested for some time already on most platforms (ramips and
     layerscape missing)


 Question: What is your preference for kernel version in the next release?

  1.1 [ ] I'm in favor of having a release soon (20.03) with 4.19 kernel
  1.2 [ ] I'm in favor of skipping kernel 4.19 and focusing on the 5.4 kernel
          for the next release


2. Establishing `openwrt-announce` mailing list as additional communication channel

 There were two attempts[2a,2b] since 6/2019 to create an additional email based
 communication channel, which would be low traffic, used for releases, security
 advisories, and other important information.

  2a. http://lists.infradead.org/pipermail/openwrt-adm/2019-June/001074.html
  2b. http://lists.infradead.org/pipermail/openwrt-adm/2019-November/001206.html


 Question: Do you agree, that the project needs additional `openwrt-announce` mailing list?

  2.1 [ ] Yes, I agree
  2.2 [ ] No, I'm against this proposal

   (If you vote No, please try to be constructive and provide your opinion)


3. New official project logo and colors

 It's more than clear that the project needs a refresh of its identity. This
 topic[3a] has been discussed on the last developer meeting in Hamburg 2019
 and on the mailing list as well[3b].

 Community has helped to pre-select[3c] new OpenWrt project logos and colors
 in two iterations, which took place on the forum. You can find respective
 images of new logo variants and colors in that forum[3c] post as well.

  3a. https://openwrt.org/meetings/hamburg2019/start#refresh_project_identity
  3b. http://lists.infradead.org/pipermail/openwrt-adm/2019-October/001166.html
  3c. https://forum.openwrt.org/t/help-pre-select-new-openwrt-project-logo-in-the-poll


 Question: Which new logo variant is your favorite and should become the new official logo?

  3.1 [ ] Variant E
  3.2 [ ] Variant F
  3.3 [ ] Variant G
  3.4 [ ] Variant H
  3.5 [ ] None of the above

   (If you vote 'None of the above', please try to be constructive and provide
    your opinion)

   (If unsure, vote for Variant G which was pre-selected by community with 68
    votes out of 155 total)


4. Defragmentation of source code hostings and tools

 One of the topics[4a] discussed on the last developer meeting in Hamburg 2019
 was fragmentation of our support tools, like source code hosting places
 (GitHub.com/self-hosted Gitolite), incoming contribution pipelines
 (Patchwork/GitHub.com PRs) and bug trackers (GitHub.com issues/FlySpray).

 The idea behind this vote is unification of the development into one common
 place, switching to modern tooling which would allow us to move forward
 faster, due to possible automation of various daunting and repeating tasks
 like formal PR/patch reviews, issue management and CI testing for improved
 QA, to just name a few.

 BTW for a few of us, self-hosted GitLab already looked like a viable
 alternative to the current situation, so we went ahead and created
 bugs/source code migration scripts already[4b] and started evaluating GitLab
 by using it for OpenWrt CI[4c] in C projects, like for example libubox[4d].
 It's now also possible to build staging trees on GitLab CI[4e].

 4a. https://openwrt.org/meetings/hamburg2019/start#defragmentation_of_code_and_tools
 4b. https://gitlab.com/openwrt/gitlab-evaluation
 4c. https://gitlab.com/ynezz/openwrt-ci/
 4d. https://gitlab.com/openwrt/project/libubox/pipelines/105941428/builds
 4e. https://gitlab.com/ynezz/openwrt/commit/d9d1142f41428a78df60d7494ccef8571fdd26c8


 Question: What should be our next development platform?

  4.1 [ ] GitHub.com
  4.2 [ ] GitHub.com + Patchwork OR similar mail based workflow
  4.3 [ ] GitLab.com
  4.4 [ ] GitLab.com + Patchwork OR similar mail based workflow
  4.5 [ ] self-hosted GitLab
  4.6 [ ] self-hosted GitLab + Patchwork OR similar mail based workflow
  4.7 [ ] None of the above

   (If you vote 'None of the above', please try to be constructive and provide
    your opinion)


5. Auto-close bugs for EOL branches/releases at bugs.openwrt.org (FlySpray)

 FlySpray allows to assign bugs to a certain branch, and currently we still
 have a lot of bugs reported in the now-EOL 17.01 branch. This vote is about
 having all bugs reported specifically for a certain branch closed when that
 branch is EOL. This should be accompanied by a message to retest on a more
 recent version and resubmit the bug report for the new branch if the issue
 persists.

 This is intended as a permanent rule, so while this currently only affects
 17.01, it will apply to future EOL branches as well when they become EOL.
 Closing such old bugs might be done automatically by a bot. If bug management
 is moved away from FlySpray (cf. question 4), the same will obviously apply
 to the new management tool.


 Question: What is your preference for handling of old bugs?

  5.1 [ ] I'm in favor of closing the bugs against unsupported and EOLed releases
  5.2 [ ] I'm in favor of keeping the bugs open, as I plan to fix them all
          myself soon :-)
  5.3 [ ] None of the above

    (If you vote 'None of the above', please try to be constructive and
     provide your opinion)



More information about the openwrt-adm mailing list