taskSavannah Administration - Tasks: task #15078, Submission of Speech Dispatcher

 
 

task #15078: Submission of Speech Dispatcher

Submitted by:  Samuel Thibault <sthibaul>
Submitted on:  Mon 29 Oct 2018 04:36:41 PM UTC  
 
Should Start On:  Sun 28 Oct 2018 11:00:00 PM UTC Should be Finished on:  Wed 07 Nov 2018 11:00:00 PM UTC
Category:  Project Approval Priority:  5 - Normal
Status:  Done Privacy:  Public
Percent Complete:  0% Assigned to:  Ineiev <ineiev>
Open/Closed:  Closed Effort:  0.00

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 29 Jan 2019 06:30:51 AM UTC, comment #41: 

Thank you, approving.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sun 27 Jan 2019 02:08:13 PM UTC, comment #40: 

> > All software hosted on Savannah must be GPLv3+-compatible
>
> I have asked copyright owners of these files, and waiting for their answer.


They fixed it, it's now all GPL+/LGPL+ compatible, as can be seen in the current tarball:

http://dept-info.labri.fr/~thibault/tmp/speechd.tgz

Samuel Thibault <sthibaul>
Thu 17 Jan 2019 12:12:32 AM UTC, comment #39: 

> All software hosted on Savannah must be GPLv3+-compatible


Ah, right, I didn't remember after these months.

I have asked copyright owners of these files, and waiting for their answer.

Samuel Thibault <sthibaul>
Mon 24 Dec 2018 06:15:39 AM UTC, comment #38: 

> ./src/tests/spd_cancel_long_message.c and ./src/tests/spd_set_notifications_all.c are GPLv2-only. They are however stand-alone programs which only link against src/api/c/, which is LGPLv2.1-or-later, so AIUI it won't pose problem?


All software hosted on Savannah must be GPLv3+-compatible. Why are these programs less problematic than any other?

[in reversed order]

> I agree in general. But we are here talking about autotools and gettext, maintained within the GNU project. One can't blame maintainers for assuming that those packages are doing a proper job.

...

>These files are again generated by autotools, but sure, another COPYING file can't hurt.


On the other hand, it wouldn't be reasonable to expect that autotools would look for the license text and when missing add it where package authors want, so they have to check those things anyway, even with autotools.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Tue 18 Dec 2018 10:21:50 PM UTC, comment #37: 

> src/tests/spd_cancel_long_message.c says it's GPLv2-only. Please check other files as well and contact their copyright holders.


Ah, indeed:

./src/tests/spd_cancel_long_message.c and ./src/tests/spd_set_notifications_all.c are GPLv2-only. They are however stand-alone programs which only link against src/api/c/, which is LGPLv2.1-or-later, so AIUI it won't pose problem?

./src/api/guile/gssip.h is LGPLv2.1-only, it is linked with gssip.c which is LGPLv2.1-or-later, gssip.scm.in, which is GPLv2-or-later, and src/api/c/  which is LGPLv2.1-or-later, again AIUI it won't pose problem?

./src/clients/spdsend/spdsend.h is GPLv2-only, it is linked with other files in the same directory which are GPLv2-or-later, again AIUI it won't pose problem?

Or course, "-and-later" would be better for the long run, I'll contact the authors, but AIUI it doesn't actually pose problem?

It however goes better with telling the user about these, I have added notices in README.md.

> Some files like doc/texinfo.tex are under the GPLv3+; you should provide a copy of the GPLv3 in your tarball.


These files are again generated by autotools, but sure, another COPYING file can't hurt.

> I'd recommend replacing them all with the URL.


Right, much better for the long run :)

I have uploaded an updated package on http://dept-info.labri.fr/~thibault/tmp/speechd.tgz

> > Well, there is a difference between "any cost" and "not bothering maintainers with code they do not actually maintain".


> I believe maintainers have to bother themselves with all code in their tarballs; if they don't, they may end up distributing proprietary software and even having their users sued for illegally distributing proprietary software.


I agree in general. But we are here talking about autotools and gettext, maintained within the GNU project. One can't blame maintainers for assuming that those packages are doing a proper job.

Samuel Thibault <sthibaul>
Tue 04 Dec 2018 12:40:15 PM UTC, comment #36: 

> I believe the current code status... was fixed according to the comments?


src/tests/spd_cancel_long_message.c says it's GPLv2-only. Please check other files as well and contact their copyright holders.

Some files like doc/texinfo.tex are under the GPLv3+; you should provide a copy of the GPLv3 in your tarball.

Not a critical issue, but notices in your tarball provide 3 different postal addresses of the FSF, two of them are obsolete; I'd recommend replacing them all with the URL.

> Well, there is a difference between "any cost" and "not bothering maintainers with code they do not actually maintain".


I believe maintainers have to bother themselves with all code in their tarballs; if they don't, they may end up distributing proprietary software and even having their users sued for illegally distributing proprietary software.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Mon 03 Dec 2018 04:28:30 PM UTC, comment #35: 

> WRT the extremity---I don't think I see the point very well


Well, it was about “a difference between "University of Edinburgh, UK\n Copyright 1999" and "Copyright 1999 University of Edinburgh, UK".”, and the gettext part.

> That's easy: the latter is legally valid, the former is not


Uh. I didn't even imagine that. That's good to know, and should probably be added to https://savannah.gnu.org/maintenance/ValidNotices/

> The guidelines explain in detail that every file should have the notices


Yes, but maintainers will understand that for their own files, not files introduced by autotools & gettext, which maintainers don't have maintenance power on (except just not using them, which I could partly revert to because it didn't have actual impact, but if I had to completely scratch using gettext, I'd then not be respecting the GNU Coding Standards).

> > ...and this is not a way to get more people into free software
> Our primary goal is not getting more people into free software. That would be nice, but we don't want it at any cost.


Ok. Well, there is a difference between "any cost" and "not bothering maintainers with code they do not actually maintain".

Getting back to the case at stake, I believe the current code status, uploaded on http://dept-info.labri.fr/~thibault/tmp/speechd.tgz  ,  was fixed according to the comments?

Samuel Thibault <sthibaul>
Mon 03 Dec 2018 04:15:46 PM UTC, comment #34: 

First, sorry for the long delay.

>  I have discussed this very evening with another GNU maintainer... He ended up giving up when faced with the requested extreme enforcement of Savannah guidelines. That's no good news when GNU maintainers themselves end up like this.


I agree. GNU maintainers should follow these guidelines (at the very least, when maintaining their GNU software), whether on Savannah or anywhere else.

WRT the extremity---I don't think I see the point very well. The guidelines explain in detail that every file should have the notices, and what they should look like. I see nothing that could be interpreted like "this kind of copyrightable files needs no notices at all" or "lines like 'Авторское право Имярек' will do for the copyright statement".

> ...and this is not a way to get more people into free software.


Our primary goal is not getting more people into free software. That would be nice, but we don't want it at any cost.

>  I don't see a difference between "University of Edinburgh, UK\n Copyright 1999" and "Copyright 1999 University of Edinburgh, UK".


That's easy: the latter is legally valid, the former is not. Substantially, the university may be just the publisher rather than the copyright holder (in many universities, the authors don't transfer their copyright to the institute).

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Thu 29 Nov 2018 07:18:00 PM UTC, comment #33: 

Just to complete: I have discussed this very evening with another GNU maintainer who tried some time ago to get some software on nongnu.sv.org. He ended up giving up when faced with the requested extreme enforcement of Savannah guidelines.  That's no good news when GNU maintainers themselves end up like this.  I'm extremely patient so I can put up with this, but not everyone is.

Put another way: “you even wouldn't think about following them unless you believed that it's necessary for your package in order to pass the approval stage”: it's more “extremely few people would, and I am just patient here”, and this is not a way to get more people into free software.

Samuel Thibault <sthibaul>
Thu 29 Nov 2018 06:31:25 PM UTC, comment #32: 

> now you basically say that they are so absurd


No, I am fine with the Savannah policies, I completely agree with free software and that's why I took the time to make all the changes, it does make sense to put coypright notices where it is due.

What I am saying is that I find the enforcement at the edge of absurd.  I don't see a difference between "University of Edinburgh, UK\n Copyright 1999" and "Copyright 1999 University of Edinburgh, UK".  But since it's actually easy to change, I won't bother trying to fight, I'll just stick with absurd changes if that can get speechd in, as long as it doesn't hurt users.

What I however want to say is that this kind of extremism can't be helping to get people into free software, when even people already very much into free software such as myself find it hard to comply with so strict applications of free guidelines.

Samuel Thibault <sthibaul>
Thu 29 Nov 2018 04:37:13 PM UTC, comment #31: 

> Anyway, I guess it can't be helped, you won't change your mind.


This is unfortunate. I'll try to explain.

When registering your project on Savannah, you said you agreed to adhere to Savannah policies, and now you basically say that they are so absurd that you even wouldn't think about following them unless you believed that it's necessary for your package in order to pass the approval stage.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Tue 27 Nov 2018 12:25:36 PM UTC, comment #30: 

Anyway, I guess it can't be helped, you won't change your mind. I have added support for comments in test files, added copyright&licence notices to them, to .conf files, fixed the statements in symbols.dic, manpages, and festival_client, and refreshed

http://dept-info.labri.fr/~thibault/tmp/speechd.tgz

As I know of, only the following files don't have their own copyright&licence notices:

trivial files:
config/clients/emacs.conf
doc/stamp-1
doc/stamp-vti
doc/version-2.texi
doc/version.texi
po/LINGUAS
po/POTFILES.in
po/README
po/stamp-po
src/api/python/speechd/paths.py.in
src/api/python/speechd_config/paths.py.in

Binary files, documented in corresponding README:
doc/figures/*
src/api/python/speechd_config/test.wav
src/modules/dummy-message.wav
po/*.gmo

Samuel Thibault <sthibaul>
Mon 26 Nov 2018 04:46:28 PM UTC, comment #29: 

> src/modules/festival_client.{c,h} have no valid copyright line.


Well, it's copyright University of Edinburgh. Do I really have to switch or merge the two lines to get the name of the University after "Copyright (c) 1999" ?

> Many tests are in text form, copyright and license notices should be embedded in them. README is only a fallback for formats that don't allow comments.


The test format does not allow comments, it's not just "text form".

> Likewise files in config/modules like config/modules/ivona.conf


Eerrr, is it really a good thing to clutter configuration files with copyright statements? That will only confuse users...

Samuel Thibault <sthibaul>
Mon 26 Nov 2018 04:38:07 PM UTC, comment #28: 

In the copyright line in locale/cs/symols.dic, years are missing.

In src/api/python/speechd_config/spd-conf.1, license notice should be more specific about the version, i.e. "...v2 or (at your option) any later version..."; some man pages have two license and two copyright statements, it would be better to leave just one set.

src/modules/festival_client.{c,h} have no valid copyright line.

Many tests are in text form, copyright and license notices should be embedded in them. README is only a fallback for formats that don't allow comments.

Likewise files in config/modules like config/modules/ivona.conf; please look into other files as well, I didn't run a complete check.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Mon 26 Nov 2018 01:12:14 PM UTC, comment #27: 

Just to make sure: do I need to do anything else at this stage? AFAIK all raised issues have been addressed.

Samuel Thibault <sthibaul>
Tue 20 Nov 2018 06:20:11 PM UTC, comment #26: 

> As seen from outside, the current situation (just following the GNU Coding Standards, but then being rejected from savannah due to issues in existing GNU packages) looks very incoherent and doesn't help promoting the GNU goals.


I agree.

> ...savannah administrators... should make sure, by submitting appropriate bug reports, that the GNU hello package always follows the savannah policies...


Thank you, I shall.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sun 18 Nov 2018 12:26:22 PM UTC, comment #25: 

> it isn't clear for me how it turned out that files like po/de.gmo still lack copyright and license notices.


That's because I have basically never seen a single source tarball put copyright and license notices there. Anyway, I have now added a po/README note there, and uploaded to http://dept-info.labri.fr/~thibault/tmp/speechd.tgz

To tell the truth, I am really surprised by all these problems around gettext. I mean, this can't be the first package being submitted to savannah which contains gettext translations which pose these ground license and copyright questions.

Put another way, for somebody who wants to create a package following the GNU recommendations, she would notably take the GNU hello package as an example, since it's meant to be that, and thus use gettext, and then fall in all the traps we have been discussing recently. GNU hello and everything that it uses really needs to be fixed, otherwise one can not hope to see anybody be able to submit a package to savannah.

I know you said you are just requesting to follow Savannah policies, but the Savanah policy are part of the general GNU project. As seen from outside, the current situation (just following the GNU Coding Standards, but then being rejected from  savannah due to issues in existing GNU packages) looks very incoherent and doesn't help promoting the GNU goals.

I'm not saying that the savannah administrators should fix all packages themselves, or even fix the GNU hello package themselves, but they should make sure, by submitting appropriate bug reports, that the GNU hello package always follows the savannah policies, so it can be taken as an example which respects all policies. You can not expect newcomers to have to do this, that'd not a way to greet them to the GNU project.

Samuel Thibault <sthibaul>
Sun 18 Nov 2018 10:12:32 AM UTC, comment #24: 

Oh, sorry.

But then it isn't clear for me how it turned out that files like po/de.gmo still lack copyright and license notices.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sat 17 Nov 2018 06:16:15 PM UTC, comment #23: 

I already did before making the last upload.

Samuel Thibault <sthibaul>
Sat 17 Nov 2018 06:08:19 PM UTC, comment #22: 

Excellent; please check again for files with missing copyright and license notices.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sat 17 Nov 2018 06:06:01 PM UTC, comment #21: 

> I'd like to understand: did you make sure they won't show up again after the maintainer runs autoreconf next time?


Yes, this is done after the autoreconf invocation in the build.sh script

Samuel Thibault <sthibaul>
Sat 17 Nov 2018 05:52:33 PM UTC, comment #20: 

> Anyway, I have simply dropped these files from the tarball


Thank you! I'd like to understand: did you make sure they won't show up again after the maintainer runs autoreconf next time?

> you are asking me to do something that basically all other packages are not doing.


I'm asking to follow Savannah policies. All packages hosted on Savannah should follow them. If you know some packages that don't, it may be a reason to work with them on compliance, but not a reason to accept new packages that don't comply.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Thu 15 Nov 2018 04:32:52 PM UTC, comment #19: 

>  I'm asking you to comply with general Savannah policies. It's you who says that gettext should be fixed in order for you to do that.


I'm not a maintainer of gettext, so I can't fix it myself.

Anyway, I have simply dropped these files from the tarball, here is the result: http://dept-info.labri.fr/~thibault/tmp/speechd.tgz

>  You are not responsible for other packages. I only ask you to take responsibility for yours.


Sure, but you are asking me to do something that basically all other packages are not doing. Such kind of situation is really not a way to attract people to free software.

Samuel Thibault <sthibaul>
Thu 15 Nov 2018 04:09:38 PM UTC, comment #18: 

> You must be joking?


Not really.

> To get a project accepted on non-gnu.org, you are asking me to fix a GNU project which is recommended by the GNU Coding Standards themselves?


I'm asking you to comply with general Savannah policies. It's you who says that gettext should be fixed in order for you to do that.

> How many projects on nongnu.org and gnu.org are following the GNU Coding Standards and are thus already using gettext and are thus hit by exactly the same issue?


You are not responsible for other packages. I only ask you to take responsibility for yours.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Thu 15 Nov 2018 03:53:20 PM UTC, comment #17: 

> Then please fix it in gettext.


You must be joking?

To get a project accepted on non-gnu.org, you are asking me to fix a GNU project which is recommended by the GNU Coding Standards themselves?

How many projects on nongnu.org and gnu.org are following the GNU Coding Standards and are thus already using gettext and are thus hit by exactly the same issue?

Samuel Thibault <sthibaul>
Thu 15 Nov 2018 03:48:05 PM UTC, comment #16: 

> for the source after autostuff file generation it's on http://dept-info.labri.fr/~thibault/tmp/speechd-autostuff.tgz


This is what we want. We are looking into distribution tarballs, not just "source". In particular, a copy of the license is hardly a part of the source, but we do make sure that it is included.

> ...but that has to be fixed in gettext...


Then please fix it in gettext.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Wed 14 Nov 2018 07:01:50 PM UTC, comment #15: 

Ergl, sorry, for the source after autostuff file generation it's on http://dept-info.labri.fr/~thibault/tmp/speechd-autostuff.tgz

Samuel Thibault <sthibaul>
Wed 14 Nov 2018 07:00:44 PM UTC, comment #14: 

To make it simpler, I have put on http://dept-info.labri.fr/~thibault/tmp/speechd.tgz the source before autostuff file generation, i.e. really the pure speech-dispatcher source files.

AFAIK, the only files which don't have copyright and license notices there are

po/LINGUAS
po/POTFILES.in
config/clients/emacs.conf
src/api/python/speechd/paths.py.in
src/api/python/speechd_config/paths.py.in

which are trivial files.

For reference, I have put on http://dept-info.labri.fr/~thibault/tmp/speechd.tgz the source after autostuff file generation and make dist. There are indeed some files which don't look very trivial to me (or even not trivial at all) and don't have copyright notices, but that has to be fixed in gettext, it's not coming from the speech-dispatcher source:

./po/remove-potcdate.sin
./po/quot.sed
./po/boldquot.sed
./po/en@quot.header
./po/en@boldquot.header
./po/insert-header.sin
./po/Rules-quot
./ABOUT-NLS

Samuel Thibault <sthibaul>
Wed 14 Nov 2018 06:08:10 PM UTC, comment #13: 

AFAIK, now really all files (not generated by gettext such as po/boldquot.sed, by autoconf such as config.h.in, etc. and not trivial such as config/clients/emacs.conf) have copyright and licence notices, so please be more specific.

> however, it looks like you tarball contains no copy of the LGPL.


D'oh, the file was in the upstream repo, but was missing in the Makefile.am dist rule.

I have fixed that and updated gpl.texi on http://dept-info.labri.fr/~thibault/tmp/speechd.tgz

Samuel Thibault <sthibaul>
Wed 14 Nov 2018 04:52:12 PM UTC, comment #12: 

Thank you!

Some files in your tarball still have no copyright and license notices; also, files like src/audio/oss.c are licensed under the LGPL v2.1+, however, it looks like you tarball contains no copy of the LGPL.

While at it: you could also update your Texinfo copy of the GPLv2 from https://www.gnu.org/licenses/old-licenses/gpl-2.0.texi.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Tue 13 Nov 2018 04:15:08 PM UTC, comment #11: 
Samuel Thibault <sthibaul>
Tue 13 Nov 2018 03:47:40 PM UTC, comment #10: 

doc/figures/README says,

The source files for these figure files are

architecture-future.flw
architecture.dia
priorities.dia

That's good, but then it continues, "Other files are generated from them."

Could you list those other files?

Also, I'd recommend updating your copy of the GPL from https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Mon 12 Nov 2018 05:59:19 PM UTC, comment #9: 
Samuel Thibault <sthibaul>
Mon 12 Nov 2018 05:18:39 PM UTC, comment #8: 

Well, there is also src/modules/dummy-message.wav and src/tests/yo.wav, I'll add them too.

Samuel Thibault <sthibaul>
Mon 12 Nov 2018 05:06:42 PM UTC, comment #7: 

Have you checked other files? I didn't scan them all.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Mon 12 Nov 2018 04:43:14 PM UTC, comment #6: 

I have updated http://dept-info.labri.fr/~thibault/tmp/speechd.tgz with an additional README file in doc/figures/ for the notices.

Samuel Thibault <sthibaul>
Mon 12 Nov 2018 04:31:52 PM UTC, comment #5: 

Thank you!

Some files in doc/figures still lack copyright and license notices. When file format doesn't allow such embedded comments, the files with their respective notices should be listed in a README in the same directory.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sun 11 Nov 2018 10:01:54 PM UTC, comment #4: 

I have fixed the symbols.dic notices, added notices in README etc. and uploaded to

http://dept-info.labri.fr/~thibault/tmp/speechd.tgz

Samuel Thibault <sthibaul>
Sun 11 Nov 2018 06:56:49 AM UTC, comment #3: 

locale/hr/symbols.dic, locale/sr/symbols.dic, locale/zh_CN/symbols.dic, locale/ka/symbols.dic, locale/zh_TW/symbols.dic and some other files still lack copyright notices; "NVDA contributors" is a poor specification of a copyright holder, it's almost a tautology because many contributors even aren't listed in AUTHORS.

Files like README.overview.md lack both copyright and license notices.

Please check all copyrightable files in your tarball again.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Fri 09 Nov 2018 01:23:44 AM UTC, comment #2: 

Hello,

I have added the missing copyright + license notices and added the information about the dotconf LGPLv2.1-only limitation, I have uploaded it on https://github.com/brailcom/speechd/releases/download/0.9.0-rc1/speech-dispatcher-0.9.0-rc1.tar.gz

Samuel Thibault <sthibaul>
Sun 04 Nov 2018 10:29:05 AM UTC, comment #1: 

Hello, Samuel!

Please make sure that all copyrightable files have valid copyright and license notices.  Make sure to use the canonical form of the license notices, lines like "This file is covered by the GNU General Public License" won't do.

Then, note that dotconf is LGPLv2.1-only.  This is GPLv2+-compatible, so we can host packages with such dependencies on Savannah, but you may need to clarify licensing terms of some parts of your package.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Mon 29 Oct 2018 04:36:41 PM UTC, original submission:  

A new project has been registered at Savannah
This project account will remain inactive until a site admin approves
or discards the registration.

Registration Administration

While this item will be useful to track the registration process,
approving or discarding the registration must be done using the specific Group Administration page, accessible only to site administrators,
effectively logged as site administrators (superuser):

Registration Details

  • Name: Speech Dispatcher
  • System Name:  speechd
  • Type: non-GNU software and documentation
  • License: GNU General Public License v2 or later (The server part is licensed under GPL v2+. The client part is licensed under LGPL v2.1+.)

Description:

Speech Dispatcher project provides a high-level device independent layer for access to speech synthesis through a simple, stable and well documented interface.

It is architectured with a client/server approach: applications use the libspeechd (LGPL) to connect to the server which supports the different speech syntheses in different modules.

The server it written in C, the client part is available in C, common lisp, guile, and python. It is mostly used on GNU/Linux, but can work on other Unix-like platforms as well

Other Software Required:

libtool, automake, autoconf, gettext,

glib-2.0, gthread-2.0, gmodule-2.0, LGPL v2+, http://www.gtk.org/

dotconf, LGPL v2.1+ https://github.com/williamh/dotconf/ , https://github.com/williamh/dotconf/blob/master/COPYING

sndfile, LGPL v2.1+ https://github.com/erikd/libsndfile/ , https://github.com/erikd/libsndfile/blob/master/COPYING

Everything else (speech syntheses, output audio, etc.) is optional.

Other Comments:

The project was initially hosted at the brailcom company, but is currently moving to more free platform, it is currently hosted on https://github.com/brailcom/speechd/

Tarball URL:

http://dept-info.labri.fr/~thibault/tmp/speechd.tgz

Samuel Thibault <sthibaul>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by sthibaul (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-29 ineiev StatusIn Progress => Done
        Open/ClosedOpen => Closed
    2018-11-04 ineiev StatusNone => In Progress
        Assigned toNone => ineiev

    Back to the top


    Powered by Savane 3.5