"Supported modules" and github.com/silverstripe-labs

170 views
Skip to first unread message

Ingo Schommer

unread,
Apr 1, 2016, 8:24:10 PM4/1/16
to silverst...@googlegroups.com
I think we can all agree that the "labs" distinction is pretty arbitrary - we have many modules on labs which are commercially supported, and hence shouldn't really have that label. And and we have some modules on github.com/silverstripe which are de-facto unsupported. "Supported" is a pretty fluent concept, as many unmerged pull requests and open issues on these modules demonstrate.

Every module should be able to communicate its level of support through the README, and facts like the amount of stale pull requests and issues.
And every module user should be able to interpret these signs, just as you do when deciding to use any other open source project.

My suggestions:
- Move all modules from github.com/silverstripe-labs to github.com/silverstripe. Github and Packagist will auto-redirect, no change required by module consumers.
- Note if a module is commercially supported in its README
- Declare if a module follows semver in the README
- Review each module and decide if it's kept under the "silverstripe" umbrella
- Determine current user base (e.g. if a module isn't on packagist, it's unlikely to be used)
- For de-facto unmaintained modules (e.g. promospots or technorati service), contact github users who have shown interest by raising issues, pull requests, starring or forking the repo. Ask if anybody is interested in an ownership transfer. Post a list of these modules on the core mailinglist as well.
- Where ownership on unmaintained modules can't be transferred (no interest)
  - If no packagist entry exists, remove the repository
  - If a packagist entry exists, mark it as abandoned on Packagist and as unmaintained in the README

To be clear, I'm not trying to bring NPM left-pad mayhem to SilverStripe. This would affect only a handlful of ancient modules. The aim is to be clear to potential module users what they're getting, while keeping core maintainers sanity regarding the amount of stuff we feel responsible for (or can't sleep at night because we always feel like neglecting some of our responsibilities).

Ingo

Sam Minnée

unread,
Apr 3, 2016, 6:52:15 PM4/3/16
to silverst...@googlegroups.com
This makes sense to me. I think keeping modules hosted but marking them as abandoned is a pragmatic middle ground.

I wouldn't move any module from silverstripe-labs to silverstripe whose abandoned state is under review.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
Sam Minnée
CEO
SilverStripe Limited

Christopher Pitt

unread,
Apr 3, 2016, 7:12:49 PM4/3/16
to SilverStripe Core Development
This sounds like a great idea. I support it, for what that's worth...

Hamish Friedlander

unread,
Apr 3, 2016, 7:58:40 PM4/3/16
to silverst...@googlegroups.com
Seems good to me too. 

The distinction was initially supposed to be "labs is where modules come while they're still experimental - they aren't supported, don't have as high a quality standard, and APIs or even the whole thing might suddenly get replaced with something else." Somewhere where SilverStripe Ltd staff could open source code without having to spend a couple of weeks tidying it up, making it more generic, doing the todos, etc (such a barrier to entry was preventing sharing of otherwise useful code).

However nothing ever graduated from labs when it became supported, and semver + supported modules have basically replaced the concept, along with individual and group github teams.

Hamish Friedlander

Ingo Schommer

unread,
Apr 4, 2016, 4:46:40 AM4/4/16
to SilverStripe Core Development

Christopher Pitt

unread,
Apr 4, 2016, 5:15:41 AM4/4/16
to SilverStripe Core Development
Perhaps archives of full clones, so that they can be restored (with their full history) for whatever reason. github.com/silverstripe/archives?

Marcus Nyeholt

unread,
Apr 4, 2016, 10:48:13 PM4/4/16
to silverst...@googlegroups.com
Perhaps archives of full clones

Not a bad idea, it's something I'm considering to dump things into without fully consigning them to the ether. 

On Mon, Apr 4, 2016 at 7:15 PM, Christopher Pitt <cgp...@gmail.com> wrote:
Perhaps archives of full clones, so that they can be restored (with their full history) for whatever reason. github.com/silverstripe/archives?

--

Daniel Hensby

unread,
Apr 6, 2016, 7:40:12 AM4/6/16
to SilverStripe Core Development
I'd like to see the officially supported modules all sit under one Organisation and then the others somewhere else - this makes it clearer for the core team as well as end-users as to which is which (even if it's in the readme too).

I think deleting repos is a bit of a shame as they can provide value to others in the future and there's no cost to doing so if they are kept under some other organisation that's specifically for abandoned repos. Then no-ones composer installs break and someone in the future can pick them up even if they aren't interested now.

Patrick Nelson

unread,
Apr 6, 2016, 4:25:29 PM4/6/16
to silverst...@googlegroups.com
I can say in an unrelated (but recent) thread on Github (here: https://github.com/burnbright/silverstripe-importexport/pull/33) we had independently came up with the idea of the "SilverStripe League" where basically you could orphan/drop off your modules that you're no longer interested in maintaining and the organization would be composed of people who are interested in potentially helping maintain these orphaned modules in case any bugs, issues or interesting features come up. 

So with that being said, does this sound like something that could be rolled into that umbrella? An organization (i.e. "SilverStripe Labs") which has a clearly stated intent; that is, two main points:

1. Any unofficial or potentially unsupported modules with no or low standards, i.e. experimental and etc.
2. An organization with "open arms" to any orphaned modules, exposed as an avenue for people to easily find/explore if they happen to have the presence of mind to look for a place to put their modules when they are no longer able (or wiling) to maintain their module[s] (similar to the "silverstripe-importexport" module author's modules, esp that module which is reasonably popular).



Ingo Schommer

unread,
Apr 6, 2016, 4:51:44 PM4/6/16
to silverst...@googlegroups.com
Just to reiterate this, my main goal here is to clearly communicate to module users what they're getting.
And a sentence in the README does much more for this than a URL path like github.com/silverstripe vs. github.com/silverstripe-labs.
I also have some ulterior motive here: It's a pain to maintain permissions for dozens of devs across two Github organisations ;)

>  Then no-ones composer installs break and someone in the future can pick them up even if they aren't interested now.

Pretty much all of the ones I have listed above don't have a composer.json, so that's a non issue ;)
My current thinking is that we'll move all more-or-less maintained modules from silverstripe-labs to silverstripe, and rename silverstripe-labs to silverstripe-archive.
The silverstripe-archive repo would contain all modules which are no longer maintained, *and* we can't find a new owner for.
This way we don't have to delete modules, but rather mark them as unmaintained in the README. And they'll still be searchable through Google and Github.
Would that work for everyone?

idea of the "SilverStripe League" where basically you could orphan/drop off your modules that you're no longer interested in maintaining

That'd be pretty much the opposite of the PHP League, which only has high quality, well maintained modules: http://thephpleague.com/.
I've always understood the "league" concept as a collection of best practices which a diverse group of authors and maintainers commit to.
PHP itself is a much more diverse ecosystem than SilverStripe modules. We're already getting most of the value of a "league" out of 
the supported modules definition and the new addons.silverstripe.org ratings IMHO. That's not saying that a more coordinated group
of people around a set of modules is a bad idea, I just don't think it'll solve any problems around unmaintained modules per se.


Patrick Nelson

unread,
Apr 6, 2016, 5:02:39 PM4/6/16
to silverst...@googlegroups.com

On Wed, Apr 6, 2016 at 1:51 PM, Ingo Schommer <in...@silverstripe.com> wrote:
...
 
That'd be pretty much the opposite of the PHP League, which only has high quality, well maintained modules: http://thephpleague.com/.
I've always understood the "league" concept as a collection of best practices which a diverse group of authors and maintainers commit to.

... 

Right, that's just the name they organically made up in the aforementioned thread :D https://github.com/burnbright/silverstripe-importexport/pull/33

Personally I'd suggest keeping SilverStripe Labs. The point most important to me were to re-position it with a clear statement about the direction/purpose of SilverStripe Labs (e.g. in the description on the org page on github and elsewhere) on those two main points I provided, namely the experimental component and the orphaned modules component.

Christopher Pitt

unread,
Apr 6, 2016, 5:14:31 PM4/6/16
to SilverStripe Core Development
What does the name communicate though? Modules, in the SilverStripe org, are seen as owned and stewarded by SilverStripe. Does a name like SilverStripe Labs help or harm the intention to archive old modules? To me it sounds like a place where one might find new developments, not abandoned ones...

In this, I agree with Dan.

Daniel Hensby

unread,
Apr 7, 2016, 6:46:43 AM4/7/16
to SilverStripe Core Development
Renaming silverstripe-labs to silverstripe-archive makes sense and then putting all unsupported modules there.

I think that a "labs" for modules that are new/experimental/PoC still makes sense?! but maybe they would be better in a personal account?

Jonathon Menz

unread,
Apr 7, 2016, 12:41:45 PM4/7/16
to SilverStripe Core Development
I agree with Ingo, you can just explain in the ReadMe what kind of support and stability can be expected for a module. A module can quickly go from experimental to supported and archived (if a better alternative appears), you don't want to have to change the organisation each time the status of a module changes. Plus there are a lot of shades of grey in between these broad areas of classification and describing this stuff in the ReadMe allows for a more nuance and accuracy in how the status is represented. As Hamish pointed out too, SemVer and the supported module standard, along with the recent addition of module scoring probably makes the Labs distinction redundant.

I like Ingo's suggestion of putting both officially-supported and casually-supported modules under SilverStripe and only putting truly abandoned modules under SilverStripe-Archive.

As Dan said though, PoCs or code that is never intended to be used in production is probably a special case. Maybe it's worthwhile having something like Labs as a dumping ground for this kind of stuff? Or could make use of personal github accounts as he suggested.

Sam Minnée

unread,
Apr 7, 2016, 4:16:57 PM4/7/16
to SilverStripe Core Development
My preference would be to start things in personal accounts. I've started a lot of things in GitHub.com/sminnee for that reason, and then shifted it elsewhere (with appropriate "replaces" markers) once it's got more traction. even if there are a couple of people working it, you can assign a few people committers rights on a personally-hosted repo.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--

Sam Minnée

unread,
Apr 7, 2016, 4:28:09 PM4/7/16
to SilverStripe Core Development
If we rename silverstripe-labs to SilverStripe-archive, perhaps it can be used to archive unmaintained-but-installed modules of other people too? Eg I see that Will Rossiter shut down a module that Dan Hensby was using...

Christopher Pitt

unread,
Apr 7, 2016, 4:43:01 PM4/7/16
to SilverStripe Core Development
#leftpad

Anselm Christophersen

unread,
Apr 8, 2016, 3:10:09 AM4/8/16
to silverst...@googlegroups.com
I think it’s a good idea to have a place for unmaintained modules that others feel like taking over.
I’m also thinking of some of Simon W’s modules, which ended up becoming unavailable, but some have taken over.
There it’s really hard to figure out which fork to use, it would be great if such modules could have a common space.

On 07 Apr 2016, at 22:43, Christopher Pitt <cgp...@gmail.com> wrote:

#leftpad

Ingo Schommer

unread,
Apr 25, 2016, 5:14:12 AM4/25/16
to SilverStripe Core Development
I've now either marked the discussed repos as unmaintained, or in a minority of cases deleted them.
There's also a few more repos which I've marked as unmaintained. See details below.

Which means all repos *not* mentioned below will move to github.com/silverstripe instead.
This doesn't change anything on their maintenance status, we don't provide any more or less support than before on them.
It just centralises all "somehow active" repos in one Github organisation.

Separate from this, I'll also mark modules supported by SilverStripe Ltd. as such in their README,
to make the distinction to other repos on the github.com/silverstripe organisation a bit clearer.

The ownership transfer should be seamless for 99% of use cases: 
- Issues, pull requests and forks are retained
- Groups/members/permissions will be transferred over manually
- Git clones will auto-redirect (for both SSH and HTTPS)
- Packagist URLs will need to be updated manually (we'll do this right after each rename)
- composer.lock files will check out from the redirected URLs if required, and auto-update on next "composer update" run
- Composer namespaces shouldn't change, since we used silverstripe/<module-name> fairly consistently (not silverstripe-labs)

Can anybody think of other ways this ownership transfer could trip us up?

Discussed modules:
https://github.com/silverstripe-labs/silverstripe-addonbrowser/issues/3 - Deleted, it's actively confusing with the different addons.ss.org codebase
https://github.com/silverstripe-labs/zframeworktest_dbswitcher/issues/2 - Deleted, it was only a few lines of core dev relevant code
https://github.com/silverstripe-labs/silverstripe-recipes/issues/3 - Deleted, only had three recipes from a few years ago
https://github.com/silverstripe-labs/silverstripe-addons/issues/2 - Deleted, it's actively confusing with the different addons.ss.org codebase
https://github.com/silverstripe-labs/silverstripe-tinymce_jwplayer/issues/1 - Deleted, it's broken functionality (and looks like it never fully worked)

Additional modules marked as unmaintained:

Sam Minnée

unread,
Aug 18, 2016, 2:06:28 AM8/18/16
to SilverStripe Core Development
Hi everyone, an update on the silverstripe-labs vs silverstripe organisations; I've transferred the following repos from silverstripe-labs to silversripe:

Transferring modules betweens organisations re-sets the access setting, and so I needed to reapply these. For most of the modules, I looked at commit and merge activity to see who is actually looking after the module and used that to apply admin rights.

If anyone feels it would appropriate for them to have admin rights for any one of these modules, please approach one of the admins listed below (or me) and make your case :-)

silverstripe-auditor: mateusz, stojg, halkyon are admins
silverstripe-selectupload: tractorcow, chillu are admins
silverstripe-securityreport: tractorcow, chillu are admins
silverstripe-secureassets: tractorcow, halkyon, dhensby are admins
silverstripe-registry: tractorcow, chillu, halkyon are admins
silverstripe-iframe: tractorcow, chillu, dhensby are admins
silverstripe-fulltextsearch: tractorcow, chillu, halkyon, dhensby, hafriedlander are admins
silverstripe-externallinks: tractorcow, chillu, halkyon are admins
silverstripe-crontask: tractorcow, stojg are admins
silverstripe-tagfield: tractorcow, dhensby, assertchris are admins
silverstripe-dms: dhensby, tractorcow, chillu are admins

The following modules are administered by the core team:

silverstripe-frameworktest
silverstripe-reports
silverstripe-sqlite3
silverstripe-behat-extension
silverstripe-testsession

This is not a complete transfer process, but I've made a start. I was working down the list from most-recently-updated.

Once we've transferred out the modules that are still maintained, we'll rename silverstripe-labs to silverstripe-archive.

Christopher Pitt

unread,
Aug 18, 2016, 5:46:58 AM8/18/16
to SilverStripe Core Development
Brilliant!

Sam Minnée

unread,
Sep 9, 2016, 12:42:56 AM9/9/16
to SilverStripe Core Development

Daniel Hensby

unread,
Sep 9, 2016, 12:57:48 PM9/9/16
to SilverStripe Core Development
YAY!

Martine bloem

unread,
Sep 9, 2016, 4:14:09 PM9/9/16
to silverst...@googlegroups.com
Just curious - why are the Google Sitemaps no longer supported? It even used to be core and the latest commits are only two monsths old... Has Will stopped maintaining?

Martine
--

Will Rossiter

unread,
Sep 10, 2016, 1:51:02 AM9/10/16
to Martine bloem, silverst...@googlegroups.com
Google sitemaps is still supported by myself. Happy to move that to my Github if the SilverStripe organisation no longer wants to support it?

-- 
Will Rossiter
Sent with Airmail

Sam Minnée

unread,
Sep 11, 2016, 7:39:31 PM9/11/16
to silverst...@googlegroups.com, Martine bloem
That would be good, thanks Will.

Daniel Hensby

unread,
Sep 12, 2016, 9:22:54 AM9/12/16
to SilverStripe Core Development, mart...@gmail.com
Hey Will,

I'm happy to help provide support to that sitemaps :)

Dan
Reply all
Reply to author
Forward
0 new messages