Panopoly is a great distribution! I've got a couple distributions based on it and its awesome to see other major distributions pick it up as well, like Open Atrium and Open Academy.

However, now that so many people are depending on it, the rate of development and how quickly patches are reviewed and integrated is starting to become more and more of a hinderance.

For example, new people trying Panopoly from Git will immediately hit issues like #2115807: Unpublished dev release from a couple hours ago - when there's been a patch to fix this RTBC'd for almost 2 months #2071133: Update URLs for backbone and underscore for Whitelist.

Also, there's lots of bug fixes from Open Atrium, for example, which Open Academy could use - so they have to go and add them to their make file. If you start a new distribution on Panopoly, you've got to walk through the issue queue, test them and put them in your make file too. If they were committed upstream, it would increase the ability of all these distributions to collaborate!

This isn't meant as a negative comment against @populist! He's an awesome developer and maintainer and does great work. However, I'm sure he's also very busy. :-)

What I'm trying to suggest is that maybe it's time that some of the other stakeholders - the people who now depend very heavily on Panopoly - were given the opportunity help with the maintanence of Panopoly!

I'm not necessarily suggesting myself - although, I'd love to do it and I already contribute lots of patches and help out with support as much as I can. ;-) But I'm also a relatively minor player.

Maybe a representative from each of the major distributions based on Panopoly makes sense? So long as they have a history of contributing quality patches, I'd personally be OK with it. From Open Atrium, that could be @hefox or @mpotter? From Open Academy, it could be @mrfelton?

Of course, this is not a complete list, but I've also seen great work come from @arshadcn and @Andrew_Mallis among others who aren't connected to a major distribution.

Anyway, I think we can all agree that Panopoly is a success! The idea of a distribution to build distributions clearly worked. So, how do we take that to the next level? There is this community of people contributing patches, fixing bugs and providing support - how do we take advantage of that energy in a way that is most beneficial? How does Panopoly grow up and evolve?

Personally, I think adding some new co-maintainers (from the community) who can help add more resources to the project is the answer.

But I really just want to start the discussion and see what everyone thinks! Thanks!

Comments

mrfelton’s picture

@dsnopek, As maintainer of the Open Academy distribution, I have to agree with the sentiment above. Panopoly is awesome, and we get a lot by basing Open Academy off it. But, using a base distribution that is a little behind and sometimes slow to catch up does become a bit of a burden at times. We currently have a large number of patches applied against it to make it work for us, and I know that the Open Atrium team does too.

I would be more than happy to act as a co-maintainer of Panopoly, and help keep it up to date and moving forwards. I also agree that it may be a smart move to get some of the other Panopoly based distro maintainers involved at that kind of level too.

Perhaps we should also think about setting up a group on groups.drupal.org or some other similar home where people working with Panopoly can pool resources and converse more easily outside of the Drupal issue queues too.

dsnopek’s picture

@mrfelton: Thanks for adding your comments!

For a frame of reference on patches that distributions are adding to Panopoly, here are some make files:

Several of the patches used are common.

Anyway, I know this isn't just a numbers game! The real issue is deciding how to evolve as a community. However, I thought it would be good to back up "a large number of patches" with some data. :-)

dsnopek’s picture

@mrfelton: I forgot to add that I like your idea of creating a group on g.d.o! That'd be much better suited to general discussion.

kmonty’s picture

Priority: Normal » Critical

Considering this profile has been shipping with insecure contrib module code for months, I +1 nominate either mrfelton, dsnopek, or both, based on their excellent work in the issue queue I've been witness too.

(Also bumping this up to critical, as insecure code = dangerous code.)

sheldon rampton’s picture

This sounds like a great idea to me. I speak as someone who ahs been building a distro myself will use Panopoly as a base distribution.

dsnopek’s picture

@populist and I discussed this quite a bit at BADcamp last week and I just e-mailed him asking about next steps. Hopefully, we'll move forward on this soon!

caschbre’s picture

I'm basing a new distro on panopoly (well, trying to at least) and I'd be interested in the g.d.o group. Has that been created?

dsnopek’s picture

I just created a group on g.d.o, but it isn't approved yet:

https://groups.drupal.org/panopoly

Please join!

@populist: Once you join, I'll make you a "Group organizer".

dsnopek’s picture

The Panopoly group on g.d.o has been approved! I encourage everyone following this issue to join. I'll post an introductory post in a couple days:

https://groups.drupal.org/panopoly

@populist: I'm still waiting on you to join the group, so I can make you an administrator!

populist’s picture

Issue summary: View changes
Status: Active » Fixed

+1 to setting up a GDO group and to getting this conversation growing. As more folks use Panopoly for their projects, having a broader group of co-maintainers moving this forward is a great idea.

I had some great conversation with dsnopek around all of this at BADCamp and was glad to see mrfelton volunteer since his code contributions have always been really strong. With the power invested in me, I pronounce both of you co-maintainers! Let's keep the discussion rolling in the issue queues, emails, and GDO group.

dsnopek’s picture

Woohoo! Thanks, @populist. :-)

mrfelton’s picture

good stuff :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.