Re: [boost] [BPM] Supporting an alternative to meta/libraries.json

Subject: Re: [boost] [BPM] Supporting an alternative to meta/libraries.json
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2016-01-13 10:49:21

On Wed, Jan 6, 2016 at 1:50 PM, Louis Dionne <ldionne.2 <at> gmail.com> wrote:
>
> > Rene Rivera <grafikrobot <at> gmail.com> writes:
> > > On Tue, Jan 5, 2016 at 4:52 PM, Louis Dionne <ldionne.2 <at> gmail.com>
> > wrote:
> > >
> > > > [...]
> > > >
> > > > If there are other uses, could you please elaborate? This is not
> > > > rhetorical; such uses would point out other places that need to be
> > > > changed to accommodate my proposal.
> > > >
> > >
> > > I don't know all of them ATM. Daniel maintains some extra tools that
> > > deal with that file. So he will need to tell us.
> >
> > Ok no problem. Let's hope Daniel sees this thread.
> >
>
> We'll probably need to start another thread so he notices.

I sent him a private email to notify him of the thread.

> [...]
>
> OK, thinking about it more, now that my brain has time.. I think the best I
> can think of is to have the dir be ".boostlib". It directly communicates
> the intended use "Stuff about the Boost library".

I am not strongly attached to the exact name of the directory. I do find that
.boost is prettier, but I don't really care. I'll use .boostlib when preparing
pull requests.

> [...]
>
> > Such a script should be fairly simple to write, but in
> > comparison creating 100+ PRs and merging them would be quite cumbersome.
>
> Note, I would prefer if the script did *everything* needed to do the
> rename. Which means starting from nothing, doing the clones, branch
> switches, renames, commits, and pushes.

Sure, I think that's the best way to go too. I reckon the changes should be
made to the `develop` branches of each library. The changes would then
eventually merged to `master` when preparing the next release.
Is this correct?

> > One
> > problem I see is for those libraries maintained as forks; in this case the
> > original repository would need to be updated, which would require authors
> > to cooperate. But I think all libraries maintained as forks have authors
> > that are around, so it should be doable.
> >
>
> Wouldn't they get merge conflicts and be forced to resolve them?

I guess that would be a viable path too, although it might be better to ask
these authors the permission before applying the changes, for politeness.

What I propose is the following plan:

1. I'll prepare pull requests for the tools that need to be changed. That will
   most likely require Daniel James to give me some input.

2. I'll prepare a script that a release manager can run to apply and commit
   the changes to individual libraries.

3. I'll send an email to this mailing list, explaining what changes are about
   to be rolled out. We should give some time period for people to oppose to
   the changes, if they so desire. Something like 1 week seems reasonable?

4. Once the period is done, if it is clear enough that people are okay with
   this change, a release manager can roll out the changes and merge my pull
   requests on the tools all at once.

Does this plan seem reasonable?

Regards,
Louis