[PyKDE] Where & What ?

[Jonathan Gardner]

On Tuesday 22 October 2002 08:09 am, Jim Bublitz wrote:
> On 22-Oct-02 Marc Schmitt wrote:
> > I'd like to start a discussion about those points :
> >
> > Where to place sip, PyQt and PyKDE related material. This means
> > sources, patches, packages, docs, examples, ... Currently
> > sources are on riverbank, some packages on sf, some on
> > lisa-gmbh.de. Patches seem to be nowhere, examples within the
> > sources. Wouldn't it be best to unify (or maximal dualify) the
> > places where we collect the stuff ?
>
> Jonathan Gardner set up the SF site at:
>
> http://sourceforge.net/projects/pykde/
>
> and if he's still following the list, he might want to provide some
> input. The home page link for that site is currently to
> riverbankcomputing. What I'd suggest is:
>

I am -- just not in real-time. ;-)

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

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.

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

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

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

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.

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.

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.

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.

Jonathan