Bug tracking has moved to GitHub

Release and security announcements
1

On February 9th 2022 at 12:00am CET was bug tracking replaced with https://github.com/openwrt/openwrt/issues.

Due to this decision it’s not possible to login to this system anymore. Old bugs might be migrated to the GitHub issues, but it might take some time. Until then feel free to create new issue at the GitHub issues. We’re sorry for any inconvenience this might cause.

EDIT: fixed GitHub link, copy pasta fail, thanks @hnyman

23 Likes
2

I think it may have confirmed-dev only issue that non-login user can't see like exploitable security issue: did they migrated manually?

3

I think it may have confirmed-dev only issue that non-login user can't see like exploitable security issue: did they migrated manually?

1 Like
4

Request for clarity about submitting bug reports.

I am about to submit a bug report that i believe should be fixed on openwrt.

However, this bug likely affects ath10k (core) and ath10k-ct (a package?).

Where is the appropriate place for bug reports that might affect multiple core components and/or packages?

ty

EDIT0 My proposed "answer" to this is submit the bug report in one place that its applicable to and let you all sort out the rest.

EDIT1 But it might help users to have only place to search for issues and since the dev's will have to delegate out bug reports anyway, why not keep all bug reports in once place?

5

Do you know that GitHub is owned by Microsoft and GitHub is closed source software? Did you consider that in discussion?

But the advantage is more bug reports, everybody has a GitHub account.

2 Likes
6

Have you read the discussion from the developer mailing list?

4 Likes
7

wrong user? :slight_smile: but to answer your question, yes i did read it. I'll look again in case i missed something. My comment is related to the wiki which suggests multiple issue trackers. This scenario is not unknown to large complex github projects.

8

Is that a bug in the OpenWrt code? --> OpenWrt bug tracker in Github

or a mainline ath10k bug? ---> also Linux, kernel.org bug reporting?
or a ath10k-ct bug? --> also greearb's -ct Github site.

We use lots of upstream packages, and bugs in the upstream packages should preferably be also reported upstream so that the bugs can be fixed at upstream.

3 Likes
9

Yeah, sorry,
writing two answers at the same time :frowning:

2 Likes
10

it's just a bug tracker, if Microsoft decides to go haywire it's easy to just move to something else.

The code on github is just a mirror, the main repo is still on a dedicated git server

4 Likes
11

I think among the tech giants, such as Google and Facebook, Microsoft can be considered a good guy. After all, their main revenue stream isn't user data.

2 Likes
12

Microsoft can be considered a good guy

:joy: :sweat_smile: :grin: :sweat_smile: :smile:

Please reboot and think again about it

3 Likes
13

Only for legacy reasons. At the moment they are pushing towards that goal with all their might. Buying Github is part of that effort.

As a general rule, corporations are never "a good guy". It's still an entity whose only goal is make profit.

4 Likes
14

I read the discussion and the votes, and i found some strong opinions for and against Github and some strong oppinions against Gitlab and they were all really interesting, but through reading the discussion it became not clear to me, why codeberg.org (GiTea) and todo.sr.ht (Sourcehut) were ruled out.

In the meeting notes from 20220118 they are listed as alternatives https://openwrt.org/meetings/20220118, but the discussion during the vote never went into that direction, only a single participant mentioned it briefly. Were they ruled out at the meeting, or am i jumping to conclusions here? I wonder if there is something they could do better than github / gitlab ...

15

One more good thing about Github is that it can be used by people who have to use a screen reader.

16

@ThiloteE Thanks for reading through the meeting notes! Sourcehut offers a very different workflow than other Git interfaces. Enforcing email usage to contribute did not seem suitable, especially since all community repositories work with GitHub PRs only. Codeberg/GiTea seemed a good candidate to become a new home of all OpenWrt projects, however we found at least three obstacles stopping us at this point:

  • They don't offer any pre-commit hooks on their server, which is fine but currently a requirement to ensure that every commit is signed off by the developer.
  • The Merge Requests requires isn't as convenient as the one on GitHub. We may look into supporting GiTea to improve that. However at this point this was an explicit complain of reviewers not to switch to GiTea
  • The CI is still in a closed testing stadium.

Me and @stintel (and hopefully some more users) will continue to evaluate Codeberg/GiTea and may eventually move everything. For now GitHub seem to be an okay compromise looking at usability and low-maintenance

3 Likes
17

Thank you very much, this answered my questions and stilled my curiosity :smile: Seems like a plan :slight_smile:

18

My not. Actually I would like to know what the problem is with gitlab.

19

Ah, yes sorry, there also have been people voicing their opinions in favor of Gitlab.

Here is somebody who brought some arguments against it: some arguments against Gitlab, but keep in mind, this was just one post and roughly 20-30 people cast their vote.

Here you will find the whole discussion. I personally found it easier to get an overview by filtering by thread or date as compared to subject or author

20

Nobody wanted to host (and maintain) it since it's complex to do, additionally some developers found the web interface to be overloaded and slow. Our goal is to lower the number of services we maintain to focus on developing OpenWrt.

3 Likes