[Bug 457343] Review Request: jquery - Fast, concise library that simplifies how you use javascript

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=457343

--- Comment #9 from Toshio Ernie Kuratomi <a.badger at gmail.com> 2011-08-19 12:37:41 EDT ---
(In reply to comment #8)
> I would like to take over if I can figure out how to solve the Sizzle "problem"

Like I say, I'm not using jquery now so I don't know the extent of the sizzle
problem.  Does jquery actually require sizzle?  Is it something that gets
included into jquery when jquery is "built"?  Need more information here....
> 
> 2) The static linking idea is interesting, but I guess we then might as well
> just leave the "original" bundled jquery in the package to be sure it works as
> the developers intended.
> 
What "static linking" adds is the ability to track what libraries (and
depending on the actual deps that we use, also their versions) are being used
by an application.  That way if foo was using jquery-1.0 and jquery-1.1 is
released that fixes an issue (security, major bugfix, change to a more
permissive license, etc) found in jquery-1.0 we'd know what software was using
the old jquery and be able to rebuild them with the new version.

> 3) Maybe somehow all versions can be made available in the package?
> 
> - The jquery package can just contain the minified versions of all jquery
> versions ever released (like what is available on the Google CDN)? 

It would probably be good to have both minified and "source" versions
installed.  GPL compliance would make this a requirement for some libraries...
(possibly if it was the app was GPL although I'm very unclear on this.)

> - Or maybe have two packages. The jquery package (containing only the latest
> version) and a compat-jquery package (containing all? the previous versions)?
> - Or implement a CDN api like Google for JS containing all jquery (and other js
> libs) versions?
> 
Yeah -- I think we should have multiple packages.  whether that's one for the
current version and one for all older versions or one for each older version
I'm not sure.  And how to set those up internally I'm not sure.

> 4) It would be interesting to pull jquery from git and build it locally (using
> the Makefile). This pulls in Sizzle and Qunit from git. Possibly something can
> be done there to unbundle? Furthermore it would require nodejs (not packaged
> yet?) to minify jquery...
> 
Hmm... If jquery is being shipped minified, we'd have to create that minified
version from the source version no matter what.

nodejs was under review but Lubomir seems to have disappeared:
https://bugzilla.redhat.com/show_bug.cgi?id=634911


> 5) It seems to be impossible to test all software after upgrading jquery to a
> newer version (see jquery 1.6.1 .attr() problem for instance). Should there be
> test procedures? updates-testing is time enough for package maintainers/users
> to check software against the latest version of jquery? How to avoid negative
> karma if stuff breaks? :)
> 
I don't see us being more strict than with other libraries from other
languages.  So, probably, be conservative in upgrading the library in older
releases.  Use updates-testing.  Check software as best we can, etc, etc.

> 6) How to fix all local copies of jquery in packages from being used? Use a
> (Apache) rewrite rule that redirects all */jquery*.js calls to /js/jquery.js?
> :-)

Review and fix.  Someone could check for files named jquery in the yum
repository repodata to generate that list.  This would be something to do
after/if guidelines specifying how to package javascript libraries are
approved.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.