Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merging the openwrt-routing/packages with openwrt/packages? #184

Open
jow- opened this issue May 4, 2016 · 35 comments
Open

Merging the openwrt-routing/packages with openwrt/packages? #184

jow- opened this issue May 4, 2016 · 35 comments

Comments

@jow-
Copy link
Contributor

jow- commented May 4, 2016

Hi @openwrt-routing/owners

for a long time both the openwrt-routing and openwrt packages organizations are working in parallel and in many cases are maintained by the same persons.

For the sake of simplicity I'd like to suggest to merge both organizations and move the packages from here into openwrt/packages.

This issue is just for starting a discussion and maybe reaching a consensus, so please voice your opinion here.

@ffainelli
Copy link
Member

Seems reasonable to me to merge this within openwrt/packages. AFAIR this project started earlier than when we decided to move the packages maintenance to Github, so no objection from me.

@zioproto
Copy link
Contributor

zioproto commented May 4, 2016

Hello @jow-
sounds good to me to merge organizations. Less overhead is always better.
openwrt-routing was kind of a small group, where everyone knows each other because of the many OpenWrt and Battlemesh events.
If the group of committers gets wider in the new organization we should find a way to resolve the situation where there is a patch that needs further improvement before it gets accepted.

I have a proposal, can we set up the repositories in a way that is never possible to push directly but it is always necessary a pull request ? In this way we know that each change had at least 1 other person reviewing it.

@lynxis
Copy link
Member

lynxis commented Jun 2, 2016

@zioproto you can protect branches and enable require status checks. it's not the same, but nearby.

@ghost
Copy link

ghost commented Jun 2, 2016

No objections from my side

@mwarning
Copy link
Contributor

mwarning commented Jun 2, 2016

sure, go ahead

@bittorf
Copy link
Contributor

bittorf commented Jun 10, 2016

i'am against it. it's easier for me to follow in this special field and i dont want to read all the messages from packages.

@axn
Copy link
Contributor

axn commented Jun 10, 2016

I see the point and for me both strategies are fine.

Could it mean less flexibility when interested in bleeding-edge routing
packages from trunk but stable openwrt packages? Now one could easily
choose different branches for each repo. But that's probably not so
relevant.

/axel

On 04.05.2016 19:21, Jo-Philipp Wich wrote:

Hi @openwrt-routing/owners
https://github.com/orgs/openwrt-routing/teams/owners

for a long time both the openwrt-routing and openwrt packages
organizations are working in parallel and in many cases are maintained
by the same persons.

For the sake of simplicity I'd like to suggest to merge both
organizations and move the packages from here into openwrt/packages.

This issue is just for starting a discussion and maybe reaching a
consensus, so please voice your opinion here.


You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub
#184

@elektra42
Copy link
Contributor

Hi –

I see the point and for me both strategies are fine.

Could it mean less flexibility when interested in bleeding-edge routing
packages from trunk but stable openwrt packages? Now one could easily
choose different branches for each repo. But that's probably not so
relevant.

+1

Cheers,
Elektra

Viral meme of radical freedom

The fact that you talk in your head doesn't mean that you think.

The best way to lose control over yourself is trying to control yourself.

Most people experience themselves as a voice in their head, telling them
who they are, what they think and what they have to do.

http://en.wikipedia.org/wiki/Meme

@aparcar
Copy link
Member

aparcar commented Sep 4, 2017

any progress on that?

@diizzyy
Copy link
Contributor

diizzyy commented Sep 4, 2017

So far (using members listed by github):

+1 jow, zioproto, mwarning, axn, elektra42, ffainelli
-1 bittorf

Give it a 2w timeout for the above to reply, no answer is counted as no opinion/blank. Seems reasonable and fair?

Missing:
@p4u @lindnermarek @lgierth @altergui @acinonyx
Any objections with merging?

@aparcar
Copy link
Member

aparcar commented Sep 4, 2017

@dangowrt @lynxis opinions?

@lindnermarek
Copy link
Contributor

Hi @jow- et al,

I am in the boat with @zioproto - as long as maintainers can require patch peer-reviews for specific packages I am fine with merging. We already had the case where a well-intended batman-adv patch pushed by a non-maintainer broke our package while we maintainers were unaware of said change until people complained about the broken package.

The protected branches mentioned by @lynxis does not sound like a solution to this problem. All packages live in subdirectories and not branches. Anybody else with a suggestion ?

@diizzyy: Not sure why @zioproto is counted as 'yes' since the problem he raised remains unsolved.

Cheers!

@diizzyy
Copy link
Contributor

diizzyy commented Sep 8, 2017

@lindermarek: I think it's going to be hard to implement this as some packages are very use-case specific but I do agree there should be a pull request with some timeout for reviewing however for major changes. I don't see a need for minor changes however.

@lindnermarek
Copy link
Contributor

@diizzyy: That differentiation is very fuzzy. What constitutes a major changes / a minor change ?

In our case, the change was considered minor and broke the package nonetheless ..

@diizzyy
Copy link
Contributor

diizzyy commented Sep 8, 2017

@lindnermarek
Major: Major version jumps, additional patches that are intrusive etc?
Minor: Minor version jumps, configuration changes (that doesn't affect availability) functionality such as adding threading support. I would consider lets say removal of unicode for instance a major change.

That said, we should always require a run-time test. I don't think there's a simple fix for this, reasonable would be that maintainer(s) should be able to commit directly while "external" pull requests should be reviewed within a reasonable time otherwise a commit should be allowed to step in and commit if requirements are fulfilled and it wont affect other packages

@BKPepe
Copy link
Member

BKPepe commented Jun 27, 2019

Recently the package smcroute was moved from this repo to openwrt/packages.
See @lynxis's openwrt/packages#8855 (comment)

The advantages what I can see are that openwrt/packages has CircleCI, so the packages are compile tested against ath79 target and it has DCO check (Signed-off-by commits). It's not a big deal to have it here as well. Let's look, for example, at #215 and we can think why the pull request wasn't tightened to the end.

However, I think in openwrt/packages there's a lot of activity. This situation can be improved here if there will be more people with commit access or more people, who will maintain this repo.

@mwarning
Copy link
Contributor

Still, It would be nice to have a repository that has relaxed rules (e.g. for less polished packages).

@diizzyy
Copy link
Contributor

diizzyy commented Jun 27, 2019

I presume the goal is to have as little breakage as possible so another other option would be to detach the routing repo if people don't feel they want to raise the bar slightly.

@mwarning
Copy link
Contributor

@diizzyy as the vote is already in favor of merging. How about doing that, and create another repository in the long run. But this decision is not part of this ticket.

aparcar added a commit to aparcar/packages that referenced this issue Jul 5, 2019
Following the discussion at openwrt-routing/packages there is a majority
in favor to merge the two repositories[0]. The reasonable doubt of
@bittorf[1] (notification bloat) is solvable by using a CODEOWNERS[2]
file, allowing individual notifications on specific folders.

This eventually unifies things belonging together, adds more eyes to the
routing packages, introduces automatic pull requests testing and even
removes a line from feeds.conf!

[0]: openwrt/routing#184 (comment)
[1]: openwrt/routing#184 (comment)
[2]: https://help.github.com/en/articles/about-code-owners

Signed-off-by: Paul Spooren <mail@aparcar.org>
@aparcar
Copy link
Member

aparcar commented Jul 5, 2019

I created a pull requests, basically moving all this to openwrt/packages/net, see here openwrt/packages#9399

We could start using a codeowners file to define responsibilities per package.

@BKPepe
Copy link
Member

BKPepe commented Jul 5, 2019

We could start using a codeowners file to define responsibilities per package.

openwrt/packages#7125

It will work just for people, which has commit access.

@aparcar
Copy link
Member

aparcar commented Jul 5, 2019

I don't see a problem giving the maintainers of routing access to packages, or would that be a problem?

@adschm
Copy link
Member

adschm commented Jul 5, 2019

@aparcar But it won't be available to non-maintainers, so those who were watching the whole openwrt-routing would now have to watch the whole openwrt/packages?

@mwarning
Copy link
Contributor

mwarning commented Jul 5, 2019

@adrianschmutzler those would likely only watch their own packages.

@adschm
Copy link
Member

adschm commented Nov 4, 2019

Hi, it looks like this is stuck again.
Based on the discussion in packages repository, the majority (out of very few people) favored moving packages without history. Despite, there was a preference (especially from the people at openwrt/packages) to not just merge packages, but put some work into them to meet the merge criteria for openwrt/packages:
openwrt/packages#9399 (comment)

Unfortunately, almost nothing has happened since then. There have been two attempts:
openwrt/packages#9406
openwrt/packages#9408

The latter (from me) was meant as a proof-of-concept for merging with history, which has been rejected as stated earlier. Since I'm not a package maintainer, and my contribution was limited to the history stuff, I will close that one again.

Nevertheless, the terms should be clear now:
If openwrt-routing is supposed to be merged into openwrt/packages, there has to be a PR for every package to be added, and there would be some work to update Makefiles and other stuff.
I'd thus want to encourage package maintainers or other volunteers to start with that (we do not have to transfer everything at once, it would be okay to start with 5 packages) or decide to re-vote and cancel the merge.

@zorun
Copy link
Contributor

zorun commented Jul 30, 2020

It would be good to reach a decision (one way or the other) before the next 20.XX release.

If I sum up the discussion so far:

General proposal

Move all packages from openwrt-routing/packages into openwrt/packages

Arguments in favour

  • less overhead, unified organization
  • improve package quality thanks to Continuous Integration which is set up in openwrt/packages

Arguments against

  • there is a lot of activity in openwrt/packages, it will be hard to follow what happens to specific routing packages
  • more people will be able to merge changes without the approval from maintainer/upstream. This has already been a problem in openwrt-routing (quoting @lindnermarek "a well-intended batman-adv patch pushed by a non-maintainer broke our package while we maintainers were unaware of said change until people complained about the broken package"). It is expected to be a bigger problem in openwrt/packages
  • less flexibility (e.g. we lose the possibility to use trunk routing packages on stable openwrt release), although I'm not sure it is actually possible currently.

Remaining questions

How to ensure that openwrt-routing maintainers are kept in the loop

This touches both on following activity and ensuring proper patch review.

Codeowners files can be used, they work with both Github and Gitlab.

Maintainers receive a special notification about their packages, and pull requests can be configured to require the approval of the maintainer.

It seems it needs all maintainers to have commit rights.

Commit rights

Should all current members of openwrt-routing obtain commit rights on openwrt/packages?

How to import packages

The current approach is to move packages individually, improving them in the process. Pro: it improves package quality and consistency. Cons: it takes time and efforts. This approach is preferred by openwrt/packages people, see openwrt/packages#9399

The alternative is to bulk-import all packages as they are currently in openwrt-routing.

Another issue is whether to keep the history of commits: the current approach is to discard history, see openwrt/packages#9408

@zorun
Copy link
Contributor

zorun commented Jul 30, 2020

From my end, I also think that the activity on openwrt/packages is really too high to follow. I am subscribed to email notifications for it but I can't keep up with everything.

The advantage of openwrt-routing is that it's a small group of people that (mostly) know each other, so it's easier to work together and trust each other.

If there is a process to make sure that maintainers are made aware of changes and can review patches, then I'm ok with the merge. Otherwise I think it should stay separate, unless there are stronger arguments in favour of the merge.

@zorun
Copy link
Contributor

zorun commented Jul 30, 2020

Based on feedback from IRC, I have updated the summary (about codeowners files, and importing packages individually)

@mwarning
Copy link
Contributor

mwarning commented Aug 1, 2020

  • I do not have a opinion on this
  • it would be nice to have a generic repo in feed.conf.default (commented) that is less professional, thus lowering the bar for participation, but also not being shut out

@adschm
Copy link
Member

adschm commented Aug 11, 2020

Looks to me like this will stay separate. Maybe just get CI running and be happy?

@aparcar
Copy link
Member

aparcar commented Aug 11, 2020

There is still some discussion at openwrt/packages#12977 to fix the notification issue. Please don't close this just yet.

@PolynomialDivision
Copy link
Member

Can we maybe just adopt the .github as workaround? It checks for many targets, so u will notice for example build errors on targets that build with glibc.

@aparcar
Copy link
Member

aparcar commented Mar 10, 2021

Hi, it's been some time and I'd like to move this at least over to the openwrt organization so all core members have access. GitHub allows to transfer ownership and renames with automatic forwarding, buildbots internally use the mirror on git.openwrt.org anyway.

After the move I'd make sure that a group called routing-maintainers has commit access to the repository and I add all current commiters of openwrt-routing/packages to this group.

Any objections?

@lindnermarek
Copy link
Contributor

What are all the things which need updating / changing in order to not break after this transition ? URLs, notifications, git repositories, permissions, etc ? A comprehensive list would be appreciated to allow us to catch most of the issues beforehand.

@aparcar
Copy link
Member

aparcar commented Apr 8, 2021

GitHub automagically redirects requests meaning we don't have to update anything during the migration, pulling from the old URL will still work. From my understanding the migration also transfers stars and notification settings.

Long term the mirror script at git.openwrt.org should be updated.

Apart from that the openwrt.git/README.md needs an update, but that's minor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests