It sounds like you are on a very good track. My suggestion is that you resolve all outstanding release train requirements, create an update site for snapshot builds and participate in a few Juno milestones to establish a release process and give users an opportunity to try R4E. Once all of that is in place and working and there is integration with other Mylyn components I'd be a very good time to discuss making R4E available from the main Mylyn repository again. Regardless of that, you can always participate in Mylyn (or Eclipse) releases in the sense that you can make compatible releases available at the same time that Mylyn is released and we'd be happy to link the R4E noteworthy from the Mylyn website to make users aware. I have pasted some additional thoughts below.
On Tue, Oct 18, 2011 at 4:13 PM, Alvaro Sanchez <[email protected]> wrote: > We are scheduled to participate in Eclipsecon Europe 2011, this will > be a good opportunity to show the existing capabilities, and future > plans to interested users. > > R4Eclipse has not been released yet and the publicity has been > limited. This shall change as we move to our fist release. > e.g. News and Noteworthy shall be created as we start producing > regular releases. I'd strongly recommend to make snapshot releases available early and often (i.e. as soon as the tooling is consumable by users). Snapshot releases are a great opportunity to validate workflows and new functionality before making it available in actual releases. Users have high quality expectations of Eclipse releases and if releases aren't sufficiently polished there is a risk that users are turned away from a project for a long time. Feedback from demo camps and such is useful but it's even more valuable to get users to actually install and use the tools. That's the type of feedback that can give you a much better sense what the important impediments are that should be addressed before a release. >> This initial feedback from early adopters is particular important to >> work out common installation and compatibility issues. We make an >> effort to run automated tests in a number of environments and >> encourage committers to bootstrap on a variety of configurations. >> Still, we can only ever capture a fraction of the configurations that >> are deployed in the real world and rely on the community to validate >> builds before distributing releases to a larger audience and less >> experienced users. >> > Agree, the proposal to include R4E in a first release within Mylyn 3.7 > will allow us to provide a realistic installation environment with all > dependencies available in the same site. Once we publish something on the Mylyn release site users have (and should have) the expectation that the published features will work and install into their environment. I don't want to risk that trust by making components available from the main update site that haven't seen a sufficient level of validation. Basically, I would like to see that validation happen before stuff moves to the Mylyn site and not as part of making stuff available on the Mylyn site. You can easily create a composite site that aggregates the Mylyn site and the R4E site to provide users with a seamless install experience that is exactly the same as installing directly from the Mylyn site. > I see the problem, we can leave the Subclipse connector out of the > Mylyn Versions release for the time being. > would the Eclipse Market place be a suitable place to offer an > update site for the Subclipse connector and dependencies ?? Yes, a Marketplace listing that points to a repository with all required dependencies could be a very good option to publish the connector. Steffen -- Steffen Pingel Committer, http://eclipse.org/mylyn Senior Developer, http://tasktop.com _______________________________________________ mylyn-integrators mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
