[PyKDE] Where & What ?

[Jim Bublitz]

On 22-Oct-02 Jonathan Gardner wrote:
> On Tuesday 22 October 2002 08:09 am, Jim Bublitz wrote:
>> On 22-Oct-02 Marc Schmitt wrote:
>> 1. Set up a different home page at SF that points to
>> riverbankcomputing for the latest tarballs/releases, and then a
>> section of pointers to the various rpms, addons, patches,etc.,
>> either on SF or elsewhere. It isn't really necessary that all of
>> the files be in one place, just the links. It should also
>> reference this list, of course. Phil would then only have to
>> maintain links to that page at the riverbank site to direct
>> people to the binaries.

> Yes. This is a very good idea. I had this idea in the back of my
> head -- 

You probably mentioned it before - most of my good ideas are stolen
from someone else :)

> something like ViM's website where we can share code and examples
> and tutorials would be really nice. Now I just have to get off
> my rear and learn PHP to do dynamic pages at SF. Of course, if
> someone has the time and the expertise, you are welcome to do
> it. (See Below)

Even plain old HTML to begin with would be fine - you can always do
the PHP for v2.0
 
> 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.

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.
 
>> 2. I personally don't have a problem with giving Marc or
>> Hans-Peter upload privileges at SF (I have admin privileges),
>> although I'd prefer to leave that up to Jonathan. If people
>> want to upload rpms there, it shouldn't be a problem. OTOH, if
>> Jonathan has the time to co-ordinate that, that should be OK
>> too. It seems that anyone can upload, but someone has to pick up
>> the packages and transfer them to the site (admin) within a
>> short period of time. That hasn't worked out very well for me
>> in the past - maybe because of the timezone difference (I'm on
>> the US west coast).

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

You don't know how true that is :)

> There should be enough people here to pick up  what you can't do
> or don't have the time to do.
 
>> 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.

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

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.

That said, I'm all in favor of more people participating in PyKDE
and (hopefully) influencing its direction.
 
>> As Phil also indicated, it would be nice if people would
>> indicate their willingness to put together and support
>> binaries or srpms for a particular
>> distribution/platform/whatever. I'm really not sure
>> what's already available or who's doing what. It would be
>> equally helpful if older versions were made unavailable when
>> appropriate (one of my gripes about SF is that everything
>> stays there forever, including the mistakes I made when
>> uploading).

>> > What about packaging policy ? To me this means, how to split
>> > packages. For SuSE 8.0 I made -devel and -doc packages, for
>> > 8.1 I merged everything together reflect the source
>> > structure :  There are only three packages, sip, PyQt and
>> > PyKDE left. Each contains all of the sources stuff, like
>> > libs, docs, examples and sips. IMHO we should provide
>> > three super-spec, that everyone can use for every
>> > distribution.

>> When I actually had a job and couldn't avoid management
>> responsibilities, my attitude was always "you do the work - you
>> make the decisions" (it might not be the best mgmt style, but at
>> least nobody came after me with automatic weapons). I personally
>> prefer the "everything in one place" approach, but the files get
>> fairly large then I imagine. While it would probably be best to
>> be consistent among the various distributions, the only thing
>> I'd feel really strongly about is that for a specific
>> distribution release, people pick a method and stick with it -
>> offering several options (eg. one big package or several
>> smaller packages - the user has to choose) is not a good plan
>> IMHO.
 
> 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.

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.
 
> This has several positive effects. One, through upgrading, you
> are replacing the distribution's packages. That makes it a lot
> easier because the old stuff won't be in the way. Two, there is
> a chance that the distribution may pick up your RPM specs for
> its next release, or at least that the guy in charge of 
> making the RPM will be able to work with you.

Working with the Debian and FreeBSD guys has been a big help to
both Py* projects. I'm certainly open to doing whatever will help
the other distributors, but the KDE release cycles are too frequent
to hope that the distributors will keep up. SuSE beat me to KDE
3.0.4 (I think), but I'm pretty sure I'll beat them to 3.1 and maybe
3.1.1 as well.
 
> Also, the specs are not going to be exactly alike. With RedHat
> using Python 1.5 as /usr/bin/python, I can't write a spec that
> depends on /usr/bin/python being Python 2.2. In fact, I should
> probably put together two different packages for each - one for
> Python 2.2, and the other for Python 1.5. That wouldn't make
> any sense for SuSE, who uses Python 2.2 for /usr/bin/python, 
> and doesn't even have Python 1.5.

There is some stuff in sip that's Python version sensitive
(weak refs?), I believe, so binaries will be Python version
dependent unfortunately. Compiling shouldn't care for Python >=
1.5.2. (2.2.1 has some really nice features though)
 
> If you go off and use some other system of organization, it will
> require a bit more work on the user's end to get everything set
> up properly.
 
>> If there's anything I can add to PyKDE to make life easier for
>> package maintainers, please let me know.

>> The bottom line seems to be that someone needs to volunteer to
>> co-ordinate this (don't be shy!) and other people need to sign
>> on (for however long you can) for their bits, and clearly
>> indicate when they can't continue so someone else can pick up
>> that part.

> Hey folks, if you think you can handle a volunteer position, you
> better speak up! My experience is the Phil and Jim are more
> than willing to share the burden with their fans.
 
> This is my picture of what we are looking for, based on the last
> few posts. Go ahead and clarify or contradict me if I am wrong.
> You may also want to append to this list if you see anything
> missing.
 
> 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. 

> 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.
 
> Right now we have a couple of people working on SuSE, one on
> Debian, one on RedHat, and I think one on Mandrake. However,
> having two or three people on one system is not a bad idea.
> Different versions of the same system may need to be supported.
 
> 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.

Phil and I can probably continue to handle
freshmeat/comp.lang.python/kde.org announcements, but beyond that
everything else is wide-open (we'll have to remember to update the
SF links in the announcements too)

Anything is better than nothing at the moment - my personal
affinity is for projects that start small but know where they want
to go eventually (and you seem to). There's nothing wrong with 0.1
releases.

My last suggestion is that anyone else interested jump in soon -
even an occasional hour or two here and there can be a big help or
a great learning experience. Beyond that, I'd suggest Jonathan,
Hans-Peter and Marc (along with whoever else is interested) work out
the details off-list and I'll just stay out of the way. Let me know
if I can help in any way.

Jim