Thank you, I appreciate it. The list of gbuild modules is in main/Module_ooo.mk. The rest are using dmake. The next one I expect to port is main/jurt, and that will be a substantial patch.
Will our release process keep testing trunk until it's ready, then make a branch of it to use for the release? If necessary I can work on modules offline or in another branch, then commit or merge them back when the release is over. On Wed, Apr 4, 2018 at 3:06 PM, Jim Jagielski <j...@jagunet.com> wrote: > > > > On Apr 4, 2018, at 9:01 AM, Jim Jagielski <j...@jagunet.com> wrote: > > > > > > I will start another thread on the gbuild topic... > > > > First and foremost, I am incredibly impressed with the work > being done on the gbuild migration. I really am. > > However, and there's always a "however", there must come > a time where we "hold the line" on migration in hopes of getting > a 4.2.0 out. As such, I think some sort of plan might be due > (and apologies if we have such a documented plan already > in place)... > > Does it make sense to spend time to list modules that still > need that migration and then prioritize them? As well as > create a policy such that all "new and updated" modules > must use gbuild but for existing modules, "if it ain't broke, > don't fix it"? > > I'm not trying to stifle the migration, it's just that it appears > to me that we need better management about it. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
