Can anyone import trivial changes to libiberty?

Can anyone import trivial changes to libiberty?

[Daniel Jacobowitz]

I just sent a parallel build fix to gcc-patches for libiberty/Makefile.in
and it was approved.  Does that mean I can commit it to the main sources
repository too, or should I leave it to whoever handles merges?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Can anyone import trivial changes to libiberty?

[Daniel Berlin]

Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:

> I just sent a parallel build fix to gcc-patches for libiberty/Makefile.in
> and it was approved.  Does that mean I can commit it to the main sources
> repository too, or should I leave it to whoever handles merges?

You are *supposed* to commit to both at once.
In practice, sometimes people forget.
Merges don't occur all that often. They usually occur when someone
notices something they needed in one but not the other, and that
they've gotten out of sync. 
At least, this is my experience.
--Dan

-- 
"When I go, I'm flying Air Bizarre.  It's a good airline.  You
buy a one way round trip ticket.  You leave any Monday, and they
bring you back the previous Friday...  That way you still have
the weekend.
"-Steven Wright

Re: Can anyone import trivial changes to libiberty?

[Daniel Berlin]

DJ Delorie <dj@redhat.com> writes:

> Actually, this all changed when I took over libiberty.  My machine has
> a cron job that runs hourly and looks for needed merges, and writes a
> script that does all the work for me.  I just review the script and
> run it when I get the email.  The libiberties have been in 100% sync
> since I started doing this.
Coolness.

> 
> Specific comments follow.
> 
>> You are *supposed* to commit to both at once.
> 
> You are *allowed* to.  You should if you can.  If you don't, or do it
> wrong, the automerge picks up the difference.
> 
> *Anyone* may merge any patch from gcc to other libiberty repositories
> if they can't wait for the automerge, even if it's not their patch.
> However, *nobody* can commit to non-gcc libiberties until after it's
> committed to gcc (otherwise my scripts get confused, and it's a bad
> idea anyway).
Right.
This much i knew.

> 
>> In practice, sometimes people forget.
> 
> Or can't check in to other repositories.
Forgot about that.

> 
>> Merges don't occur all that often. They usually occur when someone
>> notices something they needed in one but not the other, and that
>> they've gotten out of sync.
> 
> They happen hourly now.  Or, it checks hourly, and I commit it next
> time I sit down at the computer ;-)


> 
>> At least, this is my experience.
> 
> Hopefully, we'll all have better experiences now.
Good experiences are well, good.
:)

-- 
"I was reading the dictionary.  I thought it was a poem about
everything.
"-Steven Wright

Re: Can anyone import trivial changes to libiberty?

[Andrew Cagney]

> I just sent a parallel build fix to gcc-patches for libiberty/Makefile.in
> and it was approved.  Does that mean I can commit it to the main sources
> repository too, or should I leave it to whoever handles merges?


I _think_ the merge process was recently automated.  DJ?  (If it has 
then src/MAINTAINERS could do with an update).

	Andrew

Re: Can anyone import trivial changes to libiberty?

[DJ Delorie]

> > I just sent a parallel build fix to gcc-patches for libiberty/Makefile.in
> > and it was approved.  Does that mean I can commit it to the main sources
> > repository too, or should I leave it to whoever handles merges?
> 
> I _think_ the merge process was recently automated.  DJ?  (If it has 
> then src/MAINTAINERS could do with an update).

It's semi-automated.  If you want to commit to multiple places once
it's approved for gcc, go ahead.  Otherwise, I've got a cron job that
does everything but the final checkin for merging (and it writes me a
script for the final checkin too).  In fact, I just ran that, so it's
merged.

I'll add yet another note to src/MAINTAINERS about the auto-merge
process.