Bugzilla – Full Text Bug Listing
| Summary: | [Tips] Request repo in eclipse | ||
|---|---|---|---|
| Product: | Community | Reporter: | Wim Jongman <wim.jongman> |
| Component: | GitHub | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, Lars.Vogel, mikael.barbero, mistria |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 10 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 531784 | ||
|
Description
Wim Jongman
What project is this a part of? -M. part of platform. Adding Lars Vogel, project lead, to authorize this request. Wim, can you clarify the purpose of this repo? Why not using the normal git repo? (In reply to Lars Vogel from comment #4) > Wim, can you clarify the purpose of this repo? Why not using the normal git > repo? This repo contains the tip providers like this: https://github.com/wimjongman/jsontips should not go in any normal repo. Is here to collaborate on tips via pull requests. Fine for me to have such a repo. Dani, WDYT? (In reply to Lars Vogel from comment #6) > Fine for me to have such a repo. Dani, WDYT? I think this needs much more discussion. So far, as you mentioned yourself, all Eclipse SDK stuff is in Eclipse Git repositories. Then, it needs to be discussed what tips are stored in that repository. Just Eclipse SDK tips or also tips for any other project? If the latter, then it must not be owned by the Eclipse top-level project, e.g. by the Foundation. (In reply to comment #7) > (In reply to Lars Vogel from comment #6) > > Fine for me to have such a repo. Dani, WDYT? > > I think this needs much more discussion. So far, as you mentioned yourself, all > Eclipse SDK stuff is in Eclipse Git repositories. Then, it needs to be discussed > what tips are stored in that repository. Just Eclipse SDK tips or also tips for > any other project? If the latter, then it must not be owned by the Eclipse > top-level project, e.g. by the Foundation. For now I have tips for platform and jdt. Other projects may create their own repo or do it in another way. In the future we can merge all tips together or leave them separated. We are totally flexible. (In reply to Wim Jongman from comment #8) > (In reply to comment #7) > > (In reply to Lars Vogel from comment #6) > > > Fine for me to have such a repo. Dani, WDYT? > > > > I think this needs much more discussion. So far, as you mentioned yourself, all > > Eclipse SDK stuff is in Eclipse Git repositories. Then, it needs to be discussed > > what tips are stored in that repository. Just Eclipse SDK tips or also tips for > > any other project? If the latter, then it must not be owned by the Eclipse > > top-level project, e.g. by the Foundation. > > For now I have tips for platform and jdt. > > Other projects may create their own repo or do it in another way. In the > future we can merge all tips together or leave them separated. We are > totally flexible. How does Eclipse find those repos? Where would they be listed? Why can't the current state not be stored in e.g. our common doc repo? (In reply to Dani Megert from comment #9) > How does Eclipse find those repos? The repo will be there for management and testing. With a Jenkins job I will pull in the tips as json files into the download area. > Where would they be listed? The repos would only be listed on Github. Project leads would collaborate on this and other repos that they own themselves. > Why can't the current state not be stored in e.g. our common doc repo? 1. Tips are not text documents but json files and urls 2. I want an isolated repo for better collaboration (clone and pull request) 3. Tips are fluid. Providers can drop and add Tips through the internet. The framework and the intent is all described in this bug [1] and the children of this bug [2]. Please also take a look at [3] [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=307889 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=531784 [3] https://github.com/wimjongman/jsontips He guys, this is the idea of the dynamic json provider. In 20 minutes you get a complete overview of the framework. https://youtu.be/I2N5lCYu4qY Hi Wim, let's start with the common doc repo so that we can continue to use the Gerrit workflow. I think the actual tip(providers) would fit very well in eclipse.platform.common repo together with the user documentation. Is there any technical constraint that would prevent tips from working if they're added there? (In reply to Mickael Istria from comment #13) > I think the actual tip(providers) would fit very well in > eclipse.platform.common repo together with the user documentation. Is there > any technical constraint that would prevent tips from working if they're > added there? Firstly, thanks to all for your feedback! Yes, in fact, there is a technical constraint. Currently, I can directly address GitHub like so [1]. I can also directly access eclipse git repo like so [2] but for Gerrit changes this is not possible. This means that I cannot test a pull request from someone, nor this someone can test their own provider from their own repo (we can redirect the Tips source [3]). (Agreed, people could consume from a Gerrit build result, but in practice, this is not very nice) In addition, GitHub makes it possible to edit in-place. This makes the whole workflow cloud-based and very easy. Especially for this type of content. Let's look at this as an experiment. At any time we can always block direct GitHub access. Looking forward to your +1's! Yours truly, Wim [1] https://raw.githubusercontent.com/wimjongman/jsontips/master/providers.json [2] https://git.eclipse.org/c/platform/eclipse.platform.common.git/plain/bundles/org.eclipse.jdt.doc.isv/about.html [3] -Dorg.eclipse.tips.ide.provider.url=https://raw.githubusercontent.com/wimjongman/jsontips/master/ As Wim the primary developer prefers GitHub, +1 from me. I'm personally worried about it for a few reasons: * it makes 2 repos with same goal (informing users) in 2 different places which makes things harder to maintain. * not sure adding a (GitHub moreover) repo would fit easily in current releng process (aggregator repo) nor that there are free cycles to make sure build can be adapted as necessary in time for M7 or even final build I agree that ability to directly edit files on GitHub would fit well for documentation. And I think it would be interesting to consider moving the documentation repo to GitHub. But that would be another issue. There are other hacks that could be tried for testing content submitted by Gerrit, such as fetching the commit locally and using a file:/ URL. I don't have the impression that the requirement is strong enough to introduce complexity induced by the proposal. My suggestion would be to start with a "minimum viable" approach, which seems to be using the eclipse.platform.common. (In reply to Mickael Istria from comment #16) Ok, too much FUD. I will move to that common repo. (In reply to Wim Jongman from comment #14) > Yes, in fact, there is a technical constraint. Currently, I can directly > address GitHub like so [1]. I can also directly access eclipse git repo like > so [2] but for Gerrit changes this is not possible. While it is possible to get file raw content from bot git and gerrit (see https://git.eclipse.org/r/plugins/gitiles/), webmasters highly recommend not to. Git and gerrit are not file servers. We've experienced high bandwidth usage when Oomph was using git to serve their products catalog. If you need to serve files from eclipse.org to a large audience, make it so from download.eclipse.org. Thanks. (In reply to Mikaël Barbero from comment #18) > > so [2] but for Gerrit changes this is not possible. > > While it is possible to get file raw content from bot git and gerrit (see > https://git.eclipse.org/r/plugins/gitiles/), webmasters highly recommend not > to. Absolutely! Just for local testing. Thanks for the Gerrit pointer. |