Re: CinePaint tasks

Kai-Uwe Behrmann <[email protected]>
Newsgroups gmane.comp.video.cinepaint.devel
Message-ID <[email protected]>
Am 27.02.08, 04:43 -0800 schrieb Robin Rowe:
>  > below are some small to bigger sized
>  > things to contribute. They are not limitted to packaging
> 
> Mohanjith hasn't finished work on 'make rpm' and other rpm tasks I've 
> requested. It seems premature to ask for additional tasks beyond packaging.

I was not aware. Ok.
 
> > o compile Glasgow easily on Posix systems (BSD/Linux/osX/MinGW)
> >   (cmake/autotools/PMK ??)
> 
> Glasgow builds fine using CMAKE. There's nothing to be done there that 
> I'm aware of. I've asked our CMAKE developer Michel Lesoinne to add 
> CMAKE support for Film Gimp.

Ah, fine I will have to check.

> > o create an LSB compatible package for Gtk2 CinePaint including a 
> >   installer script, something like the one for Googleearth
> >   a new "make lsb" target beside "make rpm"?
> >   (shell scripting, autotools)
> 
> I didn't know it wasn't LSB already. What are the changes? Why?

I would not expect LSB to cover all of our fancy graphics libraries like 
OpenEXR, FTGL ... These libraries must be in some directory to run 
CinePaint out of the box for a one package simple shell script install.

> Personally, I detest the LSB sprinkling files all over the system making 
> it difficult to uninstall. Something I'd like to see make do is create 
> an uninstall script (uninstall.cinepaint.sh).

We dont need. The Googleearth example fits what you request very neat. I 
have done similiar packages for other projects. A self extracting 
shellscript has its own charm.

> A build option for segmented installation would be nice. That's 
> everything installed in one directory or below. A call of rm -rf removes 
> completely. From a system security standpoint, apps installing shared 
> libs are evil. From a testing standpoint, it would be nice to install 
> multiple CinePaint versions that can't collide.
> 
> > o translations (po file editing and testing)
> 
> If we need a translations maintainer we should post that as an open 
> position. What tasks and skills are needed? Will you supervise?

I would help as I did already. Perhaps I get to setup a progress page for 
this matter.

> > o dcraw + plug-in update (small C coding)
> 
> Sounds like a good small tasker for someone. Does anyone want to do? 
> What exactly is needed?

In short:
o put a new dcraw in place, near by the plug-ins - to be seen in a working 
  CinePaint package.
o check old options
o suggest new ones
o test
o probably modify the rawphoto plug-in to run again. 
Tiffs with and without profiles is a requirement.

> > o last but not least a 0.23 release of the Gtk2 version, including the 
> >   many testing, say playing and spotting obvious bugs 
> >   (muse, bug communication and fixing, autotools, 
> >    testing on various architectures and cutting edge distributions like 
> >    on the Novells build server + Open/FreeBSD, possibly Solaris)
> 
> I have an UltraSparc. I'll build on Solaris. We have maintainers on 
> OpenBSD and FreeBSD.
> 
> Anything rpm packaging is within Mohanjith's mandate, should definitely 
> be involved in 0.23. By the way, it's my goal that the next version be 
> 1.0, not 0.23. What needs to be done specifically?
> 
> QA beyond rpm testing is outside Mohanjith's mandate. We could post an 
> opening for a QA position, but that implies someone will follow through 
> to squash bugs. Kai-Uwe, are you doing that? Do we have all the bugs 
> squashed in the database?

What a pitty. I had loved to read we find someone to take over step by 
step the release work from my shoulders. The current delay of a release is 
not intentional, but because of my other work and projects. I know it is 
hard to find someone, who has the energy to qualify for such a work load.

> Kai-Uwe, in case you don't know, you're our autotools maintainer. Nobody 
> else is willing to touch it. I've given up on autotools. CMAKE is 
> already in place for Glasgow. I want to build with cons, too.

Thanks.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.