From pykde Wed Oct 23 17:56:29 2002 From: Jim Bublitz Date: Wed, 23 Oct 2002 17:56:29 +0000 To: pykde Subject: Re: [PyKDE] Where & What ? X-MARC-Message: https://marc.info/?l=pykde&m=103540024304432 On 23-Oct-02 Marc Schmitt wrote: > On Dienstag, 22. Oktober 2002 21:16, Jim Bublitz wrote: >> Sounds like a user-generated FAQ - I think I'll steal that idea >> too. I'd definitely be interested in seeing that info, as I >> haven't used anything but SuSE for quite awhile. It would be >> helpful to me for improving the install process and users >> wouldn't have to fix the same stuff with every new release. > > I think, out of a *user* point of view (user is everyone who > wants to use Py*, not develop it) binary packages are far more > important then source packages. While improving the source > setup surly is something important, providing painless binary > packages for all major distributions will have (imho) more > impact. I pretty much agree, but if something won't build on a particular platform at all, it's kind of hard to do the binary. > Ack. I haven't thought about it, when I last uploaded the binary > packages to sf. But I guess we have to time it anyway, because > the files within /incoming tend to get remove quite often. It does make international collaboration more difficult. > See, this is one of the largest problems I currently have > (besides my fundamental lack of money) : Where to put files ? > It's alway a pita publish something thats larger then 40k. Same here. >> I don't have a problem mirroring the source tarballs on SF, but >> I still think there are a lot of good reasons to make riverbank >> the "official" site for the base source packages. Phil and I >> have discussed this in the past and decided against making SF >> the "official home" of the source code for various reasons. I >> think from "our" perspective (Phil will certainly disagree if >> the "our" doesn't apply) it makes a lot of sense to have a >> home for development, and a separate home for >> users/binaries/everything else. If nothing else, riverbank is >> much more convenient on this end and Phil has it highly >> automated. > Personally, I tend to "one place to rule them all". Again, simply > out of a users point of view. Out of political reasons, I surely > understand that you want to host your files there, as it gives > you some part of image (i hope you understand what i mean) and > serves as advertisement. So there's nothing wrong with it, but > I wouldn't duplicate the sources (at least not if riverbanks > host is stable enough). What about this solution : > Keep the sources on rbc, everything else on (e.g.) sf. And > provide transparent links on sf that link to the sources, with > a comment "maintained at riverbankcomputing". That seems the perfect solution to me. The two concerns are really access and control (along with co-ordination and convenience), and linking is sufficiently transparent to solve the access part without doing any harm to the control part. A lot of projects seem to do something like this. >> > In my mind, the best way to handle this is to keep your RPMs >> > as close as possible to the distribution's RPMs. If RedHat >> > and SuSE package PyQt differently, then our RedHat and >> > SuSE RPMs would be different as well. We'll need a little >> > document telling people what they need to get and how to >> > install it, but they would need that anyway. > Distributions won't be able to afford this way much longer - in > longterm, It leads to fragmentation and weakens their position. > And personally I find it insane, that if Phil or Jim relase a > new version, d*v(*k) new packages had to be generated (d=number > of distribution, v=number of version, k=number of kdes) - just > for this package. Imaging what a waste of resources it is. So if > we here could at least minimize d, AS LONG AS we can provide a > drop-in replacement, why shouldn't we do so ? If we can't, we > have to find another solution, but I really prefer unification. This is open source - we love to duplicate efforts (look at the number of IRC clients on freshmeat, for example). > Out of this reasons, I'd like to use a unified .spec, which > builds on every platform. I've seen good examples (the one > Hans-Peter provided) about using flexible macros which can > configure nearly anything. So at least we should give it a try. I don't know enough about rpm to know if this is feasible, but I've wondered if it's possible, and it certainly seems desireable. If someone can make a start on a .spec file that does this and provide me a little support, I'll be happy to try and maintain it for PyKDE. We used to autmatically generate a .spec file (in the Makefile I believe), but I never paid much attention to it. > Debian will probably have to go their own way, but hey - Debian > always does this ... :) (I've used it exclusivly for over a > year) >> I agree - consistency is nice if you can achieve it, but >> I don't think it's ever a strong reason for choosing a course >> if action. I'd trust the package maintainers to use their best >> judgment and hopefully provide enough documentation to make >> their releases usable. > Well, I do. Consistency == Userfriendly. I think '==' is a little strong, but I'm certainly not opposed to being either consistent or userfriendly. I'd lean more towards "the principle of least surprise" or predictability than consistency. > But if the world is against me in this point, I wont make a > problem out of it :) Yes, but we're *consistently* against you :) >> >> If there's anything I can add to PyKDE to make life easier >> >> for package maintainers, please let me know. > a billing-address ... But honestly, make it KDE-independant ... /dev/null? :) > I think this can be solved by a clear and common way and place we > where we provide information. As Phil already said, if we had a > list of who's who, we could simply cc each other, define a > special subject-prefix and use good old mail. Recruiting people > will not be that easy. There so many OS projects begging for > help ... IMHO, the only way to accuire people is to grow. If we > grow, if we're get more attention in public, more people will > come and ask for help. A few people have posted already - I'll try to keep a list, but I'm not always good at doing that. Does anybody object to having their name/address in a file in the distribution? >> > 3. Web designer. Needs to be familiar with PHP, or willing and >> > able to learn. Will put together a website that will explain >> > what sip, PyQt, and PyKDE is, post the documentation on the >> > website, and instructions for getting it to work. Some artwork >> > and design skills will be necessary. We also want to expand to >> > dynamic web pages that allow the PyQt and PyKDE communities to >> > share code and tutorials. How many do we need? Enough. > I could start doing this, and see how it develops. (Althogh I > don't fully agree on the php-part (depends on the project size > and if we have a cgi-enabled server) ) Go for it ... Jim _______________________________________________ PyKDE mailing list PyKDE@mats.gmd.de http://mats.gmd.de/mailman/listinfo/pykde