This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: onwards to git


On Thu, Apr 30, 2009 at 11:00 AM, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Apr 30, 2009 at 10:47:43AM -0400, Carlos O'Donell wrote:
>> On Thu, Apr 30, 2009 at 4:46 AM, Thomas Schwinge <tschwinge@gnu.org> wrote:
>> > Just a suggestion from someone who isn't actively using the ports
>> > repository: why not have separate Git repositories for each individual
>> > port, and base these repositories on the [glibc]/master branch? ?Doing
>> > so, the ports maintainers could periodically merge in [glibc]/master into
>> > their ports' branches (which may either be in a separate repository or in
>> > the main glibc repository), and it would also automatically be documented
>> > which port is maintained, which was the last version of [glibc]/master
>> > this port was tested with.
>>
>> I think this would be a great idea.
>
> I think it's just going to make more work for the maintainers of each
> individual port. ?Mostly, they just keep working. ?It'll also be a
> pain for multi-platform distributors like Debian, who will have to do
> the merge anyway.

It wouldn't be any additional work for the maintainers of each
individual port. As a port maintainer I already have to pull down the
latest glibc and test if it broke my local patches and ports changes.
How is this any different? On the contrary, I've made my local process
visible to the public and they can follow along.

Debian would have way less work to do, they would simply split out
glibc per target, download a git snapshot for that target, and build
without doing the integration that has already been done by the target
maintainer. It would be way easier than the current debian nightmare
of collected patches, they could push patches upstream into per-target
trees to fix target-only issues.

I still don't see any downside.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]