Community
Participate
Working Groups
The main goal of the solution is to promote the development of the release. When someone during the milestone comes up with the idea about some new, interesting feature for Eclipse then they can provide proper entry to the proposed WIKI. The N&N however can have some "new feature proposal available" icon and proper link to the WIKI. The feature has to be provided in the installable form from the external site, i.e. Eclipse Market or Git Hub. When feature is stable enough and accepted by the users it can be merged to the master Git repository. Additionally the WIKI page and indirectly the N&N one can contain the link to the Bugzilla or blog where the new feature get deeply discussed. When we agree to go with it we have to figure out the way of filtering the craps that can be published from time to time. However I think, we can postpone it till a first crap What can we achieve by this solution? * incoming release can be earlier announced by the blog entries dedicated to the new features and it can encourage the new people from the Community for helping with the development of the new release as well as the users for switching to Eclipse as the primary IDE or RCP platform * new interesting architectural/design changes can be proposed with the features. It will be real prove of concept and not only "raw" idea sent via e-mail * some really strong Eclipse developers/consultants can find the idea interesting and help with development of the new release * during implementation of the new feature you have to quite often fix some defects that block the feature or get exposed by it, what indirectly improves the quality of Eclipse * current solution - announcing the new ideas by mailing list - is not sufficient in my opinion. Some ideas finish with several discussion e-mails. Even when something get implemented it can be forgotten in the moment. Having the persisted list with the feature proposals on WIKI that is connected to N&N page, better visible than the mailing list archive, seems to be better solution in my opinion Please let me know what do you think about the proposal, Daniel
I think that having a switch in Eclipse SDK to see beta features would be nice. It could be either a cli param or better a setting in Eclipse SDK. In the same time we should not pollute the master code with beta features. I think we could solve the issues on the releng level. If there is a beta feature in some bundle, the Eclipse SDK would contain two versions of it. The stable one and the beta one. Stable bundles would be built from master and beta bundles from another dedicated branch. The beta switch would switch the set of bundles running withing Eclipse SDK.
(In reply to Szymon Brandys from comment #1) > I think that having a switch in Eclipse SDK to see beta features would be > nice. It could be either a cli param or better a setting in Eclipse SDK. In > the same time we should not pollute the master code with beta features. > > I think we could solve the issues on the releng level. If there is a beta > feature in some bundle, the Eclipse SDK would contain two versions of it. > The stable one and the beta one. Stable bundles would be built from master > and beta bundles from another dedicated branch. > > The beta switch would switch the set of bundles running withing Eclipse SDK. You got it wrong. There won't be any beta code in the repo. The code must be outside Eclipse, e.g. in the Market Place. The new thing is that this can be advertised in the N&N via a new wiki.
(In reply to Dani Megert from comment #2) > You got it wrong. There won't be any beta code in the repo. The code must be > outside Eclipse, e.g. in the Market Place. The new thing is that this can be > advertised in the N&N via a new wiki. I understand the Daniel's idea. What I suggested is a completely new thing. I am suggesting to add one switch to enter 'beta' mode. IMO It would be easier for people to just switch to use 'beta' features and see them all instead of installing them one by one from Market or somewhere. The 'beta' mode could be also used for suggesting new defaults in settings. Then we could gather feedback from users about the changes what can help to decide what should be introduced and what should not. I can imagine that when you enter regular Eclipse, you get a prompt asking if you want to test 'beta' features. It could be a fancy prompt showing what is new. If one decides to switch, he could get a prompt after some time asking for feedback and offering an option to switch back etc. The option to switch between modes should be also easily available somewhere in Eclipse. This is something used across desktop and web solutions already and IMO it works quite well there.
(In reply to Szymon Brandys from comment #3) > (In reply to Dani Megert from comment #2) > > You got it wrong. There won't be any beta code in the repo. The code must be > > outside Eclipse, e.g. in the Market Place. The new thing is that this can be > > advertised in the N&N via a new wiki. > > I understand the Daniel's idea. What I suggested is a completely new thing. > > I am suggesting to add one switch to enter 'beta' mode. IMO It would be > easier for people to just switch to use 'beta' features and see them all > instead of installing them one by one from Market or somewhere. The 'beta' > mode could be also used for suggesting new defaults in settings. Then we > could gather feedback from users about the changes what can help to decide > what should be introduced and what should not. > > I can imagine that when you enter regular Eclipse, you get a prompt asking > if you want to test 'beta' features. It could be a fancy prompt showing what > is new. If one decides to switch, he could get a prompt after some time > asking for feedback and offering an option to switch back etc. The option to > switch between modes should be also easily available somewhere in Eclipse. > > This is something used across desktop and web solutions already and IMO it > works quite well there. Let's keep this bug focused on the original idea. Our milestones must be stable and not contain beta stuff.
(In reply to Szymon Brandys from comment #3) > (In reply to Dani Megert from comment #2) > > You got it wrong. There won't be any beta code in the repo. The code must be > > outside Eclipse, e.g. in the Market Place. The new thing is that this can be > > advertised in the N&N via a new wiki. > > I understand the Daniel's idea. What I suggested is a completely new thing. > > I am suggesting to add one switch to enter 'beta' mode. IMO It would be > easier for people to just switch to use 'beta' features and see them all > instead of installing them one by one from Market or somewhere. The 'beta' > mode could be also used for suggesting new defaults in settings. Then we > could gather feedback from users about the changes what can help to decide > what should be introduced and what should not. > > I can imagine that when you enter regular Eclipse, you get a prompt asking > if you want to test 'beta' features. It could be a fancy prompt showing what > is new. If one decides to switch, he could get a prompt after some time > asking for feedback and offering an option to switch back etc. The option to > switch between modes should be also easily available somewhere in Eclipse. > > This is something used across desktop and web solutions already and IMO it > works quite well there. For me the idea is also very interesting, but for now the original solution seems to be more suitable, I think. The huge benefit that I see with the new approach is a possibility of "safe" refactoring of the source code. For instance we can switch the IDE for using the new E4 progress view and ask the users whether it is fine for them basing on their feedback. I think we can consider it as the 2nd step after applying the original idea Daniel Daniel
Can we define any rules for this bug saying when it can be closed? Do we need approvals from everybody on the CC list or we can just wait 1 - 2 weeks for the comments and when there is no "-1" comment then we can go with the solution? thanks, Daniel
(In reply to Daniel Rolka from comment #6) > Can we define any rules for this bug saying when it can be closed? Do we > need approvals from everybody on the CC list or we can just wait 1 - 2 weeks > for the comments and when there is no "-1" comment then we can go with the > solution? > > thanks, > Daniel We usually wait for a week. Next week's meeting is a good time for the final go / no go.
We will try this in M2. Daniel, please kick it off.
I've reopened the bug since I want to attach the link to the new WIKI when it is ready Daniel
