Re: [Gallery3] Wrapping up 3.0.5
Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> Thu, 21 Feb 2013 12:49:13 +0100
| Newsgroups | gmane.comp.web.gallery.devel |
|---|---|
| Message-ID | <CA+z51A5dXBYGnNgwicUZb1vKZfJeRTED_OJjW7-_7wSoSW=4+g@mail.gmail.com> |
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 ]