Project status?

28 views
Skip to first unread message

Brandon Fosdick

unread,
Sep 16, 2011, 9:49:38 PM9/16/11
to qextser...@googlegroups.com
Recently I've been trying to use qesp for a real project and I've found the code to be a terrible mess. This has been known for awhile now, but I didn't realize that it's nearly unusable (I haven't looked at it in quite some time). I was about to sit down and start fixing things, but that led me to wonder about the status of the project and whether or not it's worth continuing. 

I haven't seen any traffic on this list in some time, and the last commit was well over a year ago. I know there were some patches submitted that were never incorporated. I remember talk of the project being merged into Qt proper, but it seems nothing happened on that front. There's a QSerialPort project on gitorious already, although it appears to be similarly unmaintained. And, with Qt's fate still in the air, it's hard to know what to make of all of this.

So what do we do? I'm willing to put some effort into cleaning up the library if that's the right thing to do. Maybe even formally submitting it as a change request to the Qt project. I'm also open to adding some more admins to the project if there are willing volunteers. Of course, we can also shutter this project in favor of something else. 

If the qesp project does continue I'm in favor of moving primary development to someplace that can facilitate push/pull requests. GCode doesn't help with accepting patches from contributors, and it's something that github does a lot better. With that said, I think this project's home has moved too many times already and I'd rather not move it again.

What say the group?



Lisandro Damián Nicanor Pérez Meyer

unread,
Sep 16, 2011, 10:07:02 PM9/16/11
to qextser...@googlegroups.com, Brandon Fosdick
On Vie 16 Sep 2011 22:49:38 Brandon Fosdick escribió:
[snip]
> What say the group?

My main concern has been (and it keeps being) it's license status. You may
want to see [0] for a previous discussion on the matter. Public domain is not
that easy as it may first seem, specially if the author are from the EEUU.
Also the license it's not stated anywhere in the source.

If those two things could be solved, then we could happily give some life back
to this project.

Kinds regards, Lisandro.

[0]
<http://groups.google.com/group/qextserialport/browse_thread/thread/e8756920b01da82?pli=1>

--
Dadme voto electrónico y con una terminal os haré presidente.
el.machi

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

signature.asc

Liam Staskawicz

unread,
Sep 17, 2011, 11:49:35 AM9/17/11
to qextser...@googlegroups.com
I apologize for not having had more time to work on it recently. I agree that the code has always been a bit of a mess (sorry for any I added) - I wouldn't mind helping out with some serious house cleaning either.

With regard to the license, let's just change it to Apache 2.0 or MIT and call it a day :)

Liam

Lisandro Damián Nicanor Pérez Meyer

unread,
Sep 17, 2011, 1:04:58 PM9/17/11
to qextser...@googlegroups.com, Liam Staskawicz
On Sáb 17 Sep 2011 12:49:35 Liam Staskawicz escribió:
> I apologize for not having had more time to work on it recently. I agree
> that the code has always been a bit of a mess (sorry for any I added) - I
> wouldn't mind helping out with some serious house cleaning either.
>
> With regard to the license, let's just change it to Apache 2.0 or MIT and
> call it a day :)

That and putting it explicitely in the sources will definetely make my day :)

Kinds regards, Lisandro.

--
mathematician, n.:
Some one who believes imaginary things appear right before your i's.

signature.asc

Brandon Fosdick

unread,
Sep 17, 2011, 9:34:14 PM9/17/11
to qextser...@googlegroups.com
After looking over the code a bit, I think the level of cleaning required is on par with a complete rewrite. If we do that we can set whatever license we want without having to worry about the past. Either way, we should probably wait until Qt's new contributor guidelines are posted and see what licensing they want. Hopefully they won't require GPL.


--
You received this message because you are subscribed to the Google Groups "qextserialport" group.
To post to this group, send email to qextser...@googlegroups.com.
To unsubscribe from this group, send email to qextserialpor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/qextserialport?hl=en.

Angel Perles

unread,
Sep 18, 2011, 9:44:05 AM9/18/11
to qextser...@googlegroups.com
> Brandon Fosdick <bfos...@gmail.com> Sep 17 06:34PM -0700 ^
> <#digest_top>

>
> After looking over the code a bit, I think the level of cleaning
> required is on par with a complete rewrite. If we do that we can
> set whatever license we want without having to worry about the
> past. Either way, we should probably wait until Qt's new
> contributor guidelines are posted and see what licensing they
> want. Hopefully they won't require GPL.
>
>

Taking into consideration that Lian is here, it's now the moment to he
put some license in the code. As Lisandro states, that and putting it
explicitely in the sources also make my day.

Others could then start incorporating patches and rewriting code, and
this excellent project can continue.

Do not wait Qt licensing. The license could be changed in the future.

There are too much patches and mirros over there for this project, so
the licensing issue can help a merge.

Regards,
Àngel

Lisandro Damián Nicanor Pérez Meyer

unread,
Sep 18, 2011, 1:35:55 PM9/18/11
to qextser...@googlegroups.com, Angel Perles
On Dom 18 Sep 2011 10:44:05 Angel Perles escribió:
[snip]
> Taking into consideration that Lian is here, it's now the moment to he
> put some license in the code. As Lisandro states, that and putting it
> explicitely in the sources also make my day.
>
> Others could then start incorporating patches and rewriting code, and
> this excellent project can continue.
>
> Do not wait Qt licensing. The license could be changed in the future.
>
> There are too much patches and mirros over there for this project, so
> the licensing issue can help a merge.

I do totally agree with Angel :)

--
Si vives cada día de tu vida como si fuera el último,
algún día realmente tendrás razón.
Steve Jobs

signature.asc

Brandon Fosdick

unread,
Sep 29, 2011, 1:43:31 PM9/29/11
to qextser...@googlegroups.com
I would vote for BSD or MIT :)

However, there is the issue of relicensing code without getting consent from all contributors. Doing it unilaterally is very tempting, but we should probably play it safe. That's why I was suggesting a rewrite.  The code is messy enough to actually warrant starting over and it would neatly solve the relicensing issue.


On Sep 17, 2011, at 08:49 , Liam Staskawicz wrote:

Liam Staskawicz

unread,
Sep 29, 2011, 2:01:40 PM9/29/11
to qextser...@googlegroups.com
That works for me - let's call it MIT and go for it :)

I have some code lying around that would make the windows async stuff much nicer, using completion ports, so that could be one nice improvement.

Liam

1+1=2

unread,
Nov 9, 2011, 5:13:48 AM11/9/11
to qextser...@googlegroups.com
Hello everyone,

I have make some code refactoring for QextSerialPort, you can find it under

http://code.google.com/r/dbzhang800-qextserialport/

1. D-pointer and Q_PRIVATE_SLOT are used to moving private members
from QextSerialPort to QextSerialPortPrivate

2. qdoc3 instead of doxygen is used for generating documents

3. MIT license header add to all sources files

4. add a helper class QextWinEventNotifier for windows user, when
user's SDK doesnot contains Qt's private files, this class will be
auto selected.

5. source compatible with old versions.

6.

Usage

The package contains a qextserialport.pri file that allows you to
integrate the component into programs that use qmake for the build
step.

All you need is adding following line to your qmake project file:

include(pathToPri/qextserialport.pri)

Using QexSerialPort library

Although QextSerialPort can be directly compiled into your
application, You may prefer to use QextSerailPort as an library, which
is very easy too.

1. Write a config.pri file.(read config_example.pri for reference):

shared library
static library

2. Changed to subdirectory 'buildlib', run

qmake
make

shared or static library will be generated.

3. Add following line to your qmake project file:

include(pathToPri/qextserialport.pri)

Build documents

Run qdoc3 from the doc directory.

qdoc3 qextserialport.qdocconf

Lisandro Damián Nicanor Pérez Meyer

unread,
Feb 3, 2012, 2:42:12 PM2/3/12
to qextser...@googlegroups.com, Liam Staskawicz
On Thu 29 Sep 2011 15:01:40 Liam Staskawicz escribió:
> That works for me - let's call it MIT and go for it :)
>
> I have some code lying around that would make the windows async stuff much
> nicer, using completion ports, so that could be one nice improvement.
>
> Liam
>
> On Thu, Sep 29, 2011 at 10:43 AM, Brandon Fosdick <bfos...@gmail.com>wrote:
> > I would vote for BSD or MIT :)
> >
> > However, there is the issue of relicensing code without getting consent
> > from all contributors. Doing it unilaterally is very tempting, but we
> > should probably play it safe. That's why I was suggesting a rewrite.
> > The code is messy enough to actually warrant starting over and it would
> > neatly solve the relicensing issue.
> >
> > On Sep 17, 2011, at 08:49 , Liam Staskawicz wrote:
> > I apologize for not having had more time to work on it recently. I agree
> >
> > that the code has always been a bit of a mess (sorry for any I added) - I
> > wouldn't mind helping out with some serious house cleaning either.

OK, I'm tempted to start a rewrite myself, but I will only be able to do it
under Linux, as it's the only OS I'm using.

Also there is the chance to do a relicensing call: we can send a notice that
we are going to change the code to Expat/MIT license [0] in a month. If no one
complains, we can freely switch.

What do you think? For me, it's either now or switch to something else, do it
right and stop rewriting the same tool.

[0] <http://www.jclark.com/xml/copying.txt>

Kinds regards, Lisandro.

signature.asc

Márton Miklós

unread,
Feb 4, 2012, 5:09:37 AM2/4/12
to qextser...@googlegroups.com
Hello,

Someone sent a message to the mailing list that he refacotred the code:
http://code.google.com/r/dbzhang800-qextserialport/
it might be a better starting point.

Regards,
Miklï¿œs


2012-02-03 20:42 keltezï¿œssel, Lisandro Damiï¿œn Nicanor Pï¿œrez Meyer ï¿œrta:
> On Thu 29 Sep 2011 15:01:40 Liam Staskawicz escribiᅵ:

Lisandro Damián Nicanor Pérez Meyer

unread,
Feb 4, 2012, 8:49:32 AM2/4/12
to qextser...@googlegroups.com
On Sáb 04 Feb 2012 07:09:37 Márton Miklós escribió:
> Hello,
>
> Someone sent a message to the mailing list that he refacotred the code:
> http://code.google.com/r/dbzhang800-qextserialport/
> it might be a better starting point.

The licensing problem remains as it's a derived work.

License stuff is f#2·$%"·$ (funny) sometimes :-)

Kinds regards, Lisandro.

--
"Any sufficiently advanced technology is indistinguishable from magic"
Arthur C. Clarke

signature.asc

Thomas J. Webb

unread,
Feb 11, 2012, 2:45:26 PM2/11/12
to qextserialport
BSD or MIT work for me. GPL definitely wouldn't and lGPL could be
problematic for mobile devices unless it contains a static linking
exemption (i.e., wxWindows license rather than proper lGPL). More
liberal licenses like BSD or MIT are best because it allows for it to
be reappropriated into Qt later.

I am willing to help with coding or even some financial assistance
because my software that customers are using uses this lib. I'm having
a big issue right now (which I will describe in a subsequent post to
not confuse this thread) that /might/ be due to a bug in
qextserialport. Since I'm desperate right now, I might even write a
minimal lib for my own use in the meantime but I really do like some
of the features of this lib, like the realtime detection of serial
ports.

-Thomas

On Feb 3, 11:42 am, Lisandro Damián Nicanor Pérez Meyer
<perezme...@gmail.com> wrote:
> On Thu 29 Sep 2011 15:01:40 Liam Staskawicz escribió:
>
>
>
> > That works for me - let's call it MIT and go for it :)
>
> > I have some code lying around that would make the windows async stuff much
> > nicer, using completion ports, so that could be one nice improvement.
>
> > Liam
>
> > On Thu, Sep 29, 2011 at 10:43 AM, Brandon Fosdick <bfosd...@gmail.com>wrote:
> > > I would vote for BSD or MIT :)
>
> > > However, there is the issue of relicensing code without getting consent
> > > from all contributors. Doing it unilaterally is very tempting, but we
> > > should probably play it safe. That's why I was suggesting a rewrite.
> > > The code is messy enough to actually warrant starting over and it would
> > > neatly solve the relicensing issue.
>
> > > On Sep 17, 2011, at 08:49 , Liam Staskawicz wrote:
> > >  I apologize for not having had more time to work on it recently. I agree
>
> > > that the code has always been a bit of a mess (sorry for any I added) - I
> > > wouldn't mind helping out with some serious house cleaning either.
>
> OK, I'm tempted to start a rewrite myself, but I will only be able to do it
> under Linux, as it's the only OS I'm using.
>
> Also there is the chance to do a relicensing call: we can send a notice that
> we are going to change the code to Expat/MIT license [0] in a month. If no one
> complains, we can freely switch.
>
> What do you think? For me, it's either now or switch to something else, do it
> right and stop rewriting the same tool.
>
> [0] <http://www.jclark.com/xml/copying.txt>
>
> Kinds regards, Lisandro.
>
> --
> Dadme voto electrónico y con una terminal os haré presidente.
>   el.machi
>
> Lisandro Damián Nicanor Pérez Meyerhttp://perezmeyer.com.ar/http://perezmeyer.blogspot.com/
>
>  signature.asc
> < 1KViewDownload
Reply all
Reply to author
Forward
0 new messages