30 Apr 2012 7:42 PM #1
Public ExtJS github repository!
I may be living in a fantasy world, but how awesome would it be if Sencha set up a public github repo for extjs?
As my library of "It really should work like this" and "I don't believe this code ever worked" overrides grows ever larger and more unwieldy, It occurs to me that there are probably plenty of devs out there doing the same thing. Wouldn't it be sweet it we could fork and submit pull requests, whereupon maintainers could opt to either savagely heap their scorn, or gleefully accept the free labor?
I assume the legal vultures would poo-poo this of course, but I for one would gladly relinquish all copyright bla bla bla, and even continue to pay for support / licences. Why? because it beats the hell out of waiting for bugfixes, and maintaining a leaning tower of overrides in perpetuity.
1 May 2012 5:32 AM #2
- Join Date
- Mar 2007
- Gainesville, FL
- Vote Rating
We sell support subscriptions and that would be a bit of a mess. Plus reviewing PRs would take up a lot of our time not allowing us to develop.Mitchell Simoens @LikelyMitch
Sencha Inc, Senior Software Engineer
Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/
Need more help with your app? Hire Sencha Services email@example.com
Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!
When posting code, please use BBCode's CODE tags.
1 May 2012 10:52 AM #3
Regarding support subscriptions: ExtJs is already opensource, for non-commercial use anyway.
Were Sencha to push only public releases to the public repo, then viola! No disclosure of hotfix or other private code, and accepted user-contributed patches could be pulled into the "official" private version of the repo for benefit of the next public release as appropriate.
The object of the game should be to get the users involved, especially as it pertains to real-world use cases and the patches/changes they necessitate. Sencha is not in the business of writing applications, but of writing and supporting tools to write applications. As such, internally conjuring sufficient real-world use-cases to ensure robustness of the library is difficult. This necessarily biases sencha toward certain (usually minor, but material) contrivances in the code that could benefit from some outside perspective. This is why I feel it's important to emphasize the dearth of official avenues by which users can propose specific modifications.
Certainly it could spawn a lot of pull requests, but I reckon it'd be a heck of a lot better to sift through those than all the (lost/forgotten) bug tickets to the same effect. Sure, it's easier to just pretend the feedback doesn't exist, but ignoring it will only cause devs to get frustrated.
Listen to your users. We like you! otherwise we wouldn't be here.
21 May 2012 4:23 AM #4
Having a public GitHub repo where you push only the official releases would ensure:
- the official release gets a "version number", so that a simple diff/patch is always exact and very fast to check.
- it encourages fixes from the community - in Ext itself but in the examples and UX too. Right now most "solutions" are Forum snippets taken out from the context with a very high effort to track, test, check and later also to follow.
This would also explain why so few users contribute, or why many of the contributions in the forums get lost or after a while diverge much to much to be usable - just take a look at the many UX examples.
You control the master, so you decide what to pull from others.
Also your public repo must not be a mirror of your internal one, but just periodic pushes when a release is made - so do many companies, and it's less, not more work.
21 May 2012 9:57 AM #5
Even Ed seemed to be receptive to this possibility... two years ago!
If we get demand for a github repository featuring just the public releases we may set that up too.
Rabble rabble rabble rabble
2 Sep 2013 6:08 AM #6
My growing collection of EXT JS overrides is getting painful to maintain. It would be really cool to have a public EXTJS repo which allows me create branches with my overrides and build a customer version of EXTJS. Plus, when EXTJS upgrades become available, it would be much easier to see if and how I need to adjust my overrides.
I realize it's been a while since this request was posted. Has any progress been made in this direction?
6 Sep 2013 7:08 AM #7
6 Sep 2013 7:47 AM #8
Ohh, then I missed 99 of these discussions. :-) But good to know that others have the same need. What is the state of discussion then?
6 Sep 2013 2:34 PM #9
Having harped on this issue with various persons at various times, it is becoming increasingly clear, despite some overtures to the contrary, that Sencha is not interested in this kind of community interaction.
This is a shame, because Sencha is by their very nature a tool-maker, and is pretty good at it too... but they absolutely cannot be in the trenches on a day-to-day-basis as a tool-user. This is evidenced by my rather large library of patches required to make ExtJS work for my application at all. (complexities for which dataIndex is unsatisfactory, the ability to render more than one instance of an MVC view/controller pair, etc, etc, etc) My company would be happy to surrender the copyrights for these patches, but there's no mechanism to contribute them upstream. Yes, there's the "feature request" process, but that's not a good fit for the "this bit needs some re-architecting" scenario.
From my perspective, Sencha is rightly concerned with thought-leadership. This is a good thing in many ways. *But* without a significantly improved mechanism for user contribution and feedback, Sencha dwells in the echo-chamber, and runs the risk of having companies like mine abandon the platform.
12 Sep 2013 11:46 PM #10
If we say, that handling such repository isn't complex, then we should demonstrate this. Looks like nothing prevents us from creating a repo, accept community (our) patches and merge GA releases from Sencha.
If we will be able to maintain such a repo for while and proof its usefulness, then, possibly, Sencha will take part in it.
What are your thoughts about this approach?
From my point of view, there is a problem with api changes. The public version must not differ or it will lose it's roots.
Thread Participants: 23
- firstname.lastname@example.org (1 Post)
- dawesi (3 Posts)
- austin (1 Post)
- seade (1 Post)
- lorezyra (3 Posts)
- mitchellsimoens (5 Posts)
- andong (2 Posts)
- themightychris (1 Post)
- Scorpie (1 Post)
- abe.elias (1 Post)
- Max_nl (3 Posts)
- HOJ (1 Post)
- g.sidler (3 Posts)
- email@example.com (1 Post)
- abierbaum (1 Post)
- fdp (2 Posts)
- danielhugo (1 Post)
- ettavolt (1 Post)
- olecom (4 Posts)
- brian428 (3 Posts)
- Misiu (1 Post)
- richiejaeger (1 Post)
- Glatzmatz (1 Post)