release documentation #1779
Comments
|
Everyone, please don't hesitate to tell about your opinions on how we could release more easily and efficiently. If you think that git is enough, please tell why. If it isn't enough, how could we release LXQt components faster and more easily? LXQt has its git users but many users don't know how to have git LXQt -- I've seen Arch users that have problem with git. Others may suppose that gt LXQt is as unstable as git KDE.... As far as I've seen, we get lots of useful reports only after a release. |
|
Well, and many distros are just not geared well towards anything but released software, so another reason for regular releases. However, Arch isn't one of them. I'm shocked by the comment that you say that some of them have a problem with git. Could you elaborate more on that? If the useful reports come after a release, that certainly suggests a very good value in regular releases. The more releases, the more feedback, the more improved each subsequent release. |
Git LXQt is maintained very well in AUR but I've seen many Arch users with less than minimal knowledge of their systems. Installing Arch doesn't make a magic ;)
I completely agree. I've experienced its usefulness first hand. Debian and Ubuntu users make sensible bug reports/feature requests after new releases. I don't know how many times I've had to say, "your installation is too old." |
|
I guess I'm just surprised to see Arch users that don't know what they're doing! Anyways I'd like to hear from others on this. Most importantly, we need to hear from @agaida since it sounds like he's been the one carrying the release torch. |
|
It seems, that no release concept exists. I am new to the whole LXQt world. The only release that I have seen is 0.14.X from Lubuntu 18.10 onwards. In other words, I have no idea, how release management was handled before 0.14. If I had to create a release concept, I would ask myself this:
Based on the answers, it has quite different consequences for downstream. |
|
@apt-ghetto |
|
IIRC our goal was/is a major release every six months more or less, followed by point (fix) releases to the latest major release. Considering the available manpower, aiming for more frequent releases/backports etc is not realistic. |
|
@luis-pereira For example, releasing lxqt-archiver should be a piece of cake. It shouldn't wait for only one person to do the whole job. |
|
@luis-pereira we are about 9 months too late for our 6 month milestone, so maybe we can start with sticking to that! |
|
Also what dictates when a point release comes out? Only for security and critical bug fixes or what? |
Of course it can. |
That would be a great start. |
Security and critical bugs at least. |
|
I agree with @luis-pereira that point releases are for critical bugs and security. Also for that reason, it'll be great if each developer is able to make them by consulting others — instead of waiting for @agaida, who may have lots of other jobs to do. That will be a wok division, which will benefit both users and developers (because of more helpful reports and less reports against outdated codes). |
|
FYI: The first release by me: https://github.com/lxqt/lxqt-archiver/releases/tag/0.1.0. Please package it for your distros and for us to get real feedback! |
|
Awesome! I published https://www.archlinux.org/packages/community/x86_64/lxqt-archiver/. From the perspective of a packager, the first thing I noticed for this release is that there are no GPG-signed source tarballs. Arch Linux enforces package authenticity by PGP key IDs (ex: line 22 in PKGBUILD for lxqt-about) Seems GPG-signing is done by https://github.com/lxqt/lxqt-release-foo/blob/master/scripts.d/archive.sh. EDIT: lxqt-archiver moved to stable repo. |
|
@yan12125 |
|
OK, please tell if this is correct. To make a release of an LXQt component (minus the general announcement, which isn't possible for now):
@yan12125, am I missing anything, especially for Arch? EDIT 1: I meant "signed tag" but wrote "annotated tag"; corrected it. EDIT 2: I made a release for Arqiver in the above-mentioned way: https://github.com/tsujan/Arqiver/releases/tag/V0.5.0 |
Nothing :) Thanks for the note! |
Most distros will check against @agaida and/or @jleclanche GPG key though. |
|
Okay, good to know. Do you plan to do a release of the whole of LXQt in the end or only some individual parts? |
|
Actually, I think its highly preferable (even a must) to release My plan, so far:
After that, other components could be released. But I should do some tests before doing anything. We also need to wait for @selairi to finish his works. I hope libfm-qt/pcmanfm-qt could be released 3 weeks later but other components might need to wait a little longer. |
|
@tsujan that sort of sequencing is the sort of things the docs need. So should we create a wiki page to start collecting some of this stuff? |
|
@wxl |
|
OK, the whole LXQt should be released on bumping lxqt-build-tools's version. I update all changelogs in PRs whenever I find time (already made 2 PRs). Then I prepare summaries for release pages (previously, we did it in "lxqt.org" but it's better and cleaner to do it for each component in its own release page). The order of releasing is obvious but distro packaging should be done after all components are released (I'll tell everyone about it). |
|
@wxl How To Release A New Version of LXQtOrderPreparing and releasing of LXQt components can be done in this order (only important components are listed and the order isn't strict near the end): You should have installed the latest git versions of all LXQt components and be satisfied with their performance before proceeding. Preparation
ReleasingRelease the components in the above-mentioned order. To do so, for each component:
AnnouncementAnnounce the new version of LXQt with some highlights as the release note of Tell distro maintainers that they can start their jobs. If someone finds an issue in your work, fix it — of course, reluctantly because you're tired now. |
|
@luis-pereira, thanks a lot! I might make minor changes to it later. @yan12125 @jubalh @wxl @luis-pereira I double checked everything -- and hope that my double-checking hasn't had the inverse effect ;) -- but please check it and tell me if something is wrong. @wxl Please tell Lubuntu team that the new version is ready; I didn't know whom I should call. I hope Debian will have a new maintainer. |
|
You mean how new features get into .ts files? In CMakeLists.txt is set There was also something like -DCMAKE_UPDATE_TRANSLATIONS=ON while compiling but I think it's ignored. |
|
@stefonarch Minutes ago, I saw that everything had already been done cleanly in |
It might be helpful to put it elsewhere. the SKS pool is probably your best bet. |
You mean "elsewhere too"; it should be in GitHub. |
|
Well elsewhere, by definition, acknowledges one place and points at one that is not like it, so yes 🤣 |
@voidpin Well, like always: just because something doesnt exist on one distribution/os we won't change it (unless there is a general good reason). You can just set the setting yourself in your build scripts :) |
|
@jubalh |
|
I see, I thought just a switch can be used. |
|
@jubalh I think it has been a misunderstanding here. |
So, I was wrong. We don't need to change anything :) @jubalh, you were right. |
|
@tsujan yes, I was just asking to please keep it as is :) |
|
Thanks for clarifying @voidpin ! |
|
FYI, |
|
Nice. You might want to override the panel's icon theme with a set that has light (symbolic) icons. That's possible at the bottom of panel config dialog. |
|
Alright, apparently I was wrong and GPG public keys on some key servers is still necessary for some scenarios. An example is Arch Linux's reproducible builds server, which uses That is as simple as a command That should be enough as SKS server exchanges keys periodically. @tsujan mind to add that? |
|
Please tell me where I should add it and I will tomorrow -- I'm not familiar with key servers. |
|
@tsujan on the terminal, using the command @yan12125 gives you. They key will be synced to other key servers, so you only need to send it once. Although it's possible getting the key directly from GitHub, I don't think is a good idea to rely only on that. gpg --fetch-keys https://github.com/tsujan.gpg |
|
@AlfredoRamos However, I can't find it with |
|
OK, after using |
|
Back to the main subject: We did it :) Thank you all for your suggestions, guidance and help, without which a release wouldn't be possible. I'll clean up the explanations whenever I find the time, although they're usable as they are. A few components need point releases, which I'll make in 2 weeks or so. Future releases will be straightforward. |
|
@tsujan do you know when you plan to do 0.15.1? |
|
@jubalh Only lxqt-panel, pcmanfm-qt/libfm-qt and lxqt-archiver need point releases (lxqt/lxqt.github.io#43). Tomorrow, I'll release pcmanfm-qt, libfm-qt and lxqt-archiver. lxqt-panel may need to wait a little because of lxqt/lxqt-panel#1404. In general, whenever I want to make point or, especially, major releases, I'll ask everybody for their opinions and, when I make them, I'll tell you and @yan12125. |
|
Perfect! Thanks @tsujan ! |
|
You're welcome. |
|
FYI LXQt-0.15.0, including all the point releases until yesterday, has been imported and is now available for all NetBSD users. |
|
@tsujan translations can be extracted with the |
|
The |
|
@luis-pereira |
As discussed (offtopic) on #1778 @tsujan and I are of the opinion that we could use more clear documentation about how and when to do releases.
I'm pretty sure the how is well sorted (but not ever written down from what I can tell) but the when has probably been a bit more organic. I think that latter issue could especially use development. I'm not saying that we adhere strictly to some time-based schedule, but there may be triggers to releases. What are those triggers?
I think the more detailed this documentation, the more the burden of releasing can be shared among multiple people, which should make releases easier, which should mean more releases, and that's a very good thing.
It certainly would save us the trouble (like on the aforementioned issue) of telling people that they should use git master because the releases are too darned old.
The text was updated successfully, but these errors were encountered: