Hi Everyone!
Welcome to the Panopoly group. :-) I hope this will become THE place for all the people who depend on Panopoly to discuss and plan its future.
To start things off, I'd like to describe the state of Panopoly as I see it, talk about getting to version 1.0 and moving beyond into the future. Of course, this is all just my opinion -- feel free to share yours and disagree. At the moment, only @populist's voice carries any real power (but I'm hoping that will change soon - more on that below).
The State of Panopoly
Panopoly is really taking off! There are many major distributions moving to it (such as OpenAcademy and OpenAtrium) and more new ones picking it up. The idea of a distribution to build distributions has clearly struck a chord!
The main roadblock at the moment is the the rate of development and how quickly patches are reviewed and integrated upstream. Lots of people are using the code, submitting patches, and even (to a lesser degree) reviewing -- but those patches are just sitting in the queue, waiting to be committed.
Right now, @populist is the only maintainer - and while he's a great guy and an awesome developer - he's only one person! The needs of Panopoly now exceed the ability of one person to handle.
There is an issue in the issue queue discussing the possibility of adding new co-maintainers to the project - please check it out for more information: Add co-maintainers to Panopoly?
Getting to 1.0?
Once we've got the team worked out to take us forward, we need to decide where we are going.
Personally, I think the next release we make should be 1.0, which should simply contain all the current RTBC patches and as many others as we can review and test in 4 weeks.
If we are consistently committing patches over this 4 week period, that'll give the distributions that depend on Panopoly time to test it out and give feedback.
So, 1.0 will just be an updated version containing all the patches that we are all probably already using. :-) Nothing exciting ... yet!
Moving foward!
Panopoly is a community resource that more and more people are depending on. In order to keep it healthy, we'll need to be continuously reviewing, testing and committing patches.
Also, since Panopoly is a "base", we won't likely be working on sexy new features but more often things like updating module dependencies and making sure they don't break anything.
For this reason, I think (again, just my opinion) that we're going to end up releasing a lot - like maybe even once a month or once every other month. In order to reduce the amount of manual testing this will require, I'd like to propose setting up some kind of continuous integration for Panopoly.
I've already started work on this, but so far don't have anything to show -- I keep getting distracted by interesting tangents, such as: Why the heck is 'drush make' so slow and how can I make it faster? ;-) But in the next couple weeks I should have something setup.
Here is the issue where I'll post my updates: Setup continuous integration server for Panopoly
What do you think?
Again, the above is just my personal thoughts and plans with regard to Panopoly. Do you agree/disagree? Is there something missing?
Please let me know in the comments below! Thanks. :-)
Comments
I'm very interested in
I'm very interested in keeping panopoly moving forward with regular updates. I had been building my own distro very similar to panopoly and have since scratched that to make mine based on panopoly.
I think getting to a solid 1.0 release would be great but we may need a bit more clarity on what that entails. It may be more than just the RTBC patches, I haven't had a chance to look through all of those yet. Should we have a separate thread to discuss what should go in there? I'm guessing the RTBC patches along with making sure all of the modules that are used by panopoly are upgraded as best they can be.
Maybe we should tag all of the issues in the queue with a unique tag so we can easily track, test, commit those?
I know there are a few other distros that are based on panopoly and have to a) manually add patches to their own make files and b) override contribs to get to a newer version. Ideally panopoly can keep frequent enough so other distros can avoid that.
On the other hand, will too frequent of updates cause issues with other distros that are based on panopoly?
-
@foggyperspectiv | foggyperspective.com (blog)
Thanks for joining the
Thanks for joining the discussion! :-)
Of course, this is open to debate, but in my opinion 1.0 is just a label. And if we're going to be doing monthly or bi-monthly releases (in order to keep up with module upgrades and security releases), then the label doesn't really matter too much. In two years, we could have Panopoly 1.24!
I'm worried if we delay to make 1.0 perfect or include too many things, then it'll never get released because there'll be more module upgrades and we'll just keep churning on it. That's why I was suggesting that we timebox it to four weeks.
My hope is that 1.0 will just get us to the point where we already are, but without the majority of patches in every distros make file.
Creating a tag for everything we think should get committed once we start moving forward is a great idea! That would allow us to focus our reviewing and testing. Maybe we could reuse the "sprint" tag that the core team uses for a similar purpose?
At the moment there are issues in the issue queue (with patches) for updating every module up to it's latest version! I've got a cron job that runs drush makefile-check nightly and sends me an e-mail. :-)
It's just a matter of testing everything with the updates and making sure the upgrade path works. I'm particularly worried about the Search API stuff: Update Search API modules
So long as we do enough testing (which will be the slowest part of this process - hence my desire for CI), I don't think we can update too fast for other distros. They always have the option to stay on an older version if they're not ready to upgrade. That's my opinion, at least. :-)
Thanks again for joining the discussion here!
Regards,
David.
Marking issues as "sprint"!
I went through the Open Atrium make file and marked all the patches they use as "sprint" in the Panopoly issue queue.
I also picked out a couple issues that are important to me. :-)
Here you can see the current list:
https://drupal.org/project/issues/search/panopoly?sid%5B%5D=Open&issue_t...
I invite everyone else here to do the same for your distros make file. For now, this is really just a list of which issues are important to distro maintainers.
Like I mentioned above, I'd like to time box the development for the 1.0 release to four weeks. So, we'd start working on the RTBC + sprint stuff first, and whatever we get done in four weeks becomes 1.0. And then we keep going (for 1.1)!
But at this point this is all just my opinion. :-) We need to get @populist in here to give the final word and to add some new co-maintainers so we can start committing (and the four week count down, if he agrees with my plan).
However, we can start reviewing stuff in the issue queue right away!
Yeah, I'm good with that
Yeah, I'm good with that process of monthly sprints to knock out the top priority items. We'll just want a way to prioritize issues then since we may have more items tagged for a sprint than we can accomplish.
I skimmed the issue queue and the only other ticket we may want to tackle is [#2087075].
-
@foggyperspectiv | foggyperspective.com (blog)
Good points!
Good point about priority - however, I'm not sure how best to do that.
Yeah, I agree that issue (#2087075: updating Media) is super important! But it's also probably going to be a difficult one. :-)
I think it'd be best to set the bar low for 1.0 and focus on the technical debt we've built up by not committing anything for so long first. Then once that's out of the way we can start on the more difficult stuff. Of course, if someone did the work and got a patch written, tested and upgrading flawlessly, it could get in too! :-)
Maybe instead of prioritizing
Maybe instead of prioritizing tickets, we simply use a blocker tag. All blockers have to be fixed before we roll a new release. Anything else is more a matter of who jumps in on the tasks to complete them. That way we don't have to worry about prioritizing.
For [#2087075] let's leave it out of the 1.0 release for now unless someone gets it done as you mentioned... but make it a priority (i.e. blocker) for 1.1?
-
@foggyperspectiv | foggyperspective.com (blog)
That would probably work. My
That would probably work. My only concern is issues marked as "blockers" holding back release overly long and then we could end up in the same situation as currently. :-/ Since this is an all volunteer team, we can't really require anyone to work on specific issues. Let's keep discussing how to do this!
I'm worried if we delay to
I generally agree with this, however, given how many module upgrades/RTBC patches exist, I would lean on getting all of those committed as soon as possible, cutting a final RC release, and then going 1.0 in a month. That gives us plenty of opportunity to test the backlog of changes before declaring everything good to go.
Super excited!
I'm a believer in the power of Panopoly. Let's keep it going forward.
I'm interested in hearing what it takes to get CI working for this project. I'm looking to use this distribution during next year's Overnight Website Challenge (last year's: http://tc2013.overnightwebsitechallenge.com/ ) where we are likely going to need to use CI to do frequent builds of our site.
Software Engineer @ The Nerdery
So what are our next steps to
So what are our next steps to getting those issues you linked to committed?
-
@foggyperspectiv | foggyperspective.com (blog)
We need @populist to join the discussion! :-)
We need @populist to join the discussion! :-) He's the only maintainer right now, so we need some more folks made co-maintainers and his blessing on the plan. He just e-mailed me today and says he'll get on this in the next couple days. To quote his e-mail (I hope he doesn't mind):
;-)
Drupal 8
Also, with Drupal 8 heavy on the minds over all developers, we should be looking for problem areas for porting the work to Drupal 8.
What get's cut? What get's reduced? What is dropped and rewritten? How does the Drupal 7 version change as a result of those architectural choices?
Would be kind of fun to pursue this challenge because Panels support is something that a lot of other sites will want. And Panopoly is what makes Panels awesome.
Software Engineer @ The Nerdery
Those are some really good questions!
Thanks for joining the discussion! Those are some really good questions. :-)
One issue that I know we'll have to deal with sooner or later is that Panopoly is currently using TinyMCE but Drupal 8 is bundling CKEditor (and the current Edit module only works with CKEditor): Support CKEditor and inline editing in Panopoly
However, it's the port of Panels (and Panelizer, IPE, etc) to D8 that's going to be the biggest and most difficult part of this. Once that effort starts to materialize, we'll have to follow it very closely!
Thanks again!
David.
We could probably tackle the
We could probably tackle the ckeditor / edit features in a 7x branch if nothing else than to see what all we have to do. The parts that really depend on panelizer, panels, etc. we'll have to wait on those to be ported first.
-
@foggyperspectiv | foggyperspective.com (blog)
Whoa, the Layout module was removed from Drupal 8!
Parts of Panels were supposed to end up in core in Drupal 8, but it appears that much less will be included than hoped. I just found out that the Layout module was removed:
https://drupal.org/node/1813372
However, I believe that there is still context for blocks in Drupal 8 core, which means that (hopefully) Panels will be able to use core blocks rather than implementing it's own thing this time around. Also, there's equivalents for pretty everything that was in CTools in D8 core.
Ugh... I didn't realize that.
Ugh... I didn't realize that. What was the reason?
-
@foggyperspectiv | foggyperspective.com (blog)
Time, mostly
Getting the UI pieces figured out was going to take too much time. The blocks and layouts initiative was cut short to just "blocks" but in the process we got a pretty robust plugin system that goes beyond ctool's capabilities because it's can be hooked into just about anything.
Take a look at how they're used for views, fields, and field formatters.
Since there wasn't time to implement "layouts" the focus of the system is to have everything that would be needed to eventually implement them.
Software Engineer @ The Nerdery
We're aiming to release Panopoly 1.0 right before Christmas!
We forgot to announce this publicly, but myself and @mrfelton were added as Panopoly co-maintainers and we've all agreed to sprint to a 1.0 release which will come out during the week of December 16th, right before Christmas!
The main issues we're focusing on have been marked with the "sprint" tag:
https://drupal.org/project/issues/search/panopoly?sid%5B%5D=Open&issue_t...
If @mrfelton can find the time for it, he's also planning on taking a stab at the Media upgrade. We'll see if there is enough time to do enough testing to get it included in 1.0!
If you want to help us get there, please review/test patches or otherwise help us get organized in the in the issue queue! I'd like to give special recognition to the amazing amount of work that lsolesen has been doing in the issue queue: categorizing issues, attempting to recreate bugs, asking for more information and testing patches. Thanks so much to lsolesen and everyone else who's been helping out!
There's a lot to do and we're an all volunteer team. In fact, if you're in this group or following in issues in the issue queue then YOU ARE PART OF THE TEAM! ;-)
Thanks again and take care!
David.
Stable!
Congratulations to everyone who worked hard to get 1.1 out!
(happy me)