On 08/01/11 23:18, Kaiting Chen wrote:

On Sat, Jan 8, 2011 at 2:54 PM, Lauri Niskanen wrote:

...

On 01/08/11 21:38, Kaiting Chen wrote:

...

Just out of curiosity does anyone use tdl? The last release was way back in 2004. --Kaiting.

I use it. However, if you know better applications for the same job, please tell me.

How about RememberTheMilk? --Kaiting.

Are you referring to http://www.rememberthemilk.com/ ? They seem to target very different problems. I use tdl for per-project todo-lists, and I check the list into version control. RememberTheMilk would not be a suitable replacement for that. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On Saturday 08 January 2011 23:23:26 Mike Sampson wrote:

...

...

[1]: http://www.archlinux.org/packages/community/x86_64/tdl/

I use it. However, if you know better applications for the same job, please tell me.

Task Warrior - https://aur.archlinux.org/packages.php?ID=22085

+1, this is great. Pete.

2011/1/10 Cédric Girard :

On Sun, Jan 9, 2011 at 12:23 AM, Mike Sampson wrote:

...

Task Warrior - https://aur.archlinux.org/packages.php?ID=22085

Mike

Does anyone know why this package does not use upstream name ? There is no way to tell this "task" package is Task Warrior except looking to the URI.

There's some confusion on the upstream page, taskwarrior.org. Text like "Taskwarrior is an ambitious project to supercharge task with an interactive interface, GTD features, color themes, data synch, dependencies, custom reports, charts, and Lua plugins, all while our international team provides excellent support!" make it sound like 'taskwarrior' is a layer on top of something called 'task'. But then the download file is http://www.taskwarrior.org/download/task-1.9.3.tar.gz The package is called 'task' by upstream in all distro files they provide too. No matter how confusing this is, I would say that 'task' is the correct package name for the program taskwarrior :-) /M -- Magnus Therning                      OpenPGP: 0xAB4DFBA4 email: magnus@therning.org   jabber: magnus@therning.org twitter: magthe               http://therning.org/magnus

On Monday 10 January 2011 10:26:14 Magnus Therning wrote:

...

Does anyone know why this package does not use upstream name ? There is no way to tell this "task" package is Task Warrior except looking to the URI.

There's some confusion on the upstream page, taskwarrior.org. Text like

"Taskwarrior is an ambitious project to supercharge task with an interactive interface, GTD features, color themes, data synch, dependencies, custom reports, charts, and Lua plugins, all while our international team provides excellent support!"

make it sound like 'taskwarrior' is a layer on top of something called 'task'. But then the download file is http://www.taskwarrior.org/download/task-1.9.3.tar.gz The package is called 'task' by upstream in all distro files they provide too.

No matter how confusing this is, I would say that 'task' is the correct package name for the program taskwarrior :-)

You're right, but it might be worth including something like "AKA taskwarrior" in the description, to help people searching for that term. Pete.

On 09/01/11 17:33, Kaiting Chen wrote:

On Jan 9, 2011, at 5:54, Magnus Therning wrote:

...

On 08/01/11 19:38, Kaiting Chen wrote:

...

Just out of curiosity does anyone use tdl? The last release was way back in 2004. --Kaiting.

I use it occasionally, it's a nice, light-weight little ToDo manager.

Okay I was just wondering whether or not I should keep it in [community]. Looks like I should. --Kaiting.

I'd nominate it for a migration back to AUR actually. So far people seem to have gotten excited about all the alternatives suggested in the thread, and personally I can always use vimoutliner instead anyway :-) Is there no "package popularity contest" that could offer information about actual usage? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On Jan 9, 2011, at 12:50, Magnus Therning wrote:

Is there no "package popularity contest" that could offer information about actual usage?

This is always an interesting topic to discuss. There is pkgstats which unfortunately is not ideal statistically in that it does not pull data from a characteristic sample. To figure out actual usage data is probably impossible. The metrics from MirrorBrain might be the closest one can actually get to that. Unfortunately that is not what we use to manage our mirrors. --Kaiting. Kiwis and Limes: http://kaitocracy.blogspot.com/

Yes magnus, arch has pkgstats which is similar to popcon, but the instalation is completely volountary. it is a good resource, but something more granular would be nice.

On Sun, Jan 9, 2011 at 11:41 AM, Magnus Therning wrote:

On 09/01/11 18:21, Thomas S Hatch wrote:

...

Yes magnus, arch has pkgstats which is similar to popcon, but the instalation is completely volountary.

Doing anything but a voluntary thing would be VERY difficult for many reasons I think ;-)

...

it is a good resource, but something more granular would be nice.

What do you mean by "more granular"?

/M

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

Right, it needs to be voluntary, of course :), but the problem is that the results of the pkgstats, while useful, are still singled out to a subset of users. This of course breaks the reliability of the statistical analysis. So pkgstats is a good indicator of package use, such that if a package shows up a lot on pkgstats then we have a viable indication of popularity. But the opposite cannot be reliably assessed, this is because the subset of users using pkgstats does not reflect a random sampling of users, therefore, statistically it is very feasible for there to be large unrepresented swaths of users. By "granular" I mean "more accurate", the problem here is of course is the question of how this is done. The Fedora project uses a system called smolt to track Fedora installations, it runs during the firstboot process and returns a monthly report to Fedora about hardware and installation information. Fedora feels somewhat confident that smolt returns fairly accurate information, mostly because it is turned on by default. But even then, it can only reflect a subset, since it is still opt in and client side. The next argument would be to incorporate a server side solution, that just traces how many times individual files are downloaded. The problem here is that it requires that we ask the mirrors to all run mirror side traces, and I highly doubt they would all go for it. I imagine there are other solutions to the problem, but the reality is that open source is by its nature viral, and tracking this stuff is murder. So removing something from community and placing it in the AUR is difficult, primarily because we cannot be sure that it is not being used. Unfortunately this method "ask around" has a number of holes too. I know that there are criteria for bringing a package into community, I wonder if a set of criteria or lightweight process for package removal from community would be a good idea. The way distributions like debian and Fedora handle this problem is by just packaging everything - and we don't quite have the man power and interest (all be it Arch is getting close, we have a lot of Devs and TUs now). But also there is a question, a strong question, about whether or not that would be an Arch philosophy solution at all. The AUR and the easy path to package inclusion is one of the things that make Arch great.

On Sun, Jan 9, 2011 at 2:51 PM, Kaiting Chen wrote:

On Sun, Jan 9, 2011 at 4:18 PM, Thomas S Hatch wrote:

...

The next argument would be to incorporate a server side solution, that just traces how many times individual files are downloaded. The problem here is that it requires that we ask the mirrors to all run mirror side traces, and I highly doubt they would all go for it.

Use a single central server that proxies all requests to individual mirrors. Then you track at the site of the central server. --Kaiting.

-- Kiwis and Limes: http://kaitocracy.blogspot.com/

Ahh! That would work for tracking, I should have thought of that. but then the user can still directly attach to mirrors and the results are skewed again, and you know that they would, since the proxy is not always going to make the best choice for them, at least it sure doesn't work on Fedora! But when all is said and done I don't think that adding layers to the repo would be a good move, it creates an over complication to the pacman process, and for tracking. This is clearly a Heisenberg issue, adding complexity to track something has changed the basic nature of that which is being tracked. Mainly my comments were more along the line of exploring the issue, in the end I think that just writing up some guidelines for moving packages out of the binary repos would be a good idea, adding engineering to the problem on the level I have described would be non KISS IMHO. -Tom