Non-core contributed modules

Justin - I've created the Patch: Elluminate component and so I am going to resolve this issue as fixed. I try to stick with keeping the name simple by basing it on where the code is. So in your case it is Patch: Elluminate.

That said, I am wondering if you should not have two separate packages. We created the concept of a package to combine a block and module into one zip file. Technically, the code you have does look like a patch (which involves changes to stored code and ideally consistes of a diff file) but instead a combination of 4 plugins. If this is correct, I would like to consider moving those to their proper location under plugins. Then, if you wanted we could rename Patch: Elluminate to Package: Elluminate and just have one component and let folks know that it is for both the elm and sas version of the Elluminate packages. This issue of integrating with other software is one that I want to throw out to the developers and give some thought as to how we can best manage them in CVS. It is a challenge to figure out how to manage in our CVS integrations for things like Drupal, Elluminate, DimDim, etc. because the versions of those programs do not correspond to our own development tree.

I would appreciate your consideration and thoughts on moving the code (if it seems appropriate) to the appropriate plugin folders and also any comments about how best to handle the various versions. One idea I have is to create special branches but I need to coordinate this with Eloy so that the appropriate/needed zip files get automatically created.

Peace - Anthony

Justin - Just to follow up, I had forgotten that I had created MDLSITE-544 to discuss how to deal with different versions. If you want to comment on ideas for how best to handle that issue it would be best to do so there. Peace - Anthony

Okay, just to confirm everything...

1) There is currently three separate entries in Moodle contrib for Elluminate: '/plugins/blocks/elluminatelive', '/plugins/mod/elluminatelive', and '/patches/elluminate'.
2) We have been maintaining only the '/patches/elluminate' entry.
3) The patch actually contains two separate versions (releases) of the Elluminate Live code; one for ELM and one for SAS.
4) The patch is not really a patch because it does not change any core Moodle code, but rather contains plugins.

So, using the new reasoning, this should really be a package not a patch. And further, we probably need two packages - one for SAS and one for ELM. If we do this, it would make sense to remove the patch and plugins completely.

I don't see the 'package' directory in contrib. Is it there?

Mike - Thanks for helping to clarify things. I was not aware of the Elluminate Live code in the plugins section. Just to help me understand things better, what is the distinction between the block and module in plugins and the versions in patches? Also, what does ELM and SAS stand for (mostly out of curiosity). I'm trying to envision what our ultimate goal is. Do we need two version (ELM and SAS) or is the one in plugins a third version? By saying you only maintain wht is in patches is that to say that the code in plugins is outdated and can be 'discarded'. If so, depending on how Eloy and I work out MDLSITE-544 we could move the code from patches to plugins, create the various branches, and setup the packages to produce two zip files (one for ELM and one for SAS). For more information on how packaging works see MDLSITE-411. Essentially there is a text file (see http://cvs.moodle.org/contrib/tools/package_builder/packages.txt?revision=1.3&view=markup) where we list the code that goes into making a package so there is no directory. Peace - Anthony

Hi Anthony,

The files for this in plugins/ is outdated. The code in patches/ is what is up to date.

And ELM and SAS are just two different server types that Elluminate provides. ELM is the stand-alone server that you can install on your own server hardware and SAS is their hosted service where they run everything for you. The Moodle integration functions the same with both server versions it's just that the underlying code is different depending on which you are connecting to.

Thanks for getting the component setup for us. I think we'll remove the code from the plugins/ directory and note this with an issue in the new component.

Okay. I removed the block and module from the plugins directory...

So, we just need to add the others to 'patches', and when the packaging scheme is finalized, utilize that?

mike

Justin and Mike - Thanks for removing the old code from plugins. Actually, what I envision is moving the code that is currently under patches to plugins; however, before doing so I want to make sure that Eloy and I get MDLSITE-544 resolved so that we do not have a whole separate directory sitting around for the two versions. If things go as I hope (and that is a big if) there would simply be /plugins/blocks/elluminate and /plugins/mod/elluminate. We could consider keeping it called elluminatelive if we wanted (it makes no difference to me). Then we would create packages for the two versions (ELM and SAS). For now, just go ahead and continue to maintain things under patches as it seems to be functional for the time being and we can work at cleaning up and making it more theoretically 'proper' later. Long term my goal would be to have the packages created by combining the block and mod from plugins rather than the code in patches. Hopefully that makes some sense, if not don't worry. I'll keep you updated and ask before I change anything. Peace - Anthony

I am reopening this issue until we finally have it resolved as to where and how things will be worked out for the elluminate code. I know I sent messages to Mike Churchward and Justin and then realized it would be good to keep track of the history here so I am copying what I sent to Mike.

—
I am trying to keep a handle on the rapidly expanding CONTRIB section. It looks like a directory was created/committed which I suspect was a mistake and I was hoping that you might be able to confirm that /contrib/patches/eluminate_sas can be deleted. There are no files in there but I figured I would check with you. I'm just concerned that a typo could cause some confusion down the road so if I can get Martin to delete it I think that would be best but I wanted to check with you first.

Then when we get MDLSITE-544 resolved, we can hopefully move back to using the plugins folders and package them as needed for the various versions. One of the questions I asked Justin was to help clarify for me which patches folders we will be using for active development. It looks like you created some new ones. For example, I wonder if there would be a problem in having the code for elluminate_elm and elluminate_sas in a single zip file or is it important to separate them. If we just want one elluminate.zip file with both folders in them then we should use contrib/patches/elluminate/elluminate_elm and contrib/patches/elluminate/elluminate_sas. If we really need to separate them and have two zip files (elluminate_sas.zip and elluminate_sas.zip) then we should use contrib/patches/elluminate_elm and contrib/patches/elluminate_sas. I definitely want to get rid of whatever is not needed. My preference would be to have the sas and elm versions together under contrib/patches/elluminate because that will be more consistent with how things will be if we are able to use additional branches for the elm and sas versions. Both of them would be called elluminate.zip but we would append the branch name containing elm and sas to the packages so that we would have a link something like http://download.moodle.org/download.php/packages19_elm/elluminate.zip (for the 1.9 Moodle version of the elm code). It is not a huge deal either way but I do want to eliminate any folders we don't need and find it confusing right now - not to mention that it adds clutter to the CONTRIB tree.

Peace - Anthony

Mike - Just to avoid any confusion, could you be specific about "they should be able to be deleted". I get confused as to which files you are referring to. I believe we said that we would delete everything under /contrib/patches/elluminate so that you could have separate zip files.

I think we starting cleaning up the files in contrib/plugins/elluminate/blocks/elluminatelive and contrib/plugins/elluminate/mod/elluminatelive by deleting them; however, it looks like this was just done in HEAD. I'm not sure if you want to do the same for 19STABLE branch. There are branches for 1.5, 1.6, 1.7, and 1.8. I'm trying to think how we are going to keep some type of reasonable history with the files all over the place. This really seems to have become quite a mess. Do you want to try to preserve some of the history - versions for Moodle 1.5, 1.6, 1.7, 1.8 and 1.9 or would you prefer to have just one version of the Elluminate code in CONTRIB (namely the ones in contrib/patches/elluminate_elm and contrib/patches/elluminate_sas)?

I'm going to post this to CONTRIB-1045 where we have some of the history of this conversation. I'm trying to keep it in one place so I can review/remember all of the various pieces. Peace - Anthony

Mike - Just to follow up on your question about how to use HEAD in CONTRIB, I think of it as the development version. It is up to the maintainer to decide what links they want to give in the Modules and Plugins database. For some folks, they do not bother or need to maintain branches of the code and only support a particular release. They use HEAD for the latest "stable" release. Others, will use the 1.9 branch for Moodle 1.9 and HEAD for Moodle 2.0. So there is no one "right" way to use HEAD. It sounds like you would prefer to use it as a development branch. Feel free to do so and just keep your stable releases for the various versions of Moodle in the appropriate branches and merge changes appropriately as we do with Moodle core code. The download link you give will be to http://download.moodle.org/download.php/patches19/elluminate_sas.zip and you do not have to provide a latest release file if you think folks might be using your development code. On the other hand you may want folks using the development version to help with testing. It is really up to you as long as you explain what the versions mean for your projects. Does this make sense? Peace - Anthony

Mike - Just out of curiosity, why are you still using or maintaining mysql.php in your recent elluminate commit to the 1.9 branch? I see that you have an install.xml file and it seemed unnecessary. Peace - Anthony

Sorry for the confusion...

You can delete the '/contrib/patches/elluminate' directory. I have now added branches for "MOODLE_19_STABLE" and "MOODLE_18_STABLE" for both '/contrib/patches/elluminate_elm' and '/contrib/patches/elluminate_sas'. I think that is all we will support for now, so you may as well remove the ones in "plugins" as well.

So, that will give us a MOODLE18, MOODLE19 and HEAD version.

I would like to have a link to the latest development version, but I worry that the text "Latest release" will fool non-developers into thinking its the correct one to use. So, for us, its safer not to provide a link to the development version. This is solely an issue with what the labels say in the database module.

The "mysql.php" contains any updates from older versions of the module. These were replaced by "upgrade.php" in later versions of Moodle, but are usually kept for upgrade purposes in case someone upgrades from a much older version. The "install.xml" replaced "mysql.sql" and "postgres.sql". Those files should be gone.

mike

Mike - Actually since you have the access, would you mind deleting the files? If you do not have time let me know and I'll try to carve some out for this. As long as you explain what you mean by the latest development version on the M&P page and in the docs install section I think you should be fine but if you do not want to provide the latest version that is fine. I wonder if we could get away with changing that to say Latest development version. Any suggestions on how we could best handle the labels? As for mysql.php, I meant mysql.sql. 'm not concerned - it just caught my attention when I saw the commit so I figured I would mention it. Peace - Anthony

I believe this has been handled as best it can until packages are available... The extraneous directories have now been deleted.

Thanks for deleting the extraneous directories.Packages are available and we can easily set that up but I figured I would wait a little until we sorted out some of the other stuff first. Let me know when you are ready to make the transition and we will make it happen. Peace - Anthony

Closing all of my resolved issues. Peace - Anthony