Transfer Featherpad

[SamAlex]

Hey @review-team please transfer featherpad snap name to me, allowing me to build and publish it.

1. Took the upstream approval regarding this --> https://github.com/tsujan/FeatherPad/discussions/745

2. Build recipe ready --> https://git.launchpad.net/lxqt-snaps/tree/Featherpad/snapcraft.yaml?h=main

[roadmr]

I’d like to wait until @Lin-Buo-Ren replies in https://github.com/brlin-tw/featherpad-snap/issues/11 (you opened the issue, then closed it with no explanation - maybe reopen it so it comes to the maintainer’s attention).

• Daniel

[SamAlex]

So even upstream will cant override this, i did close it because he hasnt been active since the last year ??

[Lin-Buo-Ren]

Hello, first of all, apologies for the ignorance. As the discussion is currently scattered throughout multiple places(downstream snap project issue report, upstream project issue report, Snapcraft Forum snap ownership transfer post, and the Snap Store private backstage messages), I would like to consolidate them into this Snapcraft Forum thread as it is the proper place for the matter to be discussed in the first place. I’ll also forward the same necessary portions of responses to the upstream issue report with full-quoted context as not everyone has a Snapcraft Forum account.

I, unfortunately, and regrettably, missed the communication e-mail sent by the Snap Store staff regarding the namespace transfer request assumed to be initiated by you on 5/10/2023:

…and was wondering why there’s an unknown personnel request for the snap ownership transfer with the “ASAP” in their very first direct communication:

Source: Transfer Snap To Me · Issue #11 · brlin-tw/featherpad-snap

Although I’m thrilled to have someone willing to devote their precious resources to address the burden of the Featherpad snap’s maintenance, I also, have the responsibility to ensure that the snap doesn’t fall into the wrong hands(I already have a bad reputation for “snap maintenance negligence”, I wouldn’t want to gain another one which is “snap ownership transfer negligence”, right?). As a result, I would like to request to temporarily suspend this ownership transfer process and focus on addressing the problems that cause the necessity for the snap ownership transfer in the first place.

To steer the matter in the right direction, I have implemented and devised a plan moving forward:

• I have set the snap’s visibility to “unlisted,” which means it will no longer appear in search results or store listings. However, users can still install it by directly referencing the snap’s name. This action is intended to minimize the impact of the unmaintained version of the snap. The visibility setting will be restored once the maintenance status improves.
• I hereby invite @SamAlex to directly contribute to the downstream snap project (https://github.com/brlin-tw/featherpad-snap) by following the regular GitHub development workflow of fork, pull request, review, and merge. To ensure quality assurance I would like to require the following criteria to be cleared before granting direct write access to the Git repository:
  • All necessary snap build recipe changes required to build the snap to the latest version of the upstream project must be merged into the repository. If possible, changes should be logically separated into individual commits or pull requests. In cases where logical separation is not feasible, a comprehensive enumeration of changes should be provided in the commit descriptions.
  • The snap should be buildable via the snapcraft remote-build command, at least for the AMD64 architecture.
  • A one-time maintenance notice regarding the change of project contributors must be implemented. For further details, please refer to this link. Additionally, at least 75% of the current weekly active installs should be upgraded to the revision that contains the notice.
• Once I am fully convinced that the snap is being well taken care of, I will add @SamAlex as a store contributor to the snap. This will grant equivalent access to the store backstage, enabling the management of channel releases and other relevant tasks.

If you have any questions or concerns regarding the progress we are making, please do not hesitate to ask. I wholeheartedly welcome you aboard!

Cheers ,
林博仁(Buo-ren, Lin)

[SamAlex]

I dont understand this complicated (and maybe unnecessary) process you seek, the last condition of requirement-- are you asking me to do progressive-updates ?? so much hassle even though i have sought the upstream approval.

[SamAlex]

Ok,I will try doing the required process when free but i dont find it appropriate

[Lin-Buo-Ren]

@SamAlex

I dont understand this complicated (and maybe unnecessary) process you seek

As I mentioned in the previous reply, this process is required to ensure the quality of the snap, to avoid the frustration of the ~130 current FeatherPad snap users. The Git repository write-access criteria simply request you to:

• Properly file necessary code fixes for the snap recipe against the latest FeatherPad release
• The resulting snap should be build-able by the Snapcraft build infrastructure
• Implement a necessary communication so that the users can learn that there are changes to the snap contributors(e.g. not just me)

I believe all of these criteria are reasonable and can be satisfied with little effort, if you have any questions I’m happy to help!

@SamAlex

the last condition of requirement-- are you asking me to do progressive-updates ??

No, the one-time maintenance notice is meant to inform Snap users that there will be major changes to the packaging so that they can do necessary measures to reduce the impact (like temporarily holding the package to the current version).

As with any free software projects, I cannot force you to give out any promises regarding the software maintenance, just like I never give out promises that the snap will be updated in a timely manner(which is simply not possible as I’m currently fully occupied with my other duties).

Your help, even in the short term, is highly appreciated.

[SamAlex]

Ok thanks for the explanation, so i should begin with a PR ??

[Lin-Buo-Ren]

@SamAlex

so i should begin with a PR

Yes, however, as in my previous reply, please separate the patch into individual logical changes so that it can be easily reviewed.

Note that I may also manually merge some of the fixes from your packaging recipe in the meantime, please check out the project regularly to avoid duplicate efforts, thank you.

[SamAlex]

Ok, i will do that although i dont really understand what you meant by logical-patches etc. as alll i wish to do and understand is present a single one-time snap yaml.

[Lin-Buo-Ren]

@SamAlex

i dont really understand what you meant by logical-patches

Refer to this OBS Studio snap pull request as an example, changes should at least be logically separated into individual commits, which can be done by adding the portions of the lines you wish to be ended in a commit instead of the entire file.

If multiple logic changes can’t be easily split into separate commits, simply adding them as a whole while mentioning what you’ve done in the comment messages is acceptible.

[SamAlex]

I have completely changed the yaml and built it from scratch, so i dont think i will be able to do it in parts again.

Refactor and Modernise snapcraft.yaml

If multiple logic changes can’t be easily split into separate commits, simply adding them as a whole while mentioning what you’ve done in the comment messages is acceptible.

Chose the second option.

[roadmr]

Hey folks, given that the current maintainer (@Lin-Buo-Ren) is still active, I will not transfer the snap, instead relying on the collaboration you already have to work on this.

• Daniel