Non-core contributed modules

Bulk user improvements directory creation request

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.9
  • Fix Version/s: None
  • Component/s: Add a project here
  • Labels:
    None
  • Affected Branches:
    MOODLE_19_STABLE

Description

Requesting to create /contrib/patches/bulk_user_improvements/ directory in CVS for storing Bulk User Actions plugin architecture improvement and corresponding actions.
Original conversation with Anthony Borrow:

Friday, 27 February 2009
Vlas Voloshin [06:08 PM]: Hello, Anthony! There's another question I would like to ask you. As you may already know, I've been developing a bulk user actions improvement for some time already: a plugin architecture and corresponding actions for it. I can't be sure, if anyone is interested in it besides me, but maybe there's an opportunity to keep it all in contrib CVS, in /contrib/patches/ for example? I hope this would be more convenient for installing purposes as well as for me to support it. This could also raise more attention to it, so the architecture may evolve further. My improvements are described in tracker: MDL-16793 and in forum: http://moodle.org/mod/forum/discuss.php?d=106961
Thanks in advance,
Vlas Voloshin.
Anthony Borrow [08:54 PM]: Vlas - Definitely, I am happy to help you host whatever code you want to share. We can offer the code to others and if it seems to help them they will use it. If not, it does not hurt to have it available. Usually with patches we try to maintain a patch file to use for installation. Alternatively and/or simultaneously we can provide a zip file of all the files patched which makes it easier for folks that are not familiar with working with diff files. The downside is that doing so requires a bit more maintenance as you then have to merge in changes from core and tell the person installing to have the latest version of that release which is why the diff file is preferred. All of this may be more than you need to know at the moment. One question I have is whether your changes will help resolve MDL-16793 or whether they are separate from those items. If they are part of MDL-16793 I would say just attach your diff files so that Eloy (and others) can have a look at them. I think the best thing to do is to break out the patches into specific improvements. Sort out which ones are slated for core and provide patch files for those in the tracker. Others that seem unique we can put in patches but I would like to keep them separated. One patch per new function. For each one we should have a separate issue in the CONTRIB section of the tracker. That will keep things manageable. I would rather have several small tracker issues that we can resolve, than one big one that gets big and confusing. Then if you want we can create a package of patches that could be the Vlas package. Does that make sense/sound reasonable? Peace - Anthony
Saturday, 28 February 2009
Vlas Voloshin [04:36 PM]: Well, actually MDL-16793 is our "plan" to improve bulk user actions functionality. I just wanted its whole results to be in one place. The plan may be "divided" in three components: architecture improvements, new actions and miscellaneous little fixes. Though the architecture components change the code in admin/user, it actually makes many files (standard actions) not needed anymore, as they are put in their own directories inside /admin/user/actions. Also, the main problem is maintaining of our code. If we keep updating it with patches, then patches on patches etc... it would be unpleasant for both us and its users, especially new (they would have to apply several patches to install the whole thing). That's why we think that it would be more convenient to keep it all new in one place and make "local" patches if necessary. The other component - the new actions - may be stored in other section, of course, but the problem of maintaining will stay, if we don't have some repository of current code version. And I don't think that new plugin type (bulk user action) will be created just to use it in some non-core contributed code smile That's why I proposed to have a single directory in contrib CVS which will be used as a substitution to the whole admin/user directory. If the user doesn't need some of the actions stored in that directory (including standard, by the way - all actions are used dynamically and standard ones are not "better" than others), they may just delete them from their /actions/ directory. Of course, if there is possibility to have new plugin type in contrib section, it would be wonderful, but we don't expect it smile
Anthony Borrow [07:17 PM]: OK - so it sounds like it would be helpful and possibly useful to you to have a directory like contrib/patches/bulk_user_improvements or something along those lines. You would be able to use that however you would like to work on these improvements. I've explained how the patch folder typically works but there are no hard and fast rules so you can use it in so far as it is helpful to you. The only thing I need from you is a tracker issue in CONTRIB requesting the creation of the directory and perhaps just copying your message or our conversation here. Then I can create the directory and update your CVS write access to include the new directory. Think of a name that describes the patch(es). I suggested bulk_user_improvements but you may have been thinking of something more practical and/or shorter. Peace - Anthony

Activity

Hide
Anthony Borrow added a comment -

Vlas - I have created the directory and modified your CVS write access to include it. Let me know if you need anything else. For example, would it be helpful for you to have a component here in the tracker called Patch: Bulk user improvements? If you think others will be filing feature requests, bug reports, etc. we can set that up easily enough. Peace - Anthony

Show
Anthony Borrow added a comment - Vlas - I have created the directory and modified your CVS write access to include it. Let me know if you need anything else. For example, would it be helpful for you to have a component here in the tracker called Patch: Bulk user improvements? If you think others will be filing feature requests, bug reports, etc. we can set that up easily enough. Peace - Anthony
Hide
Anthony Borrow added a comment -

Directory created - CVS access granted. Resolving as fixed. Peace - Anthony

Show
Anthony Borrow added a comment - Directory created - CVS access granted. Resolving as fixed. Peace - Anthony
Hide
Vlas Voloshin added a comment -

Thanks, Anthony!
If there'll be a need to create a new contrib component, I'll notify you. Right now, I think, it's not quite necessary.

Show
Vlas Voloshin added a comment - Thanks, Anthony! If there'll be a need to create a new contrib component, I'll notify you. Right now, I think, it's not quite necessary.
Hide
Anthony Borrow added a comment -

OK - thanks. For development purposes I think we can continue to just use this issue number for commenting on CVS commits (we usually try to associate every commit with an issue in the tracker for purposes of documentation). Once you make the patch public, then it is helpful to have a component in the tracker so that issue can get routed directly to you. Thanks for your work on these issues. Peace - Anthony

Show
Anthony Borrow added a comment - OK - thanks. For development purposes I think we can continue to just use this issue number for commenting on CVS commits (we usually try to associate every commit with an issue in the tracker for purposes of documentation). Once you make the patch public, then it is helpful to have a component in the tracker so that issue can get routed directly to you. Thanks for your work on these issues. Peace - Anthony
Hide
Anthony Borrow added a comment -

Closing all of my resolved issues. Peace - Anthony

Show
Anthony Borrow added a comment - Closing all of my resolved issues. Peace - Anthony

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: