[Pan-users] Re: Is this project still alive?

[Petr Kovar]

Duncan, Sat, 21 Jun 2008 01:35:55 +0000 (UTC):

(...)

> Not that I know of.  He apparently ignores both the user and the devel 
> list for long periods of time -- the .nzb file buffer overflow was posted 
> to the devel list with no answer, except from us users and some 
> distribution pan package maintainers.  On the bug, the GNOME folks bumped 
> the bug priority to the highest possible and marked it security, and 
> you'd /think/ if /anything/ would get a response /that/ would, but not a 
> peep.  Basically the same with the gcc-4.3 patch and the glib 2.16 bugs 
> and patches. 

In fact Charles did some bug triaging in Pan's part of the GNOME Bugzilla
earlier this year, in January more precisely if I recall correctly. But I
haven't noticed any other progress since then.

(...)

> I *DO* know that Charles is (or was for a time after he went silent here) 
> still active on other GNOME projects.  I forget the name of it ATM since 
> I'm normally a KDE person, and all of this is second-hand from a pan user 
> that follows GNOME in general, but there's a GNOME torrent app that had 
> evidently been going pretty slow that Charles evidently either adopted or 
> submitted a whole bunch of patches for (in a classic Charles "great guns" 
> phase), that ended up being absorbed and advancing the app quite some 
> distance in a relatively short time.  However, even that was probably six 
> months ago now, and I've no idea what has happened since then.

Yeah, I do know that too. :-) This program you're talking about is
Transmission, right?

<http://www.transmissionbt.com/>

It's not a GNOME project/application though. Transmission only provides a
GTK+ GUI, in addition to others.

And looking at the Transmission's source code web viewer, it seems Charles
is quite active there:

<http://trac.transmissionbt.com/browser/trunk/>

(...)

> You may also wish to contact the GNOME folks and see what they might 
> suggest, particularly given the security bug and inaction on it to this 
> point.  Certainly, they must have some interest in at least having 
> someone that would do security and preferably gcc/glib type update 
> patches.  Again, preferably not to fork, but at the minimum, someone who 
> could work with Charles and have commit privs for security and toolkit/
> toolchain updates.  One would think that's pretty critical, and it's not 
> being addressed at this point, so at least getting it addressed should be 
> in the interest of everyone in the community, including Charles.

It's sad to see Pan seriously heading toward un-maintenance, abandonment
and, let's say, obscurity. But as far as I know, the GNOME project itself
has no policy regarding the maintenance or, better say, dealing with an
un-maintained module, if it's not a GNOME critical/official one. Pan is
neither former nor the latter.

It's up to maintainer and/or skilled-enough volunteers to not let the
project die. Speaking of GNOME policies, if, after some time, a module can
be definitely considered un-maintained, then its SVN repository is moved
to <http://svn-archive.gnome.org/> - the name says it all. However, not even
the SVN repository of old Pan has been moved to this archive
till today - maybe because it's considered a project's last stable
release, new Pan being only in beta stage. 

<http://svn.gnome.org/viewvc/pan/>

So, what I think Pan users can do with this situation: Without maintainer's
(i.e. Charles's) consent, any code change should be considered as no-no,
with exception for l10n work, of course.

With his blessing, those with a GNOME SVN account can at least apply the
afore mentioned patches. Or branch the trunk and continue with some other
bits of development - that means at
<http://svn.gnome.org/viewvc/pan2/branches/>. Maintainer may incorporate
the branch changes after his return to the project. Or, with the same
intention, set up a new repository making use of a well-known public
service like SourceForge, etc.

Speaking for myself, I'm one of the GNOME translation coordinators, so I
can help with applying patches or branching, but that's all,
unfortunately.

Best,
Petr Kovar