[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in proposal
From: |
Thomas Lord |
Subject: |
Re: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in proposal |
Date: |
Mon, 1 Nov 2004 17:54:54 -0800 (PST) |
> From: Samuel Tardieu <address@hidden>
> Thomas> Submission branches are (revisioned) changesets against a
> Thomas> well-defined mainline. That implies some constraints on how a
> Thomas> submission branch is sanely used. If they want something that
> Thomas> is 'mainling + some-unmerged-submission-branches' they can
> Thomas> constuct such an entity by paying attention to '=merges'.
> Tom, you usually pay high attention to design and details. Does this
> really look like an efficient process to you? To me, it looks like you
> impose a very heavy process to tla developers which discourages
> experiments, as forks[1] from tla will have a very hard time keeping
> up with already merged submission branches.
Submission branches should make forks which cerrypick features not yet
merged into mainline should be /easier/, not harder to maintain.
-t
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Thomas Lord, 2004/11/01
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Matthew Dempsky, 2004/11/01
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Thomas Lord, 2004/11/01
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Yann Droneaud, 2004/11/01
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Thomas Lord, 2004/11/02
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Yann Droneaud, 2004/11/08
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Matthew Dempsky, 2004/11/11
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Stephen J. Turnbull, 2004/11/12