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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
