[PyKDE] PyKDE-3.7-3 Available
jbublitz at nwinternet.com
Sat Aug 9 03:46:01 BST 2003
On Friday August 8 2003 15:29, Jonathan Gardner wrote:
> On Friday 08 August 2003 14:30, Jim Bublitz wrote:
> > On Friday August 8 2003 13:03, Jonathan Gardner wrote:
> > > I'm not sure if you are familiar with the diff-patch
> > > method. I've sort of got a handle on it. I am sure someone
> > > out there will know how to administrate this better than I
> > > can.
> > It's another one of those things I don't do much, so I
> > expect I'd screw it up more likely than not and it would end
> > up taking me longer.
> The reason I am suggesting this is to open up the development
> of PyKDE. I know you don't like CVS. The diff-patch method is
> a good alternative. It won't take much time to learn, and
> getting everyone on board won't be hard.
> The goal in a lot of our minds is to avoid what happened for
> PyKDE 3.7. If you get hit by a bus (or the more likely
> scenarios: your home gets caught in the forest fire, you have
> to go to a funeral in some faraway place, or your bills are
> piling up and the cash ain't coming in), we want to be able to
> carry on without you. The best way is to keep whatever you
> have of PyKDE - -- whether it is stable or not -- available.
> It will also free you up from a lot of the boring development
> tasks. When a new version of KDE comes out, you can throw
> together a rough draft, and we can smooth the rough spots.
> When you incorporate some cool new features, you can throw it
> out and we can make it work.
I can be replaced by a machine. The way you need to look at it
is that I don't write PyKDE - I write the software that writes
PyKDE. With some bug-fixing and refactoring, that should be
releasable - I have no idea when, but it probably isn't that far
off. If it wasn't such a mess, I'd release it now, but I don't
want to support it in the shape it's in. A few people have older
copies already. It also wouldn't be that hard for someone else
to take over PyKDE, even without automation.
I hadn't realized until I started writing this post, but it
wouldn't be that hard to automate the entire procress
end-to-end, except the actual debugging. There isn't that much
debugging anymore though - maybe 10 to 15 errors in 400+ files
(including the post release stuff). I'm sure there are more bugs
lurking, but I plan more testing to catch and prevent that stuff
It's quite possible to write software that just requires people
to download a new set of kdelibs source files, but it may not be
desireable. kdelibs is about 8MB, vs 650K for PyKDE, for
example, plus there still is a small amount of code that needs
to be handwritten. Most of the handwritten stuff isn't that
important to most users though.
More information about the PyQt