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
>
>

Reply via email to