On Domingo 14 Noviembre 2010 00:45:08 Michael Tautschnig escribió: > Hi again, > > I think sounded pretty rude in my earlier mail; I'm sorry, I didn't mean to > be rude. I just had got the impression that you were waving away other > people's suggestions for no reason obvious to me. Do not worry. It sounded a bit, but your arguments were consistent. As I said, I'm, not denying other people or other ways, just trying to get things done as first step, and allocating space for big improvements for the second wave of packages. I like the stardata-common way but don't know if it is appropiate, and I'm almost sure getData is not, but both thoughts must be revised (in a future). > > [...] > > You're right; I just hadn't fully accepted that is was a simple data > package that will ensure the data doesn't get stored for each and every > user, but just once and for all on the system. Yes, that's the point: downloading data only once, not per user. And if it can be further enhanced to be only one per system, and not per program, even better. > > [...] > > Oh no, surely not, I was rather hoping that ... [...] > ... you could go for stardata-common right now. This might be a bit more > work (and you would hence possibly miss the Squeeze freeze), but I still > believe in it being beneficial. It would actually even more reduce the > disk space and band width usage if several packages shared such data. I > understand that this is non-trivial. So why was I panicking? Once the > package has entered the archive, it will stay. It does what you wanted it > to do, and it will be hard to enforce any changes. Here and now is my only > chance to try to convince you to follow a different route. Of course, bugs > could be filed, but none of them would be of release-critical severity. You have nothing but my word on this, but I'm not the kind of people who gets its package done as wanted, and later forget it. I want it to be useful and Debian to become better release after release, so I will take the path for stardata-common, but I truly prefer to do it after having the first wave of packages in, since not all packages I'm after are catalogs, and thus stardata- common itself would need to be enhanced to accomodate them all. That's probably a work long enogh for wheezy+1 or +2 if you take into account that conversion tools from text catalogs to kstars format are not easy to find, and the catalogs used are not exactly the original ones, but extracts of. I would start that not on these packages, but on the Gliese and Yale catalogs, since its stars are (most probably) included in the kstars' core (package kstars-data in Debian) and those catalogs are already in the stardata-common framework. > > [...] > > I think I got the point of your packages and while I might still not be the > one sponsoring them, it would be for technical reasons only (my knowledge > of KDE stuff is really limited). Which may not make a difference for you, > but at least for me it was important to have my attitude adjusted. I still > hope that there is a convergence towards a common data set for packages > interested in the same data, but it shall not block an initial upload. > Really no KDE knowledge is needed to sponsoring this: all that is needed is to drom some files in a determinate directory and (possibly) to set up a rc file. The contents of that file is also known. The knowledge I think is needed to sponsor this first package, and the upcoming ones in the set, is that of debconf. I really need some help with that. I'd prefer a decconf guru rather than a KDE guru to sponsor me here. > Best regards, > Michael Thanks to you: you forced me to open a bit my mind and restat my objectives for these set Noel er Envite
Attachment:
signature.asc
Description: This is a digitally signed message part.