Re: [Gallery3] Wrapping up 3.0.5

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 ]