[PyKDE] PyKDE-3.7-3 Available

[Jim Bublitz]

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

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.