Aliens invadiram a lista de discussão do kernel
- por Sergio Prado
Pelo menos é o que acreditam alguns desenvolvedores do kernel.
Acontece que uma pessoa chamada Nicholas Krause vem “trollando” a lista de discussão do kernel há mais de 10 dias, enviando alguns patches inúteis e sem sentido!
Que tal juntar duas linhas em uma só?
This joins two lines that need to be joined as this improves the coding style and makes it much easier to read. Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- drivers/staging/bcm/InterfaceIdleMode.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/bcm/InterfaceIdleMode.c b/drivers/staging/bcm/InterfaceIdleMode.c index c84ee49..e075f0e 100644 --- a/drivers/staging/bcm/InterfaceIdleMode.c +++ b/drivers/staging/bcm/InterfaceIdleMode.c @@ -211,8 +211,7 @@ static int InterfaceAbortIdlemode(struct bcm_mini_adapter *Adapter, else BCM_DEBUG_PRINT(Adapter, DBG_TYPE_OTHERS, IDLE_MODE, DBG_LVL_ALL, - "Number of completed iteration to" - "read chip-id :%lu", itr); + "Number of completed iteration to read chip-id :%lu", itr); status = wrmalt(Adapter, SW_ABORT_IDLEMODE_LOC, &Pattern, sizeof(status)); |
Ou então adicionar uma linha em branco?
This patch adds a blank line after line 708 as declared when running checkpatch on this file. Signed-off-by: Nicholas Krause <xerofoify@gmail.com> --- drivers/staging/android/sync.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index e7b2e02..0d37495 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -705,6 +705,7 @@ static long sync_fence_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { struct sync_fence *fence = file->private_data; + switch (cmd) { case SYNC_IOC_WAIT: return sync_fence_ioctl_wait(fence, arg); |
Parece brincadeira, mas não é. O que tem irritado muitos desenvolvedores, como Dave Airle:
“Nick has decided he wants to be a kernel developer, a laudable goal. He however has decided not to take any advice given to me by a number of other kernel developers on how to work on the kernel. So instead he sends random broken patches to random subsystems in the hope that one will slip past a sleepy maintainer and end up in the kernel. He isn’t willing to spend his own time learning anything, he is expecting that kernel developers want to spoon feed someone who sends them broken patches. We’ve asked him to stop, he keeps doing it, then when caught out apologizes with something along the lines, of I’m trying to learn, “idiot mistake”, despite having been told to take a step back and try and learn how the kernel works. Now we have to waste more maintainer time making sure nobody accidentally merges anything he sends.”
E Theodore Ts’o:
“So far, he has tried to do this with the ext4, btrfs, scsi, and usb subsystems. I’m probably missing a few. I suspect he’s jumping around to different subsystems hoping to find one where his reputation hasn’t been blackened yet by his refusal to deeply understand kernel code (or to test to see if it compiles, never mind trying to boot a kernel with that patch and exercise the modified code) before starting to try to help.”
Alguns acreditam que ele esteja escrevendo uma tese sobre as consequências de “trollar” uma lista de discussão, ou então ver se alguns de seus patches passam pelos mantenedores. Outras acreditam que seja a NSA.
Mas provavelmente ele deve ser apenas um estudante, cheio de energia e com vontade de colaborar, porém sem ainda a competência ou orientação necessária sobre como funciona o processo de colaboração do kernel.
De qualquer forma, não deixa de ser engraçado. :)
Sergio Prado
Sem Comentários
Nenhum comentário até agora... é a sua chance de ser o primeiro a comentar!