I actually like the idea of using GitHub forks for (not very short-lived) experiments with changes to other projects' code.
We'd still need a home for the code for our direct artifacts, and an organizational roof for the project. I still think that E4 makes the most sense for this. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Mickael Istria > Sent: Thursday, July 6, 2017 3:34 PM > To: E4 Project developer mailing list <[email protected]> > Subject: Re: [e4-dev] Sandbox for Eclipse proposal as E4 sub-project > > > > On Thu, Jul 6, 2017 at 3:29 PM, Carsten Reckord <[email protected] > <mailto:[email protected]> > wrote: > > > What's going to be interesting is how to deal with cases where > that's not a given - i.e. where we don't know the best way yet and have to > try out a few things, or where the change is more controversial and first > has to prove itself. I think hosting intermediary code, staging private > builds of some Platform or other external bundles based on Gerrit changes > (or even doing temporary forks) can play a role there. > > > Rather than coding on a separate repo wouldn't using a fork on GitHub be > better ? > > There's the eclipselabs organization at GitHub, we can place a fork of > Platform UI and Platform Text and let you be a committer on those so you > can create branches and so on. It wouldn't make things harder to work > with, and it would more easily allow to consume latest Platform change and > merge back interesting parts. > > Or maybe there's a good way for Platform to provide "experimental" Git > repositories for non-committers? _______________________________________________ e4-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/e4-dev
