[PyKDE] Where & What ?

[Jim Bublitz]

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