Hey @review-team please transfer featherpad snap name to me, allowing me to build and publish it.
Took the upstream approval regarding this --> https://github.com/tsujan/FeatherPad/discussions/745
Build recipe ready --> https://git.launchpad.net/lxqt-snaps/tree/Featherpad/snapcraft.yaml?h=main
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).
So even upstream will cant override this, i did close it because he hasnt been active since the last year ??
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:
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:
snapcraft remote-build command, at least for the AMD64 architecture.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)
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.
Ok,I will try doing the required process when free but i dont find it appropriate
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:
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!
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.
Ok thanks for the explanation, 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.
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.
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.
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.
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.
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.