Re: [Gallery3] Wrapping up 3.0.5

Hey everyone,

With the warning messages in place and the doc page written (and revised -
thanks, floridave!), I thought I'd take a stab at the short messages to
include elsewhere.

-----
- Download page for v3.0.5 (e.g. http://galleryproject.org/gallery_3_0_5)
- Forum post for v3.0.5 (e.g.
http://galleryproject.org/gallery_3.0.5_feedback)

Obsolete Modules

Upgrades to Gallery v3.0.5 have made the following modules obsolete:
Digibug, NoFFmpeg, VideoDimensions, and Videos.  If you're currently using
these modules, we recommend that you deactivate them. For more information,
please see the documentation page at
http://codex.galleryproject.org/Gallery3:User_guide:Obsolete_modules.

-----
- Forum posts for the obsolete modules
- Documentation pages for the obsolete modules

Update: recent upgrades to Gallery have made this module obsolete.  If
you're currently using it, we recommend that you deactivate it. For more
information, please see the documentation page at
http://codex.galleryproject.org/Gallery3:User_guide:Obsolete_modules.

-----
- Gallerymodules.com

Ideally, rather than making a site-wide message, it'd be great to prepend
the descriptions of the modules in question to include:

<b>(Obsolete - see documentation here)</b>

With an href on "here" to the doc page at
http://codex.galleryproject.org/Gallery3:User_guide:Obsolete_modules.
 Dariush - would this be easy to include?


Feedback?  Other thoughts?

Thanks!
Shad


On 21 February 2013 12:49, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> Hi everyone,
>
> Now that Bharat and I have gotten the warnings pulled into the code, I
> took a stab at making the doc page:
> http://codex.galleryproject.org/Gallery3:User_guide:Obsolete_modules
>
> Thoughts?  Feel free to edit it directly if you like...
>
> Thanks,
> Shad
>
>
> On 20 February 2013 15:56, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>
>> Hi everyone,
>>
>> Following up on this, I made this pull request:
>> https://github.com/gallery/gallery3/pull/155
>>
>> It adds a warning message to admin/dashboard, admin/modules, and
>> upgrader.  My goal was to inform the user and let them do what they want
>> without annoying them (persistent site status warnings) or prohibiting them
>> (forcibly disallowing and/or deactivating things).
>>
>> The "obsolescence check" itself looks at the list of active modules *and*
>> their version numbers.  This leaves open the possibility of someone
>> completely overhauling a previously-obsolete module, upping the version
>> number, and having it work without issue.
>>
>> Thoughts?
>>
>> Take care,
>> Shad
>>
>>
>> On 20 February 2013 09:15, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>>
>>> Hey gang,
>>>
>>> Thanks for the feedback!  Based on that and a bit more thinking on my
>>> end, I *think* I have a clearer idea of how to do this.  Any and all
>>> feedback welcome.
>>>
>>> Motivations:
>>> - If we're obsoleting a bunch of modules, it'd be nice to give a little
>>> explanation.  At the same time, it'd be nice not to muddy up release
>>> announcements with a bunch of text that only affects people who use
>>> now-obsolete modules.
>>> - While this is the first occurrence of purposefully obsoleting modules,
>>> it may not be the last.
>>> - This solution should probably be applied to the digibug module, too,
>>> as the company no longer exists :-(.
>>>
>>> Solution:
>>> - Add a new doc page, for example here:
>>> http://codex.galleryproject.org/Gallery3:User_guide:Obsolete_modules.
>>>  Here we have a short intro blurb, then a stanza for each module we've
>>> obsoleted with a bit of explanation, alternatives, etc.  This page can grow
>>> in the future if necessary.
>>> - Add short messages that point to the doc page in: v3.0.5 download
>>> page, v3.0.5 forum post, gallerymodules.com, and doc pages and forum
>>> posts for the modules themselves.
>>> - Add a routine to Gallery's core that checks active modules against a
>>> hard-coded list to alert the admin, which is called by: upgrader,
>>> admin/modules, and admin/dashboard.  To keep this simple and relatively
>>> unobtrusive, we can skip the site message part (as Chad pointed out, it's
>>> not as high-impact anyway).  The hard-coded list can grow with future
>>> Gallery releases if necessary, too.
>>> - Consider setting up a mailing list to send due diligence in the future.
>>>
>>> Thoughts?
>>>
>>> Take care,
>>> Shad
>>>
>>>
>>> gallery-devel <[email protected]>
>>>
>>> On 20 February 2013 02:56, Chad Kieffer <[email protected]> wrote:
>>>
>>>> Welcome, Shad, and thanks for all the work you've put into Gallery,
>>>> especially on the jQuery update! I agree with focusing on jQuery 1.9
>>>> instead of putting effort into the contributed module front.
>>>>
>>>> I'd add that the type of notice proposed for codex and forum pages be
>>>> added prominently to the downloads page. A message on the upgrader page in
>>>> G3 would have the most visibility, a site status message wouldn't hurt.
>>>>
>>>> The creation of an email list which includes contributed module
>>>> developers (we don't have one, right?) might allow us to send due diligence
>>>> notices for these types of changes in the future.
>>>>
>>>> - Chad
>>>>
>>>>
>>>> On Feb 19, 2013, at 3:52 PM, Shad Laws wrote:
>>>>
>>>> Hey everyone,
>>>>
>>>> I just subscribed to the gallery-devel list.  Hello, everyone!
>>>>
>>>> I agree that spending tons of time policing contributed modules instead
>>>> of wrapping up the jQuery 1.9 update doesn't make much sense.  At the same
>>>> time, if we do nothing, people currently using videos will upgrade their
>>>> core to v3.0.5 and never realize that they're still running hacked v3.0.1
>>>> code for file_proxy and Item_Model, which imho also sounds like a
>>>> bad/dangerous idea.  My thoughts are to:
>>>>
>>>> - add a notice about the deprecation to the release notes and forum
>>>> post for v3.0.5 (I can draft this up - when would you need it by?)
>>>> - edit the codex module pages and forum posts for the deprecated
>>>> modules and point to the notice above
>>>> - (optional) add a bit to the core code that, upon upgrade, checks for
>>>> the old modules and throws up a site message with a warning and a link to
>>>> the notice above
>>>>
>>>> In my opinion, editing the contributed modules themselves wouldn't have
>>>> much of an impact, as the use case I imagine is where the user upgrades the
>>>> core of their existing installation without touching their other modules.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> Shad
>>>>
>>>>
>>>> On 19 February 2013 19:38, Bharat Mediratta <[email protected]> wrote:
>>>>
>>>>> cc'ing gallery-devel for general interest.  We should be having more
>>>>> conversations here, imo.
>>>>>
>>>>> For those on -devel: Shad has done a lot of heavy lifting in the 3.0.5
>>>>> release which is just about ready to go.  His work fixes up movie support
>>>>> considerably and obsoletes several contrib modules which were trying to
>>>>> work around these issues.
>>>>>
>>>>> So the short answer is - we don't do anything.  Reasoning:
>>>>> - We really do care about our users having a nice experience
>>>>> - BUT we have limited time and have to care about the core
>>>>> functionality
>>>>> - if we spend our time policing -contrib modules it slows down release
>>>>> velocity
>>>>> - therefore we must focus on the things that only we can do and let
>>>>> the community do the rest
>>>>>
>>>>> There will be some breakage, the community will react and fix the
>>>>> issues and move on.  In the meantime, we'll have the time to focus on 3.0.6
>>>>> and the jQuery upgrade which is a far more impactful use of our time.
>>>>>
>>>>> That's my rationale for why I'm not doing anything.  If you want to go
>>>>> hack up a couple of one-liners into those modules to check for a specific
>>>>> version of the G3 core and error out, etc - I'll be happy to field the pull
>>>>> requests :-)
>>>>>
>>>>> -Bharat
>>>>>
>>>>>
>>>>> On Tue, Feb 19, 2013 at 5:26 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>>>>>
>>>>>> Hey Bharat,
>>>>>>
>>>>>> One last thought occurs to me re: 3.0.5 - how should we handle
>>>>>> deprecating the old, movie-related contributed modules?
>>>>>>
>>>>>> videos
>>>>>> - functionality: replaced by core core plus my new contributed
>>>>>> "movie_tools" module
>>>>>> - hack level: very high; replaces file_proxy controller, item model,
>>>>>> and movieplayer view (doesn't even use MY_ to extend)
>>>>>> - result of continued use: possibly dangerous or destructive
>>>>>>
>>>>>> noffmpeg
>>>>>> - functionality: replaced by core code
>>>>>> - hack level: moderate; replaces movie helper (like videos, doesn't
>>>>>> use MY_ to extend)
>>>>>> - result of continued use: possibly dangerous, although less likely
>>>>>> than videos
>>>>>>
>>>>>> videothumb
>>>>>> - functionality: not replaced, but doesn't take advantage of new API
>>>>>> changes (and "movie_tools" will do the same job using the new API)
>>>>>> - hack level: mild; gently uses its own controller and events, but
>>>>>> bypasses movie::extract_frame and all of its new enhancements
>>>>>> - result of continued use: can generate incorrect thumbs since it
>>>>>> bypasses movie::extract_frame and its recent DAR fixes, etc.
>>>>>>
>>>>>> videodimensions
>>>>>> - functionality: not replaced, but no longer necessary since movie
>>>>>> player is now auto-resized
>>>>>> - hack level: very low; gently uses its own controller and events
>>>>>> - result of continued use: possible mild data corruption, as users
>>>>>> can write directly to the width and height entries of a movie without
>>>>>> sanity checks
>>>>>>
>>>>>> Take care,
>>>>>> Shad
>>>>>>
>>>>>>
>>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]