[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: kstars-data-extra-tycho2 (third try)

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 
> [...]
> 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 
> [...]
> 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 
> [...]
> 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

er Envite

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: