alist: reintroduce package#29459
Conversation
|
Are the reasons for removal addressed? New contributors are expected to use a real name and not an alias as per the contributing guidelines. |
5ea3c3b to
5273c1a
Compare
|
|
Seems to me that the package description itself should reference the reason that the |
I understand the concern, and I agree that the previous change was related to trust and governance concerns around the upstream project at that time. However, I would prefer not to describe AList itself in the package description as having “telemetry issues,” unless there is a concrete and current reference to a specific release, issue, commit, or code path. A general warning may unintentionally damage the reputation of the project, especially now that AList and OpenList are maintained separately and the auth/API component has been open-sourced as AlistGo/auth. I think it is better to keep the package description neutral and focused on what the package does. If there are still specific privacy or telemetry concerns, I am happy to address them separately with factual references. |
|
I would like to add one more clarification regarding the “telemetry” concern. As far as I understand, AList itself did not have telemetry code merged into the main tree. Even the previous removal PR stated that the AList code up to v3.45.0 had been reviewed as “clean”, and that the attempted runtime-information collection code was not merged: The main concern mentioned there was the private API used for connecting to some cloud drives. My understanding is that this was not general telemetry in the AList package itself, but an API/token helper required by some storage providers where developer credentials or OAuth/token exchange are needed. AList currently provides such token tools here: The related auth/API implementation has also been open-sourced: OpenList has a similar token/API helper as well: The OpenList API pages are described as a token generator / API pages for obtaining cloud-drive API access for OpenList, and they also support using OpenList-provided parameters. So if the package description for AList needs to include a warning about this kind of token/auth API helper, I think the same standard should also apply to OpenList. Otherwise it would be unfair to describe only AList in that way, especially when both projects now have open-sourced their corresponding API/token helper implementations. I do not want to hide any real privacy or security concern. If there is a concrete, current telemetry/privacy issue in a specific AList release, I am happy to address it with a factual reference to the relevant upstream issue, commit, or code path. But without such a current reference, I think adding a general “telemetry issues” warning only to the AList package description would be misleading and may unfairly damage the reputation of the project. |
|
|
@SheltonZhu Thanks for raising this in detail. I agree that privacy and trust concerns are especially important for OpenWrt users, because this type of package may run continuously on routers or NAS devices and may handle local files or cloud-drive credentials. However, I think we need to separate three different things here:
AlistGo/alist#9142 is clearly relevant background, and it does mention possible hardware information collection for the community edition. But from what I can see, that is a planning/discussion issue, not by itself evidence that the current OpenWrt package contains telemetry code or sends hardware information by default. I do not object to documenting the history or adding a neutral note for users. What I object to is putting a strong “privacy risk warning” in the package description unless it is tied to a concrete current code path, commit, release, or default runtime behavior in the packaged version. For example, I would be open to adding neutral wording such as: “Users should be aware that the upstream AList project has had prior privacy/trust discussions, including discussion of possible hardware information collection. Please review upstream privacy and security discussions before deploying in sensitive environments.” That would inform users without making an unsupported claim that the current package itself contains active telemetry. If there is current telemetry or hardware-information collection code in the release packaged by this PR, please point me to the specific commit, source file, or runtime behavior. I will either patch it, disable it, or add a stronger warning based on that factual reference. |
|
Thanks for the clarification. I agree that planning/discussion documents are different from proven active telemetry code in a specific release. My concern is broader than only “does the current binary send telemetry by default”. For OpenWrt users, especially router/NAS users, trust and governance posture are themselves highly relevant risk factors. I appreciate that you are open to adding neutral wording. Personally, I think that is the minimum necessary compromise here. What I want to avoid is a situation where inclusion in official OpenWrt feeds is interpreted by users as a full implicit trust endorsement, while the project has:
A neutral but explicit note in the package description would allow users to make informed decisions without asserting unsupported claims about the current release. Given that packages in the official OpenWrt feeds carry an implicit level of downstream trust, I think OpenWrt should require this disclosure before accepting the package. |
|
@SheltonZhu Thanks for the clarification. I understand that your concern is broader than whether the currently packaged release sends telemetry by default. It also includes the broader trust, governance, moderation, and transparency context around deploying this kind of software on routers, NAS devices, and other sensitive environments. I have added a user-facing disclosure to the package description to make these concerns visible before inclusion. The added text asks users to review upstream privacy, security, and governance discussions, including prior discussion of possible hardware information collection, centralized governance or moderation concerns, and ongoing transparency debates. It also clarifies that inclusion in the OpenWrt package feeds should not be interpreted as a full endorsement of the upstream project's trust or governance posture. At the same time, the wording intentionally avoids asserting that the currently packaged AList release contains active telemetry or performs hardware-information collection by default, since no specific current code path, commit, source file, or runtime behavior has been identified in this PR. I hope this addresses the disclosure concern while keeping the package description factual and fair to the current packaged release. |
|
That sounds good to me. Probably should all be squashed into a single commit. |
0752986 to
fa0d7b6
Compare
|
You still need a commit message with an explanation of why this is being reintroduced. |
fa0d7b6 to
954f624
Compare
|
@GeorgeSapkin Thanks, that makes sense. I’ll amend the squashed commit message to include the rationale for reintroducing AList as an independent package, including that AList and OpenList are now separately maintained |
|
So, any users that are still interested in your project, they can just download the binaries from there, easily. NAK by me. |
@1715173329 Thanks for the feedback. Could you clarify the reason for the NAK? I do not think this PR should be treated as merely providing another binary download location. The purpose of adding a package to the OpenWrt feeds is to build it from source within the OpenWrt build system, Upstream binaries do not provide the same integration, reproducibility, target-specific builds, or package lifecycle handling as an OpenWrt package. If the objection is not about packaging or build integration, but about upstream trust/privacy/governance concerns, please clarify what specific issue should block inclusion of the current packaged release. |
|
@1715173329 Also, if the objection is that users can download upstream binaries directly, I do not think that is a sufficient reason to NAK an OpenWrt package. Many packages in the OpenWrt feeds, including OpenList, also have upstream release binaries that users could download manually. They are still packaged because OpenWrt packages provide source-based builds, So I think the blocking reason needs to be something more specific than the availability of upstream binaries. |
|
Hi maintainers, Could someone please help clarify the current status of this PR and the remaining blockers? So far I have addressed the earlier review points by:
There is currently a NAK label, but I am still not sure whether the objection is:
I would appreciate guidance from any maintainer on the expected path forward. If there are concrete technical or policy requirements that this PR can address, I am happy to make the necessary changes. If the decision is that this package will not be accepted, it would also be helpful to have that stated clearly so I can avoid repeatedly pinging individual maintainers. |
AList was previously removed from the packages feed after OpenList was introduced as a replacement. Since then, AList and OpenList have continued as separately maintained upstream projects and should no longer be treated as direct substitutes. Reintroduce AList as an independent package for users who explicitly want to deploy the AList upstream project. The package description also includes a neutral note asking users to review upstream privacy, security, and governance discussions before deploying it in sensitive environments such as routers or NAS devices. Signed-off-by: YUXIAO FAN <CN_QianShi@hotmail.com>
954f624 to
3253c0c
Compare
|
@GeorgeSapkin @efahl @1715173329 Can this issue be further addressed? |
|
Sorry no. I don't have plan to merge this at least. |
Please provide sufficient reasons. |
@1715173329 With respect, I don't think "users can just download the upstream binaries" is a sufficient basis for a NAK, because that reasoning applies to a large portion of the feed rather than to this package specifically. Almost every project in this repository also ships prebuilt binaries upstream — including OpenList, which was accepted here despite having its own upstream releases that users could download manually. If "upstream binaries are available" were a valid reason to reject a package, the same logic would justify removing a great many existing packages. Since that standard clearly isn't applied to the rest of the feed, applying it only to AList isn't consistent. The reason packages exist in the OpenWrt feeds is precisely that they provide what a raw upstream binary does not:
A manually downloaded binary offers none of this, and on routers/NAS devices the integration and reproducibility are arguably more important than on a typical desktop. So I'd ask: is the objection actually about packaging or build integration? If so, I'm happy to address concrete issues. If the concern is upstream trust/privacy/governance, that's a separate discussion — and one I've already tried to address with the neutral disclosure note in the package description. Either way, "the binaries are downloadable elsewhere" doesn't seem like a package-specific blocking reason. If the real position is a project-policy decision that AList won't be accepted regardless of packaging quality, I'd appreciate that being stated directly, so the same standard can be understood and applied consistently to comparable packages (e.g. OpenList). I'd also like to note, respectfully, that a one-line NAK without a stated, addressable reason is hard to reconcile with how review is normally expected to work here. By convention a NAK is accompanied by a concrete objection the contributor can act on, and the whole point of doing this in the open is that decisions are reasoned, transparent, and consistently applied — not least so that other contributors can understand the standard being used. Compare this with how OpenList was reviewed and accepted: I'm asking for the same kind of substantive, on-the-record reasoning here.
Any of these I can work with. "The binaries are downloadable elsewhere" — repeated without engaging the points above — isn't an answer I can act on, and quietly leaving the PR in NAK without one doesn't seem in keeping with the open, reasoned review process. I'd appreciate a direct response. Thank you. |
|
I'd like to add a point that hasn't come up yet, rather than restate what's already above. OpenWrt's CONTRIBUTING.md defines what makes a package acceptable, and it also defines what doesn't belong in that judgment. The documented criteria are objective and package-scoped: maintained upstream version, in-feed dependencies, successful compile/run testing, proper commit hygiene. Nowhere does it grant a single reviewer standing to reject a package on a criterion that appears in none of those guidelines. That matters here because a NAK isn't a personal veto — in this project it's a signal that a documented standard hasn't been met, which is why it's expected to name the standard. A NAK that points to no guideline isn't something a contributor can act on, and it isn't something other maintainers can evaluate either. It just freezes the PR. So my question is narrow and procedural: under which part of the contributing guidelines does this objection fall? If it maps to a written criterion, I'll address it. If it doesn't, then by the project's own rules it isn't a basis for blocking, and the PR should be open to review by other maintainers on the documented merits. |
|
As an observer:
The package was removed because of trust issues.
The fact that this PR only addressed that part only after it was brought makes this even more suspicious.
The walls of text to keep pushing this over and over again does not only not restore the trust, it instead makes the ones pushing this suspicious on top.
From that perspective Tianling's NAK is the right thing to do.
|
Fair perspective, and I'll keep this short. |
To put it more directly: a reasonable explanation could be given in a single line. Everyone's time is valuable and I don't expect anyone to write essays — but if there were a concrete, defensible reason, stating it would cost less effort than the silence has. Prolonged non-response to a direct, narrow question reads less like being busy and more like avoidance. I'd genuinely rather have a clear "no, because X" than an open-ended block — either lets me move on. |
no no no, it's just a waste of time imho. i cannot see any benefit of using alist instead of the community-driven openlist project, nothing makes alist special. |
OpenList is already in the feeds, and AList and OpenList are now separately maintained projects with different user bases and non-overlapping features — one is not a substitute for the other. So the core question (also raised by @skysliences) is: what standard makes OpenList acceptable but AList not? I've already disclosed the upstream privacy/governance history in the package description, and the packaged release is fully open source and auditable. If there's a specific code path, commit, or default behavior that blocks this, point me to it and I'll fix it. If the decision is simply "won't be merged regardless of changes," that's your call as a maintainer — I'd just ask that it be stated plainly, so I'm not pinging people over something that was never going to be accepted. |
Yes, this won't be merged. |
7 participants
AList was previously available in OpenWrt packages and was later replaced by
OpenList. However, AList is still actively maintained upstream.
AList and OpenList are now separately maintained projects. They have different
feature sets, release lines, and upstream maintainers. Therefore OpenList
should not be treated as a direct replacement for AList.
This PR restores AList as an independent package in OpenWrt packages.
I am the current maintainer of AList and am willing to help maintain this
package.
Tested: