With GTK3 being limited to Gnome and only for “small apps”, Qt is used much more than before and a Qt-based DE like LXQt (is there another one?) will become more important than ever.
However, LXQt has only a few active developers. Some of its previous competent developers have left it apparently and some aren’t active anymore. There are lots of features to add and, IMO, lots of bugs to fix. Realistically, the current active devs won’t be able to do that – each day has only 24 hours – I extend it to 25 by magic – and only a small part of it may be what we call “free time”.
Is there any chance to change this situation? Or should we accept the status quo and develop LXQt one bit at a time?
I can volunteer my time to work on stuff, but one thing that has always been unclear to me has been roadmaps which are pretty vague. There’s no “release date” and we just tag all of the issues with the next release. Oh, and not-so-easy ones? Yeah, let’s just tag those with 1.0. We’ll get to those “some day.”
In my honest opinion, that organizational structure is asinine if we want actual productivity.
If there was an actual deadline or actual, specific roadmaps, you’d see me much more involved. Smaller releases with specific goals would help too, not just one big release once every year.
If anything though, that would also make it easier for distributors (that aren’t Debian who don’t really care about having quick releases). Right now I carry about ten patches for some of the LXQt packages in Ubuntu because these upstream fixes won’t hit an actual release for months now.
If it sounds like I’m frustrated, it’s because I am. If I can help organize these issues, I’ll be happy to. But jeez, these huge releases are killing us.
@tsujan - maybe we do some things wrong - one of these things might be that we don’t speed up some things outside of our programming tasks. Some points like infrastructure
this forum - ok, it will go live with the release of 2.0 finally - when ever that will be, we are on beta4 now
translation system: @pmattern is MIA again - ok, to be true about, this don’t help, it will slow down things until the forum is up
with the forum up we should move to our own channels, i would suggest OFTC #lxqt as main and freenode #lxqt as backup - but this need to be communicated and coordinated - best in the forum
also with the forum up we should move our repos to github.com/lxqt - to be more visible as an independed project
Maybe an own blog - should be no problem if someone would take care of it - imho it is not the best idea to share the LXDE-Blog and do nothing in that regard in the past year
SPI Membership - we should really do this
To sum it up - we should invest more time in our public profile and our visibility, stepwise. And we should roll a new release out asap. The only thing i really don’t know right now: Is it really needed to have a libfm release before? There were some new functionalities that will need one i guess - if so, how can we speed up this needed release?
Second thought: If we are really blocked by libfm - whats about alternatives. I don’t want to depend on things were we are forced to beg, it really sucks - and yes i’m frustrated too.
@tsimonq2 - Sorry, but i have to mention it: Maybe the better way to speed up things would be to use your time and influence to remove blockers (libfm anyone again) instead of writing nice insulting changelog entries. But maybe you are right and software development really works that way.
If @pmattern decides to be MIA, then we should proceed without him. When he comes back, if he wants to participate, that’s up to him.
If others don’t want to pick up where they left off, I will.
Let’s not bikeshed it. That sounds good to me. The topic is already set in #lxqt on OFTC. Let’s do it.
If you object, speak now (well, 48 hours) or forever hold your peace. I can do this, and it isn’t going to be hard.
I can personally work on this. One thing that has been pointed out to me several times by others in the Linux community is how little the LXQt release announcements actually say. When we do a release, we should write something so that non-developers know what we’re talking about yet link to the pull requests closed (or something) so the developers can see what code changes were actually made.
Again, I can make these changes and take charge on this.
Sure, want to take that on?
That’s what I’m saying (and what I said in my first reply).
You haven’t read a single word I’ve written, have you?
That’s what I’m trying to do, I just don’t know the state of development because there is no “work towards release” and there are no “set goals” – there’s just one, slow pace, and I’m sorry if I haven’t taken the time to check in every so often on the turtle walking towards release. I guess I can look at what needs to be done and help where needed. In fact, now that you bring up clear objectives, I’ll work on them. Thank you, I appreciate it.
And about the changelogs – how I express my dislike for the release schedule of LXQt is irrelevant. What is relevant is that I am delivering these important fixes to my users. This is something we need to fix in upstream LXQt – a faster way to get fixes out to users. Even if we do a release every three months instead of nine, it’s much better than one yearly, huge release.
To sum it up - we should invest more time in our public profile and our visibility
These are wise words to me. The more LXQt is known and used, the more chance for new developers to join us. We need more releases after fixing important bugs and/or implementing exciting features. Many people rely on the latest packages of their distros and distros wait for releases.
If there was an actual deadline or actual, specific roadmaps, you’d see me much more involved.
I’m not the best person to expound on that. Personally, I find my way wildly, with no concern for deadlines or roadmaps; users tell me about new features and sometimes, features come out and tell me, “implement us!” I’ve seen other developers who do the same, namely, coding out of fun. Deadlines aren’t fun. Anyhow, my opinion on this isn’t based on facts and can be ignored.
In short, we need more users, IMO. Please consider releasing new versions much more frequently!
As for libfm, yes its way of maintenance has been a blocker for a long time. As a member, the only thing I can do is ranting, which I’ve done self-consistently The good news is that this blocker doesn’t block everything; it’s limited to pcmanfm-qt.
Let’s be pragmatic and not waste our time by fighting with each other. We could do that later, after some real jobs are really done
I think we really need to pick up the pace and I am happy to help do this because there are distros waiting on us.
Good words! Distros mean more frequent releases. I think we’ve reached a conclusion here.
I re-read your comments and the same word comes to my mind: “releases”.
LXQt is alive because, although we aren’t many, we do our jobs. Releases will tell users about that. I remember that, the first time I tried LXQt, I didn’t compile it from the git sources but installed siduction packages (made by Alf?) because Debian lacked a reliable LXQt support. If I did that, what could I expect from others?
Sorry to add 3 boring comments one after the other (the forum tells me not to do that) but I’d like to mention a fact I’ve found interesting for a long time. Please take a look at https://download.enlightenment.org/rel/apps/enlightenment/ . I compile E, once in a while, because stable releases are made in short intervals – although they aren’t really stable
You are right, the whole LXQt packaging was started in siduction - and back in 2015 i get a ping from Andrew Lee to join him at the Debconf 2015 in Heidelberg/Germany. That was the start for LXQt/Debian. So the base of all things that are now in Debian/Dervatives was written from the scratch right from the beginning of LXQt by me - and it was a long hard way.
Regarding the pace: A point release was planned for February - we can roll out what we have now, except pcmanfm-qt. Unfortunatly pcmanfm-qt is the most prominent and visible part of LXQt. So our main goal has to be to become independent of libfm - just removing the blockers step by step. Right now i see two major annoyances in the whole LXQt development: menu-cached and libfm - menu-cached is still crashing (the infamous 1:30 at restarts and shutdowns) if not triggerd by lxqt-leave --$foo - and the state of libfm. All other things are cosmetics - nice to have, important to attract users and developers - but hey, what should these people think of us: All fine, nice project, but these guys are to blind or incompetent to solve restart issues for over a year or to speed up the release of their most important foreign library? Really?
Ok, one major issue is finally solved now - xdg-open, thanks god. Also fine is that i heared rumors that Qt 5.10 will enter sid soon. Next fine thing is that i talked with Mwei - we are allowed to “borrow” the LXDE-Blog so after a little bit of cleanup and a update dance we will have an working blog that can go to live immediately after the needed cleanup - with all the content relevant for LXQt in. Thats all for now, stay tuned.
@tsujan: Why three posts, you could have edit the initial one?
I might not know about LXQt without those siduction deb packages…
Why? As far as I remember, the changes made to libfm were backward compatible (I always try to do so). Therefore, not having a new release of libfm just means not having the fixes made to it. Those fixes were for bugs most users wouldn’t encounter. IMHO, pcmanfm-qt+libfm-qt need a new release.
That being said, isn’t there any way to bring libfm under our control? (Sorry, I don’t know how many times I’ve asked this question – it’s like a repeating nightmare). Most of the important patches were made by us; weren’t they? Am I right thinking that LXDE practically pays no attention to libfm?
Yes. For the time being, we have to either tolerate that or own libfm and menu-cahce; don’t know if the latter is possible.
Ok - if pcmanf-qt works with an older libfm - fine. The “under our control” thing is a little bit more complicated. It is not wise to dis-own the current maintainer who is also the maintainer in debian … - and there is another aspect: If we would do so we would likely kill the LXDE development completely. And i really don’t want to do this. In maybe clearer words: Even if we release libfm - i would not get it into debian without heavy fights - Ubuntu is a bit different. But for debian and it’s derivatives that would be a worst outcome i can think of - and i had a look at distrowatch again - it would be really bad. So i guess asking polite and offer help might be the better way
As a user who wants to be helpful if possible. I agree that it’s hard to tell when something’s going to happen with this project. I’ve followed it for a while now because I was looking forward to a qt based DE that would be good for older pcs and low performance stuff. Every now and then I look for updates and hear nothing, and wonder if the project is dead. Then a point release will come out, and I’ll get hopeful, but it after a week it’s ghost town again. I’ll look at github issues and see if something that bugs me is being taken care of, and find my issue in the issue tracker, and maybe some discussion, but no real “Okay, we’ll do this.” or “This’ll be fixed by xx.xx.” or even the admission that it won’t be fixed. So it’s hard to tell if it’s worth waiting for the next point release, or moving on, or hoping for updated in the next week.
As a person who wants to encourage use of software I think is good. It’s hard to encourage the use of a DE that I can’t get a feel for when/if it’s going to do something. I would like to move some people off of KDE that I support because KDE has some issues LXQt handles better, but some downfalls in LXQt that have been discussed in github’s issue tracker but don’t seem decided.
As a person who’s tried at programming attempts and failed horribly, I look to point people who are better at code at projects I like. I don’t have really good incentives for them to simply fix an issue I have in the project. This means I have to find a way to make the project interesting to them. This is hard when I can’t tell what things the project is focused on at the moment. So I can’t say things like, “LXQt wants to fix blarg for the next point release.” This is frustrating.
Tl;dr version Ya’ll are really just too quiet, make some noise. Don’t just make noise that you exist, make noise about what you really want to do with the project NEXT.
That was and is a hen and egg problem. As a small project we failed in the past to make more noise - now we found the time to finish some long standing things. We have the forum up and running, have our own github space, a blog etc. All not in the final shape, but as a good as a start.
Now we have these things and should and will use them - one of our problems was and is the lack of man power. And the next goal is to roll out the long planned release as fast as possible. There was some road blocks to do so - the most important blocker was Qt 5.10 - i wanted to release with 5.10.x general available and tested. Since last week we have it in Debian, so the block is removed. Next blocker was and is the libfm situation, still testing but on a good way.
With the upcoming release we will be able to make finer grained and realistic plans what to do next. And we now are able to communicate them - only github isn’t enoght to get wider attention. And a human readable roadmap would help too, full ack.