Next LXQT release? How do the releases work?

release

#1

I’ve been kind of lurking lately in the forum, and I’ve noticed that Agaida and Tsujan have been talking about how the git release is quite a bit ahead of the 0.13 release… I also heard about the new notification history panel applet, which i would love to see out in the wild. What’s holding up the release of 0.14.0 or 0.13.x?

Not sure how LXQT works, or how LXDE worked releases.


(Mark Rabideau) #2

Every opensource project is a bit different but here is a generic description that might help you:


(Pedram Pourang) #3

Work, which needs time. Even something as “simple” as release notes takes time.

I prefer more frequent releases but I know that’s not easy.


(Mark Rabideau) #4

@tsujan and @agaida if you are looking for testers, I’m happy to pitch in. I am willing to set up a testbench on a VirtualBox machine (manjaro preferred) to check both features and functions. I can offer limited technical analysis of problems encountered along with potential solutions. If you provide the test criteria, I am also happy to try and test to your defined requirements.


(Pedram Pourang) #5

That would be great!

Testing is a very important job. Previously, we had an active tester, who didn’t let us rest. His work was very valuable – precise, clear and detailed. Now, we should test everything ourselves. That’s possible because we use what we make but a professional tester sees hidden things.


(Mark Rabideau) #6

Perhaps if you (@tsujan) and/or @agaida let me know when your “git set” is ready for an external run… I’ll download it, build it and test it. If there is a laundry list of specific things you want tested, please let me know. Probably, the best way to contact me with specifics and not clutter the forums is via message on this site. If you need my email address for anything, I can provide one as well.

Here is a bit of information about my tech background and primary company:


(jubalh) #7

On openSUSE the download and build it parts are automatically done. We have devel project X11:LXQt:git which builds new packages upon every new commit to master. openSUSE users who have installed LXQt on their machine and want to switch to the git version just have to type:

zypper ar -f obs://X11:LXQt:git lxqtgit
zypper ref
zypper dup --from lxqtgit

And their packages are going to be upgraded. Like this it’s easy for people to test because all they have to do is do their normal distribution updates and they will always run the git version of LXQt.

It saves time and resources, you don’t have to manually check out the repos and build each of the components in the correct order. The OpenBuildService does all that for you.

I recommend you take a look at this.


(Mark Rabideau) #8

I don’t use Suse (open or otherwise) I need the instructions for either “arch” or a simple Linux build from source. So I guess a normal git command stream is best.


(Pedram Pourang) #9

With Arch/Manjaro, it’s the easiest. Arch has git packages, which can be built by using an AUR helper like yaourt (through Octopi, for example).


(Mark Rabideau) #10

@tsujan So I should be able find the most recent material in AUR then? I assume the build is labeled 0.14 or something similar. If it is there, are you guys through most of your unit test and looking for me to conduct Blackbox testing? If you are, I’ll commence and build the LXQt testbed with the current AUR build of LXQt.

Are there any specific (particular) items (areas) you want me to stress?

Edit: Okay I looked in AUR… I do not see a version 0.14 build or similar. I find a bunch of 0.13.0.4 0.13.0.5 and similar tagged items. Which ones should I incorporate in the test? I assume each one I use for the test will replace something in the normal LXQt 0.13 released build available in the manajaro repo.


(Pedram Pourang) #11

For example, if you want to have the latest git version of libfm-qt, you could just do:

yaourt -S libfm-qt-git

Of course, it’ll ask you some questions (about installing dependencies and other things).

The order of installation can be seen here: https://github.com/lxqt/lxqt/wiki/Building-from-source#generalbuild-order . So, you could start with libqtxdg.

AUR git PKGBUILDs download the latest git version. So, you could easily update your LXQt installation once in a while. Compilation of some packages may take a while, depending on your computer but the command you use is as simple as yaourt -S PACKAGE_NAME-git.


(Pedram Pourang) #12

For me, personally, pcmanfm-qt is more important because I work on it much more than on other components. But all LXQt components are important.


(Pedram Pourang) #13

Oh, I should write this in bold: Never upgrade LXQt partially. For example, an upgraded libfm-qt will break an older pcmanfm-qt. All components should be upgraded in the above-mentioned order.


(Alf Gaida) #14

I’m not an primary arch user - but @tsujan mentioned yaourt - if one don’t want to build it manually - add the france mirror and install it with pacman -S yaourt


(Mark Rabideau) #15

The issue with yaourt is that it is deprecated. I’ll try to see if pacman, pacui, yay or trizen will do the trick.

I am a bit concerned that I won’t know where bugs occur if I’m not testing an identifiable build unit. If I build things piecemeal (manually or otherwise), how will you know where I’m finding errors?


(Pedram Pourang) #16

It was just an example, although it works like a charm.


(Alf Gaida) #17

@manyroads - it might be that some arch derivatives might think that something is deprecated, but if one look into git it seems to be active maintained. Anyways, one should use what one want.

EDIT: The first time some people told me that yaourt is deprecated was in late 2014 i guess. And the same people told me that it is bad behaviour if one use yaourt. I was fine with - bad behaviour is one of my strongest skills.


(Pedram Pourang) #18

For example, if pcmanffm-qt has a problem, you could report it as a pcmanfm-qt problem, although it may be in libfm-qt. You won’t need to find causes; devs will find them by studying the effects (bugs).


(Mark Rabideau) #19

Sounds good. So here are a few further thoughts & questions:

To start the test process:

  • Someone sends me the go ahead to conduct a ‘blackbox’ test.
  • I’d prefer to have access to a complete buidable unit, if at all possible. I assume it’s not rocket science to build the DE… or someone can give me a quick cheat sheet on how-to do it.
  • I begin test of the buildable unit.

Questions:

  • Should I limit tests to only those items included with the base build?
  • Should I test LXQt with openbox only? Kwin_x11? Both?
  • Do you want the test restricted to the icons, themes provided in the base build?
  • Should I examine and report dependency problems encountered?
  • Are there specific human factors that require testing or emphasis?
  • Are there specific applications you’d like me to test?

I assume you want me to report problems (bugs) encountered somehow/ somewhere. Do I need a special decoder ring or handshake? Where do you keep this ‘stuff’. Gitlab is what I’d I assume. Although I have to say, I have never used Gitlab. And… my decoder ring and handshakes are still a mystery. :wink:


(Pedram Pourang) #20

Allow me to give you a general answer to all those questions:

Use LXQt “cruelly”. No LXQt component should fail under rational circumstances. So, if it fails, that’ ll be about a bug. Openbox, kwin or any other WM shouldn’t matter – of course, you won’t need to test all possible WMs :wink:

Just have the latest git LXQt once in while (or when something important happens – we’ll tell you about the latter) and find its problems if any. Don’t be kind to us :wink: It seems easy but, in practice, it may not be so at first.