[PyKDE] Where & What ?

[Marc Schmitt]

On Dienstag, 22. Oktober 2002 21:16, Jim Bublitz wrote:
> Even plain old HTML to begin with would be fine - you can always do
> the PHP for v2.0

Yesterday I started to layout of a page within a design-tool. I made a 
screenshot and sended it to this list, unfortunatly, the mail is ~90k, and it 
still awaits moderator approval.

> > It would be really nice to have everyone write a short page for
> > how they get their system to work and what mods they like to
> > make. A page for Windows, subcategoried into 95, 98, 2000, NT,
> > XP and whatever is useful would be good. A page for Linux,
> > subcategoried into Debian, Redhat, SuSE, Mandrake, and
> > whatever distribution any of you use out ther would be really
> > nice. This way, a new user can come to the website, read up on
> > what they need to do for their  system, and we can hopefully
> > expand our user base.

Ack. 

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

> > The best way is to send an email to me saying that you have the
> > latest package. Then we can discuss the best way for you to get
> > it to me. I can set up a temporary FTP server that you can
> > upload to. We can also agree to a time that you can upload
> > directly to SF and I can get it then.
>
> Sounds good to me. Or else people can just send you links and can
> handle the uploads/ftp on their own favorite server.

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.

> >> Somebody probably needs to tackle (1) at least. I feel like I
> >> should be responsible, but as is apparent from the slack release
> >> schedule of late, it's difficult to find the time and I'm also a
> >> terrible web site designer. I'm happy to keep PyKDE up-to-date
> >> at the source level, but realistically I can't handle much more
> >> than that - I haven't kept up on promises I've made here on
> >> some other stuff like code for doing panel applets.
> >
> > You should definitely NOT do it.

As I said, I made a draft for review. But currently, I dont know where it is 
:(. The one who's responsible for giving approval - please ...

(Or does anyone have a place where I could upload this ?)


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.


> >> I agree with Phil that riverbankcomputing is not an option for
> >> binaries - Phil gets stuck paying for extra bandwidth from a lot
> >> of large downloads, and in addition it ends up being a lot of
> >> extra maintenance work for Phil.

Yes.

> > SF is more than willing to host everything. I think hosting the
> > tarballs at SF is far better than hosting them at RiverBank
> > because of that. Maybe the commercial version of PyQt and such
> > should still be at RiverBank, but the free version should
> > definitely find its home on SF for bandwidth reasons.

Yep, but see below.

> 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".


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

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.

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 of 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.

But if the world is against me in this point, I wont make a problem out of it 
:)


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

> > 1. A release coordinator. This guy would make sure that if there
> > is more than one developer on a distribution, that they work
> > together. He would also keep track of who is working on what,
> > and light a littler fire under them when a new release comes
> > out. He would also actively recruit people for needed
> > distributions. Technical skills are not required -- only
> > management ability.
>
> Probably could use someone to light a fire under me occasionally
> too.

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.

> > 2. Distribution release manager. This person would need to become
> > familiar with their distribution, and try to integrate sip,
> > PyQt, and PyKDE in the best possible way. When a new release
> > comes out, they have to create the new  packages and make sure
> > that they get posted. They would also be responsible for
> > answering any questions on where to find the packages and how
> > to install them, possibly writing some instructions to be
> > posted on the website. They should also help Jim and Phil work
> > out any build problems on their system.

I think I didn't get this one : Doesn't this mean this person had to have all 
distributions and would basically be doing the work of the 
package-maintainers ?

> > 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) )

Bye
-Marc