Voting starts in March for the Drupal Association Board election.
I discovered that both openpublic 7.x-1.0-alpha5 and openpublic 7.x-1.0-beta5 are trying to patch core. Currently, the release nodes even say it happened. However, if you download the tarballs and inspect them, the patches were never applied.
There's a very long story here, which I'll attempt to briefly summarize.
When the packaging script is building fully-packaged distro releases, it needs to do 3 distinct steps:
- Check the install profile directory out of Git from the appropriate tag and create a tarball of just that
- Build the drupal-org.make file (if it exists) in --no-core mode to get the profile and all dependencies without core
- Create a separate .make file to *just* build core and then move the directory tree from step #2 into place under the profiles directory
There can't possibly be a single .make file that handles step 3 for us, since there's no way to get .make to put the profile into place without the profile release already existing. And of course, we're in the middle of creating that release at this point. Chicken, meet egg. There's a secondary problem that once you have drush make building recursively, if you had a single .make file that defines core, the profile, and all the dependencies, there's no guarantee that the profile will get built first so that all the dependencies can install themselves as subdirs of the profile.
SO, we definitely need a separate .make file to build core, then to manually move the profile and all its dependencies into place to be able to package the full distro.
Currently, the packaging script is just spitting out a trivial little core-only .make file based on the core attribute in your drupal-org.make file and building that. Of course, that just silently ignores any special sauce distro maintainers put in drupal-org.make for the drupal project (checking out from a specific git revision, patching core, etc).
After extensive research and discussion with hunmonk, we came up with 2 possible solutions to this that will actually work. I'll list the unique pros to each approach. Also, since it's nice to have a .make file that can be built by developers or people deploying directly, I'll explain how you'd do that in each of the two approaches for comparison.
A) Add optional support for a separate drupal-org-core.make file if you need something more fancy than "core = 6.23" in your .make file.
The 'drupal' project would be disallowed in the main drupal-org.make file itself. So, if this file exists, the packaging script would build that when it needs to build core for your distro. Otherwise, it falls back to what it's doing right now.
- drupal-org.make (all projects, libraries, patches, except core)
- drupal-org-core.make (just core, if you need something fancy)
- build-[profilename].make (bootstrap for local development builds) Something like this:
api = 2 core = 6.x includes = drupal-org-core.make projects[openpublish] = 1.0-beta5
This includes the core specification directly, then points to a release (or git tag) of the profile which then builds the drupal-org.make file recursively.
- Requires no changes to drush itself -- could be fixed and deployed without intervention by drush maintainers.
- More simple and less duplication to get the build-[profilename].make file working properly
- Might be easier to not have core inside drupal-org.make for other reasons (febbraro had a gut feeling about this, but needed to clarify)
- Requires more documentation for distro maintainers.
- Possible gotcha that you have to define special sauce for core in a separate file.
- Will further complicate the drupalorg_drush plugin since the validation stuff is going to be more complex. We'll need to prevent 'drupal' project from being defined in drupal-org.make but *only* let you define that project (and its patches, etc) in drupal-org-core.make.
B) Keep everything, both core and all the profile dependencies, in drupal-org.make.
For this to work, we'd need to getcommitted to drush ASAP, and have the packaging script use that to build core directly out of your drupal-org.make file instead of creating a separate core-only .make file.
- drupal-org.make (all projects, libraries, patches, and core)
- [profilename].make (everything from drupal-org.make *except* core)
- build-[profilename].make (replicate all the core stuff from drupal-org.make, then include a pointer to the profile to build that recursively, which will use [profilename].make)
Note that this requires a lot of duplication in the .make files (core lives in both drupal-org.make and build-[profilename].make, all the projects/libraries/patches have to be replicated between drupal-org.make and [profilename].make) although part of that could be mitigated ifwas done.
- Easier to validate since everything is in a single .make file.
- Only one file to update when making a new release, instead of having to remember to update the core file, too.
- No changes needed to the drupalorg_drush plugin to change the validation logic.
- Requires a new feature in drush before we can deploy this and make it work.
- Complicates things for the "build" makefile to work properly (see above).
After a long IRC chat with with febbraro, ezra-g and webchick we decided option A is better. However, that was before I realized the pros/cons associated with changing the validation logic in the drupalorg_drush plugin. ;) So, maybe B is better after all. Luckily, everyone agreed these were roughly equivalent solutions, and no one felt super strongly about either one.
So, if anyone has other thoughts, different assessment of the pros/cons, etc, please let me know ASAP.