Re: Keeping Pan alive?

Three more weeks and only silence.  I guess it's time to move on.

On 2021.07.06 12:40, Jack Ostroff wrote:
> It's now been over three weeks, and no responses at all.  (During  
> which time there have been several new posts to some issues and MRs.)
> 
> On 2021.06.13 09:22, Detlef Graef wrote:
> [snip .... and reordered so my responses flow a bit better, and some  
> more detailed issues dropped for now.]
>> I've asked a project member of Pan with Administrator role about the  
>> status of Pan, I've got now answer at all.
> I think several of us on this list have tried contacting various  
> previous developers, all with no success.  Is there anyone else to  
> try to contact?
> 
>> I don't know if it is possible to keep Pan alive because migrating  
>> it to GTK3 would be a major task.
> I am using Pan with gtk3 with no problems.  However, there are many  
> features I do not use, and I've been told (and agree) there are still  
> issues and bugs to be worked out.
> 
>> I don't need Pan.  For my requirements the following newsreader (or  
>> even Thunderbird) is ok:   
>> http://micha.freeshell.org/flnews/index.html
> I doubt anyone NEEDS Pan, but many of us obviously prefer it to other  
> newsreaders, as long as obtaining/compiling it isn't prohibitively  
> difficult, which includes it being kept up to date, in terms of  
> security issues and use of dependent libraries.
> 
>> Any opinions or suggestions if it is worth to keep Pan with minimal  
>> effort a little bit alive and how to do this?
>> What would be the best option to keep Pan a little bit alive a  
>> little bit more independent from the Gnome project?
> I agree that someone should create a fork - although I don't think it  
> matters whether it's within the Gnome gitlab instance or elsewhere.   
> However, as nobody has spoken up willing to take ownership, I don't  
> think it would really help the cause in the long run.  I agree with  
> you, and also believe I am not capable of properly evaluating any  
> MRs.  So, if either of us  would create a fork, I suppose we could  
> accept MRs that work for us, and hopefully one or two other users  
> could test before merging.  That would work for a while for those of  
> us willing to compile from source.  Unfortunately, I don't think it  
> would be adequate to get any distros (such as Gentoo) which have  
> dropped Pan to bring it back.  On that secone item - I use Pan on a  
> KDE Plasma system, so although Pan is currently hosted on Gnome  
> infrastructure, it is not necessarily dependent on it.  This means a  
> fork could as easily be on github or gitlab.  Might there be any  
> point in trying to ask the Gnome project what it thinks should be  
> done with apparently abandoned projects?
> 
>> Maybe the best way is if someone is keeping Pan up to date in a own  
>> repository (and branch) as a fork from  
>> https://gitlab.gnome.org/GNOME/pan inside the  
>> https://gitlab.gnome.org/GNOME infrastructure.
> Unless one of the previous developers emerges from silence, I agree.
> 
>> But at the moment there are some pending Merge requests which are  
>> worse to be merged to fix some urgent issues.
> Anyone can do this in a private repo (even local and not in a  
> publicly available repository) so I think this question can be  
> deferred until the previous ones are answered.
> 
> 
>> I've created a rpm package of Pan for Fedora:  
>> https://copr.fedorainfracloud.org/coprs/dgraef/Pan/build/2251959/    
>> Builds for Suse, Mandriva, are maybe possible. At least  
>> https://copr.fedorainfracloud.org offers this.
> So there is at least a short term solution for some who don't want to  
> compile themselves, and this can be relatively easily expanded for  
> several other distros.
> 
> Jack
> 
> _______________________________________________
> Pan-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/pan-devel

_______________________________________________
Pan-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/pan-devel