Re: [aur-general] [PRQ#37061] Deletion Request for taskfile-gotask-git
(resending as I was not subscribed to aur-general before)
It tab-completes very great. And even earlier than in your version.
Only if you remember it starts with a 'g', instead of the original 't'. If you're following official documentation and trying to use 'task' and wondering why it's red and not found, tab-complete will save you there.
Moreover, before making this package happen I was speaking with original maintainer via email, and he declines binary renaming "because docs says it's task". Moreover I agree with Egor - why should we change names to make a mess in user's brains while reading documentation?
Because the alternative is making the package conflict with `task`, so one cannot have both installed on the system. That is worse. The user is free to setup an alias to use 'task' as per the documentation if they do not also use community/task.
As I can see, you've just picked up this package and "fixed" it without even trying to contact me and filed a deletion request for package that fixes problem in more proper way (using org's name).
The package did not download, was out of date, did not build, conflicted with [community], had missing completions (still does for fish/ps to be honest) and had a wrong license. The proper way to deal with those is not creating yet another AUR package, the proper way is to fix the existing one, which I have done, and then noticed you duplicated the package, hence I filed this deletion request.
Again, I'm asking to reconsider and withdraw/deny this request.
https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi... See second rule here, your package at this point is just naming the binary differently, which is just pointless duplication, let's rather reach consensus on what it should be named as. Maybe this entire issue should perhaps be raised upstream as 'task' is very generic. Taskwarrior started in 2008 and task in 2017. Though I doubt anything useful would come of it. Anyway the options are - A) go-task B) task-go C) keep task and conflict with community/task D) Something else Martin On Mon, Aug 22, 2022 at 3:02 PM Martin Rys <spleefer90@gmail.com> wrote:
It tab-completes very great. And even earlier than in your version.
Only if you remember it starts with a 'g', instead of the original 't'. If you're following official documentation and trying to use 'task' and wondering why it's red and not found, tab-complete will save you there.
Moreover, before making this package happen I was speaking with original maintainer via email, and he declines binary renaming "because docs says it's task". Moreover I agree with Egor - why should we change names to make a mess in user's brains while reading documentation?
Because the alternative is making the package conflict with `task`, so one cannot have both installed on the system. That is worse. The user is free to setup an alias to use 'task' as per the documentation if they do not also use community/task.
As I can see, you've just picked up this package and "fixed" it without even trying to contact me and filed a deletion request for package that fixes problem in more proper way (using org's name).
The package did not download, was out of date, did not build, conflicted with [community], had missing completions (still does for fish/ps to be honest) and had a wrong license.
The proper way to deal with those is not creating yet another AUR package, the proper way is to fix the existing one, which I have done, and then noticed you duplicated the package, hence I filed this deletion request.
Again, I'm asking to reconsider and withdraw/deny this request.
https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi... See second rule here, your package at this point is just naming the binary differently, which is just pointless duplication, let's rather reach consensus on what it should be named as.
Maybe this entire issue should perhaps be raised upstream as 'task' is very generic. Taskwarrior started in 2008 and task in 2017. Though I doubt anything useful would come of it.
Anyway the options are - A) go-task B) task-go C) keep task and conflict with community/task D) Something else
Martin
It tab-completes very great. And even earlier than in your version.
Only if you remember it starts with a 'g', instead of the original 't'. If you're following official documentation and trying to use 'task' and wondering why it's red and not found, tab-complete will save you there.
It will autocomplete to taskwarrior first. That might be greater problem with UX.
Moreover, before making this package happen I was speaking with original maintainer via email, and he declines binary renaming "because docs says it's task". Moreover I agree with Egor - why should we change names to make a mess in user's brains while reading documentation?
Because the alternative is making the package conflict with `task`, so one cannot have both installed on the system. That is worse. The user is free to setup an alias to use 'task' as per the documentation if they do not also use community/task.
Users will expect "taskfile-git" to behave just like written in docs, so "task" should be a command for that package. That was original maintainer's intention.
As I can see, you've just picked up this package and "fixed" it without even trying to contact me and filed a deletion request for package that fixes problem in more proper way (using org's name).
The package did not download, was out of date, did not build, conflicted with [community], had missing completions (still does for fish/ps to be honest) and had a wrong license.
The proper way to deal with those is not creating yet another AUR package, the proper way is to fix the existing one, which I have done, and then noticed you duplicated the package, hence I filed this deletion request.
So we should expect deletion requests for all these packages, right? https://aur.archlinux.org/packages?O=0&SeB=nd&K=go-task&outdated=&SB=p&SO=d&PP=50&submit=Go
Again, I'm asking to reconsider and withdraw/deny this request.
https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi... See second rule here, your package at this point is just naming the binary differently, which is just pointless duplication, let's rather reach consensus on what it should be named as.
Which CONFORMS second rule, because package on time of submission was up to date BUT maintainer REFUSES to change resulting binary's name in sake of UX. Can't blame him for that.
Maybe this entire issue should perhaps be raised upstream as 'task' is very generic. Taskwarrior started in 2008 and task in 2017. Though I doubt anything useful would come of it.
https://github.com/go-task/task/issues/697 for homebrew tap, yet same can be extrapolated on other platforms too. They don't care. They don't use taskwarrior (apparently), they want to use "task" as binary name for taskfile. But masking that behind "backward compatibility" shim.
Anyway the options are - A) go-task B) task-go C) keep task and conflict with community/task D) Something else
Also, take a look at search results I mentioned before - go-task is already used for versioned version of this package. I would go for that - create a "go-task-git" package with same description as for "go-task" package (so AUR helpers would show results for "taskfile" string) and name binary as "go-task". In that case I would have no objections about deleting my package. -- With best regards, Stanislav Nikitin (also known as pztrn). Email: pztrn@pztrn.name Telegram: @pztrn
I was not aware of the other two go-task packages. I have created AUR/go-task-git and filed a merge request for AUR/taskfile-git to unify things. I have also changed the binary name to match the other two existing packages (go-task). I am still not 100% convinced that 'go-task' is a good name for the binary but everyone else seems to be using it that way, so no reason to go against the grain. Martin On Mon, Aug 22, 2022 at 3:44 PM Stanislav N. aka pztrn <pztrn@pztrn.name> wrote:
It tab-completes very great. And even earlier than in your version.
Only if you remember it starts with a 'g', instead of the original 't'. If you're following official documentation and trying to use 'task' and wondering why it's red and not found, tab-complete will save you there.
It will autocomplete to taskwarrior first. That might be greater problem with UX.
Moreover, before making this package happen I was speaking with original maintainer via email, and he declines binary renaming "because docs says it's task". Moreover I agree with Egor - why should we change names to make a mess in user's brains while reading documentation?
Because the alternative is making the package conflict with `task`, so one cannot have both installed on the system. That is worse. The user is free to setup an alias to use 'task' as per the documentation if they do not also use community/task.
Users will expect "taskfile-git" to behave just like written in docs, so "task" should be a command for that package. That was original maintainer's intention.
As I can see, you've just picked up this package and "fixed" it without even trying to contact me and filed a deletion request for package that fixes problem in more proper way (using org's name).
The package did not download, was out of date, did not build, conflicted with [community], had missing completions (still does for fish/ps to be honest) and had a wrong license.
The proper way to deal with those is not creating yet another AUR package, the proper way is to fix the existing one, which I have done, and then noticed you duplicated the package, hence I filed this deletion request.
So we should expect deletion requests for all these packages, right?
https://aur.archlinux.org/packages?O=0&SeB=nd&K=go-task&outdated=&SB=p&SO=d&PP=50&submit=Go
Again, I'm asking to reconsider and withdraw/deny this request.
https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi... See second rule here, your package at this point is just naming the binary differently, which is just pointless duplication, let's rather reach consensus on what it should be named as.
Which CONFORMS second rule, because package on time of submission was up to date BUT maintainer REFUSES to change resulting binary's name in sake of UX. Can't blame him for that.
Maybe this entire issue should perhaps be raised upstream as 'task' is very generic. Taskwarrior started in 2008 and task in 2017. Though I doubt anything useful would come of it.
https://github.com/go-task/task/issues/697 for homebrew tap, yet same can be extrapolated on other platforms too. They don't care. They don't use taskwarrior (apparently), they want to use "task" as binary name for taskfile. But masking that behind "backward compatibility" shim.
Anyway the options are - A) go-task B) task-go C) keep task and conflict with community/task D) Something else
Also, take a look at search results I mentioned before - go-task is already used for versioned version of this package. I would go for that - create a "go-task-git" package with same description as for "go-task" package (so AUR helpers would show results for "taskfile" string) and name binary as "go-task". In that case I would have no objections about deleting my package.
-- With best regards, Stanislav Nikitin (also known as pztrn). Email: pztrn@pztrn.name Telegram: @pztrn
participants (2)
-
Martin Rys
-
Stanislav N. aka pztrn