Closure Library fork

[Rhys Brett-Bowen]

Just to bring this out of the touch support thread.

Are people interested in a community driven fork of closure library?
I'd envision a relationship akin to Fedora is to Red Hat where we can
put in more fixes that we're 99% sure about and add new features that
could be tested like touch support or other modules that people would
like to contribute.

Has anyone had experience running a project like this before? Where
should the project be hosted? Who would be happy to help out?

[Andrew Mattie]

I completely understand the need that causes this issue, but running a fork of this project for ingestion reasons concerns me for the health of the community. It's refreshing right now to know that I can pull the trunk into my applications and have a very high likelihood that everything will work just fine. Building my application upon a trusted and solid foundation is more important to me personally than having more features or more code I have to write.

My biggest fear with a community fork is that the overall consistency and quality of Closure Library (CL) will decline if the standard for contributions differs from what it is now. It'd be a shame if a fork, were it to exist, started moving at all in the direction of the jQuery plugin mess that currently exists (or worse, the micro JS junk).

While it does suck that high-quality patches often seem to have delayed ingestion, the patch system itself via Rietveld seems to work nice IMO. What if we just continued to write patches in the way CL proposes now on their Contributors page and then maintain a list of those patches on a page in the wiki? That way a plugin-esque directory can exist while maintaining compatibility with the CL base and while allowing people to pick and choose what patches they want to play with (until they're ingested or rejected overall for strategic reasons).

Would that be a good middle ground?

Andrew

[Guido Tapia]

I personally would not use a community fork of the closure libs, I would have large doubts as to the quality and longevity of the project. Closure libs is actually a really large beast and would require a large amount of work to administer.

Whilst I am also frustrated sometimes by the lack of 'ingestion' (see my list of patches here) I understand the reasons and think this is a small price to pay when compared to the benefits of using a project that is ultimately supported by such a huge dev shop.

I personally maintain my own fork, just so I can use my personal patches in my projects but would not recommend anyone else to use my fork and if you search github you will find a lot of people do the same.

Something that has also been raised in the past is the creation of a 'Contrib' project like googx or something.  This may work, but I also think the quality here would degrade rapidly.  

So whilst I think the frustrations are real and somewhat justified they are also understandable, but I think creating a fork is the wrong way to go about it.

My Solution: Googlers put some more upwards pressure and get some more full time resources on this project including, administrative, documentation, etc, etc. :)  Just look at the amount of 'noise' that yahoo make with YUI.  Google could really leverage this better and make the project pay for it self a bit more.

Anyways, interesting problem, hard solution but lets not fragment this small community.

[Rhys Brett-Bowen]

good points. I'd be curious if there was some form of google internal
roadmap for closure tools as to what plans they have for the toolset
or if changes are just being brought in as the need arises.

On Apr 27, 2:37 pm, Guido Tapia <guido.ta...@gmail.com> wrote:
> I personally would not use a community fork of the closure libs, I would
> have large doubts as to the quality and longevity of the project. Closure
> libs is actually a really large beast and would require a large amount of
> work to administer.
>
> Whilst I am also frustrated sometimes by the lack of 'ingestion' (see my

> list of patches here<http://code.google.com/p/closure-library/issues/list?can=1&q=guido&co...>)

[Nathan Naze]

Hi all,

As others have opined, I'd also hope a full fork would not happen.

While Closure is staffed at Google, our team is primarily tasked with
integrating Closure with projects and infrastructure at Google (web
testing, for example). In particular, we've been assisting in adding
support to projects that predated or didn't previously use Closure.
The library team happens to be a subteam of the Google Web Server --
that is, google.com, which picked up Closure only recently.

Since 2009, we've been pushing all changes (literally thousands)
externally. Our open sourcing happens via MOE [1], which is an
automated system that syncs a canonical version of our internal VCS
with an external repository (in this case,
closure-library.googlecode.com/svn). We do this because we think the
code might be useful to others. Open sourcing also generates
feedback, bug reports, and occasional patches. However, the open
sourcing is not the primary goal of the team.

We've been trying to get a handle on external patches. Part of the
problem has been the external issue tracker, which has, historically,
not been scrubbed and maintained (there is also an internal tracker,
which had, in the past, been the canonical). In the last few weeks,
we have been scrubbing the list and closing/discarding the bugs that
we can. We may also write tools to manage the differences between
trackers. Today, we got through bug 300, and are down to ~160 outside
of the goog.editor component [2].

This is being done in the hopes that we can bring the issue tracker
into our weekly triage and, with it, the outstanding reviews, which
should be of type CodeReview [3]. We cannot take patches from people
who do not go through the CLA process [4], and need to get back to
those folks sooner with instructions.

In any case, I know that a number of patches have not yet been pulled
in, and with the bug scrub, we will be working on getting that as part
of our weekly triage. We have not been doing a good job of this.

As Nick mentioned [5], branching for the sake of maintaining
downstream changes can be a good thing, as we can't immediately get to
patches upstream. I would like to get the review of proposed patches
down to a few weeks -- we won't always take patches or may suggest
alternate implementations (or write our own), but we want to get to
the point of giving a yes/no response quickly.

Beyond that, though, I would really like to see experimentation and
code written with Closure (but not in Closure) developed and shared,
especially when speculative or maturing. There has been a wiki page
dedicated to this [6], but there hasn’t been much uptake. I would like
to see more code go through the route of going through a formative,
experimental stage before being pulled mainline -- some of you may
have noted the goog.labs namespace [7] where we’re experimenting with
new code before graduating from labs.

In any case, happy to hear your thoughts -- I’m thankful for the help
and feedback we’ve gotten so far.

Nathan

[1] http://code.google.com/p/make-open-easy/wiki/MoeIntro
[2] http://code.google.com/p/closure-library/issues/list?can=2&q=-label%3Agoog.editor
[3] http://code.google.com/p/closure-library/issues/list?can=2&q=Type%3DCodeReview+
[4] http://code.google.com/p/closure-library/wiki/Contributors
[5] http://groups.google.com/group/closure-library-discuss/browse_thread/thread/a99a208af511c6e4
[6] http://code.google.com/p/closure-library/wiki/AddtionalLibrariesUsingClosure
[7] http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/labs/

[Michael Bolin]

I am also anti-fork, but I would like to propose that all of the Closure repos switch from SVN to Git so that we external users can maintain our patched versions of Closure more easily.

I have spoken to some Googlers about this before, but for everyone else, I believe the main reasons I have heard for not switching the repos to a DVCS are:

(1) It's a pain to get the existing URLs on code.google.com to continue to work (they may have things like "svn" and "trunk" embedded in them).

(2) People would have to update whatever scripts they use to pull from the existing repos, and existing print documentation (like Closure: The Definitive Guide) would become invalid.

My personal counterargument on these issues is "everyone can just suck it up and deal with it," but I believe others may feel differently / have more mature opinions.

--Michael

[Sarah Allen]

I want to chime in that my +1 to the github repo (on the touch thread) was not in favor of a separately maintained community codebase.  Instead, I believe that git is great for a small group to collaborate on creating and testing a small collection of bug-fixes and features.

I once overheard someone say that with github "fork is the new friend" -- it is in that sense that I would love to see a number of forked repositories where people can collaboratively vet improvements to Closure before the Google folk reel them into the main codebase.

-- Sarah

[John Lenz]

Is there any advantage to having Git be the source of truth over maintaining a canonical Git clone of SVN?

[Chris Henry]

Would git pull still works as expected? It's probably not a big deal though, rietveld patch will still be required before pulling anything anyway. If rietveld were to support diff-ing a pull request on the other hand... hmm.
Chris~

[Andrew Mattie]

I've been using hg subversion (we use Mercurial) to maintain our internal fork with the not-yet-ingested patches. I'll admit I haven't used it, but can't Git users just use git-svn to basically do the same thing?

The only time using DCVS vs SVN has been a pain for me is when I need to submit a patch. It's been far easier to just svn up and copy my work -- since that's essential what ongoing Rietveld issues require me to do anyway -- than to try to make my repo work nicely with the SVN trunk.

Andrew

[Guido Tapia]

-1 for community fork
+1 for git
+2 for github

[Johannes Nel]

In the same vein I was suggesting that a git repos would be easier to branch, in cases like the touch commits (or the bug that existed in canary for a day, this week, around the animation library)

 I am certain that several people on this list have ended up using svn simply because adding closure as an external is the easiest way of dealing with the library, unfortunately we all know what svn branching is like, so can people with vigor, intelligence and leadership do what comes naturally and solve it for plebs like me.

--
j:pn
\\no comment

[adu...@wimm.com]

We've been using Jarib's git-svn repo which gets updated automatically as our "canonical" upstream repo. This has allowed us to apply patches and rebase them on top of head (like Andrew Mattie's drag/touch fixes). It would of course be nice if this was the official mechanism, but in practice it has worked quite well:

https://github.com/jarib/google-closure-library

There is not similar mirror repository that I know of for the templates project, for that we use git-svn internally and have our own git repo that we update only when we pull the most recent code from svn (I wouldn't recommend cloning our closure-templates library for that reason). Doing the git-svn bits manually adds another step, but it's not a huge deal.

-Andy

[Michael Bolin]

John: I could be behind, but last I checked, the latest MOE development was focused on Git rather than SVN, so it might be easier on your end if you moved to Git. Other than that, having a canonical Git mirror would probably be fine, provided that:

(1) Pushes to it were automated so that they always happened alongside MOE pushes to the SVN repo.

(2) It was clear to everyone where the Git source of truth was (another Google Code Hosting project, on github, etc.).

--Michael