[PyKDE] Where & What ?

[Jim Bublitz]

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:

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.

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

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.

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. 

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.

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.


Jim