Re: [Gallery3] Wrapping up 3.0.5

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 ]