I am looking for a maintainer to take over the QXmlEdit snap project frederickjh/qxmledit that is making the snap of QXmlEdit.
I plan to literally move halfway around the world this year. In this new location my connection to the internet may not be the best. I will not have time to dedicate to this project. Instead of letting it fall into disrepair or get security holes I am looking for a maintainer to take over the project before I close it down.
Currently, I mostly just do the the builds for security updates in packages included in this snap. After the initial coding of the snap we have had two issues. On both the maintainer of the QXmlEdit project (@lbellonda on GitHub) helped find solutions.
We are now approaching 1900 users of the snap of QXmlEdit and approaching three years of being in the SnapStore.
If a new maintainer does not step up by the end of March 2021 I will remove the QXmlEdit snap from the snap store and archive the project on GitHub.
Anyone interested in taking over maintaining the snap should respond to the open issue regarding this on the Github project for the QXmlEdit snap.
We are now half-way through March. So far no one has express an interest in taking over the QXmlEdit snap. Currently it needs less than 100 more users to reach the 2000 users mark.
I will not post until the end of the month when I will disable it in the Snap Store, unless someone steps forward to take over its maintenance.
So, we have past the end of March and are now well into April. I am going to give this one week more before shutting the QXmlEdit snap down.
I have had one person come forward saying that they are interested in being the maintainer, but then they also said this:
I do not rebuild snaps due to security notices though, as I believe the security should be guaranteed by snapd’s own confinement, and that most users should automatically have their snap upgraded to the latest published revision as long as the upstream releases frequently.
I would appreciate any feed back about this “practice” of not rebuilding Snaps for included package security updates. Currently the release cycle for the upstream QXmlEdit is about two times per year. Somehow I don’t think this is a good practice considering all the emails that Canonical sends to my inbox for one snap in a years time. If it is a good practice why bother sending the emails.
Thanks in advance for your feedback on this issue!
Frederick
Rebuilding due to security issues is a good practice. Confinement help mitigate problems, but it is not meant to be the ultimate infallible software protection - my opinion, at least.
Thanks @ivo.cavalcante! That is what I thought I would hear back. I had an uncomfortable feeling leaving the almost 2000 users of the QXmlEdit snap with a maintainer than seems to be more interested in numbers (+90 search results in their github account for “snap”) but they cannot be bothered to update snaps for security updates. This person also put forth the idea of creating a dumping ground for abandoned snaps.
At this point I plant to mark the snap as private, remove the snaps from all channels and update the description in case there is ever a name dispute and I cannot be reached. I will also archive the snaps github repository.
If anyone is reading this after the fact and wants to take over the QXmlEdit snap and plans to do security updates, contact me via Github.
What is actually required to do this ? I care about security and if the process isn’t too challenging I am not opposed to doing this for popular packages, not just qmledit.
Congratulations for the care you’re showing on this subject. I’ve been following this thread, hoping for someone to take ownership of the package - I maintain some Snaps myself, but only packages that I personally use (kinda makes sense, I’m my main tester ) . It’s not the case with QXmlEdit, unfortunately…
For me, the motivation of snapping an application is mostly the lack of them in the Ubuntu archive, or the ones in it are buggy, too old, or simply that I’m too lazy to build them from source twice. It just happens to be that many of them that meets the criteria .
That’s great! The proper way to do so is to request the publisher to add you as the snap’s collaborator so that you have access to the snap’s store backstage (mostly for triggering builds whenever it is needed). The snap recipe hosting repository’s write access is also needed to switch the source-tag property if you maintain multiple risk tracks (stable/candidate/beta/edge).
As for switching source-tag and re-commit them just for rebuilding a snap’s is just too costly for the maintainer (IMO), I made a proposal to let the publisher to override/set the source-tag property of the main Snapcraft part when they needed when triggering the build: Proposal: Allow overriding the source-tag property for an one-time build in the build infrastructure , which should be helpful when you want to publish both the release and development snapshot snaps but can’t bother to commit twice just for receiving a single “snap_name contains outdated Ubuntu packages” mail.
) . It’s not the case with QXmlEdit, unfortunately…
.