On Wed, 2016-03-09 at 09:58 +0100, Laszlo Ersek wrote:
> I disagree. A v1 can be (and very frequently is) applied from patches,
> if it passes review at the first try. When the patches are picked up
> from the list, and all patches get R-b's, then it's the maintainer that
> adds the tags, so the co
On 03/09/16 00:37, David Woodhouse wrote:
> On Wed, 2016-03-09 at 00:05 +0100, Laszlo Ersek wrote:
>> (1) The submitter is himself/herself responsible for picking up review
>> tags, and then for posting a final (fully reviewed) PULL that can be
>> merged without *any* kind of rebase by the pulling
On 9 March 2016 at 07:53, David Woodhouse wrote:
> On Wed, 2016-03-09 at 07:49 +0700, Ard Biesheuvel wrote:
>>
>> I agree that they should be allowed, but i share the concern that
>> merging puts the burden of fixing up conflicts on the maintainer
>> rather than the contributor, who is arguably in
On Wed, 2016-03-09 at 07:49 +0700, Ard Biesheuvel wrote:
>
> I agree that they should be allowed, but i share the concern that
> merging puts the burden of fixing up conflicts on the maintainer
> rather than the contributor, who is arguably in a worse position to
> assess any potential problems on
On 9 March 2016 at 01:17, Laszlo Ersek wrote:
> On 03/08/16 19:09, David Woodhouse wrote:
>> On Tue, 2016-03-08 at 19:00 +0100, Laszlo Ersek wrote:
>
>>> Or do you recommend that contributors be *allowed* to email pull
>>> requests (alongside their patches), and if they do, their pull requests
>>>
On Wed, 2016-03-09 at 00:05 +0100, Laszlo Ersek wrote:
> (1) The submitter is himself/herself responsible for picking up review
> tags, and then for posting a final (fully reviewed) PULL that can be
> merged without *any* kind of rebase by the pulling maintainer.
>
> Corollary: since the first sub
On 03/08/16 19:09, David Woodhouse wrote:
> On Tue, 2016-03-08 at 19:00 +0100, Laszlo Ersek wrote:
>> Or do you recommend that contributors be *allowed* to email pull
>> requests (alongside their patches), and if they do, their pull requests
>> be merged correctly?
>
> Exactly this. They should b
On 03/08/16 19:09, David Woodhouse wrote:
> On Tue, 2016-03-08 at 19:00 +0100, Laszlo Ersek wrote:
>> Or do you recommend that contributors be *allowed* to email pull
>> requests (alongside their patches), and if they do, their pull requests
>> be merged correctly?
>
> Exactly this. They should b
On Tue, 2016-03-08 at 19:00 +0100, Laszlo Ersek wrote:
> It is not about the branch that linus pulls from the subsystem
> maintainer.
>
> It is about the patches that the subsystem maintainer picks up from
> emails of individual contributors.
>
> Let me quote Linus's email back at you:
The bette
On 03/08/16 18:30, Jordan Justen wrote:
> At the subsystem level, I think even the kernel often relies on rebase
> along with format-patch/am to bring in patches rather than merges.
My point exactly.
> I don't think anyone has ruled out considering using merges once
> everyone is more comfortabl
On 03/08/16 18:34, David Woodhouse wrote:
> On Tue, 2016-03-08 at 18:24 +0100, Laszlo Ersek wrote:
>> Here again I can only point to people who I consider my betters -- are
>> you suggesting that the QEMU workflow and the Linux workflow are utterly
>> wrong?
>
> It is not "the Linux workflow". Lin
On Tue, 2016-03-08 at 09:30 -0800, Jordan Justen wrote:
> It sounds like the issue was a lack or gap in testing after the
> rebase.
>
> I don't see that possibility going away just because you instead used
> merge. Especially if you consider resolving merge conflicts or other
> subtle errors that
On Tue, 2016-03-08 at 18:24 +0100, Laszlo Ersek wrote:
> Here again I can only point to people who I consider my betters -- are
> you suggesting that the QEMU workflow and the Linux workflow are utterly
> wrong?
It is not "the Linux workflow". Linus will *eat* you if you rebase
trees which you ask
On 2016-03-08 04:12:32, David Woodhouse wrote:
> As of yesterday, *all* my patches had been merged into OpenSSL HEAD, in
> preparation for the OpenSSL 1.1 Beta 1 release this week.
>
> There is only one more patch outstanding in my OpenSSL git tree.
>
> Do those statements seem self-contradictory
On 03/08/16 17:23, David Woodhouse wrote:
> On Tue, 2016-03-08 at 14:44 +0100, Laszlo Ersek wrote:
>>
>> Using git is one thing, designing a workflow is another thing. Many
>> workflows exist. Some of them are not exclusively merge based (QEMU,
>> various subsystems of Linux), where sub-maintainers
On Tue, 2016-03-08 at 14:44 +0100, Laszlo Ersek wrote:
>
> Using git is one thing, designing a workflow is another thing. Many
> workflows exist. Some of them are not exclusively merge based (QEMU,
> various subsystems of Linux), where sub-maintainers rebase and
> occasionally rework patches that
On 03/08/16 14:25, David Woodhouse wrote:
> On Tue, 2016-03-08 at 14:21 +0100, Laszlo Ersek wrote:
>> As soon as Intel leadership signs off on a merge-oriented workflow,
>> I'll seek to adopt it immediately.
>
> What is this "Intel leadership" of which you speak?
The Intel leadership I speak of a
On Tue, 2016-03-08 at 14:21 +0100, Laszlo Ersek wrote:
> As soon as Intel leadership signs off on a merge-oriented workflow,
> I'll seek to adopt it immediately.
What is this "Intel leadership" of which you speak? I thought the
direction from Intel was that we would move to git (at last).
Nobody
On 03/08/16 13:12, David Woodhouse wrote:
> So please, DO NOT REBASE submissions onto the latest master. Use the
> tools properly as they were designed to be used — put any non-trivial
> work into a tree and send it as a pull request. Sure, send the patches
> to the list for review *too*, but that
As of yesterday, *all* my patches had been merged into OpenSSL HEAD, in
preparation for the OpenSSL 1.1 Beta 1 release this week.
There is only one more patch outstanding in my OpenSSL git tree.
Do those statements seem self-contradictory to you? Well, they're not
quite. The patches *were* merged
20 matches
Mail list logo
