A dumping ground for all non-snapcrafters-adopted snaps?

While acknowledging the Snapcrafters organization’s adoption criteria[1][2] for snaps, I’m wondering if there are any benefits if we do have one that accepts everything(well not exactly everything, but with a lower criteria like completing most of the tasks in the Snapcrafters Template).

As far as I can see there are a few benefits:

  • Multiple people can take care of the adopted snaps, which is marginally better than an unmaintained snap which only a single person has the control
  • Multiple people can deal with the problem if certain snap’s upstream has a problem with certain snap’s presentation without escalating it to the snap store
  • We can also enforce some kind of quality assurance to the snaps, including but not limited to proper store metadata, upstream update checker, proper interface detection, and automatic building and publishing
  • Last but not least, we do have a final dumping ground if the initial packager really have no interest in maintaining their snap in long-term basis(which is sad, but still possible)

What do you think?

/cc @popey @advocacy


[1]

[2]


1 Like

Goal

A decentralized, centralized place for interested snap packagers to host and maintain their snaps, together, with lower adopting criteria for completing most of the tasks in the Snapcrafters Template

Adoption criteria

  • Completing most of the tasks in the Snapcrafters Template, however, the following are the must:
    • An attempt to contribute the snap to the upstream
    • An attempt to transfer the snap to the Snapcrafters
    • A call for testing topic and a release announcement topic in the snapcraft forum
  • The snap must be at least launch-able and all known issues filed in its issue tracker
  • The snap must not infringing any law, including but not limited to copyright, etc.

Who has the repo write access?

All individuals that have their snaps adopted by this organization will gain write access to the corresponding snaps’ repository.

They will also be invited to optionally join the organization, which will gain write access to all snaps owned by the organization.

The implementation

  • A new GitHub organization to-be-created, probably named:
    • “Not Snapcrafters” (in the sense of the Not Canonical launchpad team, but only if the @snapcrafters guys are fine with it)
    • Snap Dump (I’m not really good at naming, so that’s all I got)
    • Any ideas?
  • A process of transferring snaps from individuals to this to-be-created GitHub organization(Not sure the acceptance from the @store guys though :-/)

There is a lot of common sense in joint work on snaps, like some Debian teams maintain packages. First idea it to change GitHub vendor lock-in to open source platform. Second is to have maintainers guidelines and monitoring who does what across the tree with no ability to erase history to reduce risk of data loss if some accounts are hijacked.

1 Like

An announcement has being made: