Re: [arch-dev-public] soyuz (pkgbuild.com) server move to homedir.archlinux.org
On Mon, 18 Nov 2019 at 07:34, Sven-Hendrik Haase wrote: > Hi all, > > I set up a new Hetzner VPS that is going to become our new > homedir/public_html server available to all TUs and Devs like soyuz was. We > decided to decommission soyuz and put the public_html stuff on its own > server for security reasons, to cut costs, and so that we can > compartmentalize further. > > The server uses a Hetzner Cloud Volume which we can scale if we want but > for now, it's 100GiB of zstd-compressed btrfs. If possible, we'd like to > keep it at this size for the time being. You can host your own repos there > if you want and that's fine. Please talk to us beforehand if you see > yourself exhausting the volume with what you want to do. > > If you had stuff hosted in the public_html of soyuz, I'd ask you to > transfer stuff over to the new box which is already reachable at the names > pkgbuild.com (you'll get an SSH error because of this) and > homedir.archlinux.org. Please check if you can throw away some old > stuff/junk that you might not necessarily need on the new server. > > This new box is *not for building*. That's what dragon is for. Please only > put documents/files onto the new pkgbuild.com that you actually want > people to be able to access publicly. The box has no building facilities > and you get no sudo'd commands. > > soyuz is going to be decommissioned no sooner than 2020-01-01 but do not > expect it to hang around for long after that. We will not transfer any > files for you from soyuz. In other words: All data not explicitly > transferred by you will be destroyed after 2020-01-01. > > Please bring up any problems you might have with this new server on the > arch-devops list or IRC (#archlinux-devops). > > Enjoy, > Sven > This is a short reminder that this is happening. soyuz is going away soon. I'll mark it for cancellation one of these days. If you haven't done so yet, please migrate your data if it's important.
Re: [arch-dev-public] Proposal: Build a ruleset for new packages and package quality
On 12/12/19 10:21 pm, Christian Rebischke via arch-dev-public wrote: > 3. revive the discussion around better PKGBUILD quality (see also Eli's > thread about PKGBUILD quality on arch-tu: > https://lists.archlinux.org/private/arch-tu/2019-November/83.html) Any chance that can be posted somewhere visible to those that aren't TUs? Allan
Re: [arch-dev-public] Proposal: Build a ruleset for new packages and package quality
[2019-12-12 13:21:42 +0100] Christian Rebischke via arch-dev-public: > 1. find a consensus on rules which packages we allow in our repositories > and which don't. There's no need for hard rules except "don't put stuff in the repos that will cause legal problems". We certainly strive to ship stable versions. But for some projects those are outdated and there are valid reasons to prefer shipping a newer release even if it's tagged as unstable by upstream. Those decisions are left to the best judgment of individual maintainers. If a conflict arises, it should be discussed on this mailing list. > 2. find a consensus on rules on violating our rules regarding package > requirements. (e.g. What happens when TU/Dev XY violates our package > requirements? what is the punishment?) If there's a disagreement as to what should or should not be packaged, it should be discussed here on a case-by-case basis. If consensus is reached that the package should be removed, then the packager must remove it. Obviously if the packager does not abide the decision made, there will be serious repercussions. But there's no need to set anything in stone: this will be decided on a case-by-case basis. > 5. What do we do with the existing beta and alpha packages? Are they > granted asylum? Or do we remove them, to be consistent? > > extra libmspack 1:0.10.1alpha-2 > extra qt5-webkit 5.212.0alpha3-6 > community d-containers 0.8.0alpha.19-1 > extra frozen-bubble 2.2.1beta1-14 > extra hddtemp 0.3.beta15.53-1 > extra libcaca 0.99.beta19-2 > extra tsocks 1.8beta5-8 > community hydrogen 1.0.0beta1-1 > community lablgtk3 3.0.beta6-2 > community modclean 3.0.0beta.1-1 > community sdedit 4.2beta8-1 > community sniffit 0.3.7.beta-17 > community vbindiff 3.0_beta5-1 > community wqy-microhei 0.2.0_beta-9 > community wqy-microhei-lite 0.2.0_beta-9 We shouldn't aim to replace those packages just because they have alpha or beta in their name. Assume the individual maintainers made an informed decision. Now if someone has a good reason why we should ship a different version than the above for a given package, please bring it up and we can discuss it. I can only speak for hddtemp and tsocks: they're old releases, but there hasn't been any newer one and their last stable release are really ancient. Those "beta" releases provide the best feature/stability for our users. > 7. Another topic is a rule about "touching packages of others". In the > #archlinux-tu channel we came to the conclusion that TUs or devs should > ask the package maintainer before touching another devs/TUs package, how > do we want to handle this? Is this the consensus, or are touches without > prior question allowed? What do we do if somebody violates our rules? > etc If it's something as trivial as a pkgrel bump and rebuild, no permission is required. If it's something more substantial, it should be discussed before. As usual, if a conflict arises, it should be discussed here. > https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning > > My questions to this guidelines: > > 8.1. under which consensus where this rules defined? Are these rules the > result of a developer vote? of a leader decision? Or are they made up by > a few persons without consensus. They're just guidelines. Try to abide them and when you don't make sure you have a really good reason not to. > 8.2 I can't find any list about punishments for violations of these > rules. Again, punishment is uncalled for at this stage. If a packager repeatedly ignores warnings and repeatedly violates decisions made by consensus, then sure, we'll start a discussion about removing them. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal: Build a ruleset for new packages and package quality
On 12/12/19 7:21 AM, Christian Rebischke via arch-dev-public wrote: > 5. What do we do with the existing beta and alpha packages? Are they > granted asylum? Or do we remove them, to be consistent? > > extra libmspack 1:0.10.1alpha-2 > extra qt5-webkit 5.212.0alpha3-6 qt5-webkit is a security-critical component (a browser), and upstream has not historically been good about updating the version of webkit they build on. Currently, there is a years-long effort by annulen, to fix this and get webkit back into good shape. Given a choice between no qt5-webkit, a qt5-webkit which is so ancient it's intolerably dangerous, and packaging the resuscitated annulen version, this is an acceptable exception. > community d-containers 0.8.0alpha.19-1 > extra frozen-bubble 2.2.1beta1-14 > extra hddtemp 0.3.beta15.53-1 > extra libcaca 0.99.beta19-2 > extra tsocks 1.8beta5-8 > community hydrogen 1.0.0beta1-1 I know this one too: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/hydrogen=bf63a0be79e954863a014bb9ea23157aaf70d7c4 We needed to upgrade to the beta in order to migrate from qt4, which was in the process of being dropped, to qt5. It was not a lightly made decision. > community lablgtk3 3.0.beta6-2 > community modclean 3.0.0beta.1-1 > community sdedit 4.2beta8-1 > community sniffit 0.3.7.beta-17 > community vbindiff 3.0_beta5-1 > community wqy-microhei 0.2.0_beta-9 > community wqy-microhei-lite 0.2.0_beta-9 I'm unsure / have insufficiently researched the other cases, but I do dearly hope that their respective maintainers considered the tradeoffs before packaging an unstable release. > 6. How do we define stable packages? beta or alpha is just a human made > word. I've seen devs who said their "1.0" version is unstable and > shouldn't be used in production. Should such a software get packaged? > And what about projects who use semantic versioning (the devs said so), > but they have a 0.* prefix release? Semantic versioning defines 0.* as stable, so this is not a question. As per semantic versionining, a version indicator ending in one of the globs: -alpha* -beta* is considered an alpha or beta prerelease and therefore unstable. > 7. Another topic is a rule about "touching packages of others". In the > #archlinux-tu channel we came to the conclusion that TUs or devs should > ask the package maintainer before touching another devs/TUs package, how > do we want to handle this? Is this the consensus, or are touches without > prior question allowed? What do we do if somebody violates our rules? > etc > > 8. A few guys in the IRC pointed me to this guidelines in our wiki: > > Note: This page is only editable with Wiki-Admin/Dev Permission. > > https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning > > My questions to this guidelines: > > 8.1. under which consensus where this rules defined? Are these rules the > result of a developer vote? of a leader decision? Or are they made up by > a few persons without consensus. > > 8.2 I can't find any list about punishments for violations of these > rules. > > 8.3 There is no documentation about our alpha and beta packages. I see > that there are exceptions for alpha and betas, but it's not clear for me > how these exceptions apply to the packages we have in our repositories. > > This needs to be documented, otherwise every person could push an alpha > package and just 'claim' that one of those exceptions apply for the > package and if nobody checks this claim, the package will be in the > repository. The most likely place to find out about exceptions is by reading the svntogit commit logs, which is an excellent place to store information about, well, changes made to the package, and I encourage people to make use of that fact. :) > 9. Do we consider packages, that are build from the latest git tag, as > alphas or betas? >> pacman -Ss|grep -E '\+[0-9]+\+g' Well, those don't build from "the latest git tag", they build from "the latest git commit" perhaps. Given it is not tagged upstream as a stable release, nor is it tagged upstream as an alpha or beta, it seems obvious to me that they are not alphas or betas or even stable releases... they are *-git packages. > 10. Do we need to ask software developers in the future if they consider > their project stable? It's not clear which versioning schema the devs > use, some consider their 0.1 release as unstable, some consider it as > stable. Is semantic versioning applied? Do they follow a different > schema? Semantic versioning as well as common convention states that they are stable, if upstream says that it's actually only beta quality then I encourage you to do some soul searching about whether to package it. Most software with a 0.* version will be versioned that way because "we are not ready to commit to a stable API, so any new version has the potential to change how the software works, to the same degree that a semver major version can". Alternatively, the
Re: [arch-dev-public] Proposal: Build a ruleset for new packages and package quality
On Thu, 2019-12-12 at 13:21 +0100, Christian Rebischke via arch-dev-public wrote: > Hello everybody, > > Due to a longer discussion around alpha and beta packages in our > repositories in IRC yesterday, I would like to start a hopefully more > constructive discussion around this topic on the ML. > > Short summary for everybody what happened: > > I wanted to get caddy2.0.0-beta into [community], people started > discussing that we don't ship betas in our repositories and I should > either wait or ship the stable caddy v1 release. > > > I don't want to start this discussion around caddy again (I will wait > for a stable release). What I want to accomplish with this mail is: > > 1. find a consensus on rules which packages we allow in our repositories > and which don't. For the ones that were not in the discussion about caddy: The caddy devs consider 2.0.0-beta10 stable software but not stable API. From https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning > Stable packages package stable releases I think this means stable software *and* stable API. Projects that depend on a certain library are not expected to be using beta releases. They will most likely only update once the library authors commit to a certain API. For most cases I don't think we should be packaging unstable APIs. > 2. find a consensus on rules on violating our rules regarding package > requirements. (e.g. What happens when TU/Dev XY violates our package > requirements? what is the punishment?) No punishments. As coderobe said, we should assume good faith. If someone is breaking the rule, ask them to fix it. If they continue to do it then I think it's means for disciplinary action, even removal if needed. I believe this should apply to both TUs and Devs. > 3. revive the discussion around better PKGBUILD quality (see also Eli's > thread about PKGBUILD quality on arch-tu: > https://lists.archlinux.org/private/arch-tu/2019-November/83.html) > > 4. I would like to have this rules written down somewhere, either in the > TU bylaws (in dev bylaws if this exists) or in a new format like > "community bylaws" (maybe we could combine this with the question about > a new leader). This should be in the packaging guidelines, not on some community or TU specific guilelines. I also think any sort of bylaws are not the correct place for this, there are to many exceptions for this to be correctly described in that kind of document. > 5. What do we do with the existing beta and alpha packages? Are they > granted asylum? Or do we remove them, to be consistent? > > extra libmspack 1:0.10.1alpha-2 > extra qt5-webkit 5.212.0alpha3-6 > community d-containers 0.8.0alpha.19-1 > extra frozen-bubble 2.2.1beta1-14 > extra hddtemp 0.3.beta15.53-1 > extra libcaca 0.99.beta19-2 > extra tsocks 1.8beta5-8 > community hydrogen 1.0.0beta1-1 > community lablgtk3 3.0.beta6-2 > community modclean 3.0.0beta.1-1 > community sdedit 4.2beta8-1 > community sniffit 0.3.7.beta-17 > community vbindiff 3.0_beta5-1 > community wqy-microhei 0.2.0_beta-9 > community wqy-microhei-lite 0.2.0_beta-9 Well, it depends on the case. As a general rule just don't package -beta. > 6. How do we define stable packages? beta or alpha is just a human made > word. I've seen devs who said their "1.0" version is unstable and > shouldn't be used in production. Should such a software get packaged? > And what about projects who use semantic versioning (the devs said so), > but they have a 0.* prefix release? True. We can't make rules based on version strings, each case needs to be analyzed. If the software is stable and the API is stable then package it. > 7. Another topic is a rule about "touching packages of others". In the > #archlinux-tu channel we came to the conclusion that TUs or devs should > ask the package maintainer before touching another devs/TUs package, how > do we want to handle this? Is this the consensus, or are touches without > prior question allowed? What do we do if somebody violates our rules? > etc This is the same as 2), assume good faith. If people abuse it then that should be grounds for disciplinary action. > 8. A few guys in the IRC pointed me to this guidelines in our wiki: > > Note: This page is only editable with Wiki-Admin/Dev Permission. > > https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning > > My questions to this guidelines: > > 8.1. under which consensus where this rules defined? Are these rules the > result of a developer vote? of a leader decision? Or are they made up by > a few persons without consensus. > > 8.2 I can't find any list about punishments for violations of these > rules. > > 8.3 There is no documentation about our alpha and beta packages. I see > that there are exceptions for alpha and betas, but it's not clear for me > how these exceptions apply to the packages we have in our repositories. > > This needs to be documented, otherwise every person could push an
[arch-dev-public] Qt 5.14 in [testing]
The usual reminder that, due to Qt's ABI versioning, everything built against 5.14 will have to wait in [testing] until Qt itself moves.
Re: [arch-dev-public] Proposal: Build a ruleset for new packages and package quality
On Thu, Dec 12, 2019 at 01:40:19PM +0100, Public mailing list for Arch Linux development wrote: > On 12/12/19 1:21 PM, Christian Rebischke via arch-dev-public wrote: > > 8.2 I can't find any list about punishments for violations of these > > rules. > > > > Best regards, > > Chris > > > > Do we have such lists of punishment in any of our other guidelines? > > I think we generally assume that other team members are acting in good faith, > if someone is doing something by mistake - point them towards it and I'm sure > you can figure it out. > All without threatening someone with /punishments/. > > -- > Rob (coderobe) > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > This is indeed an argument, although it's difficult to differ between a mistake and a "mistake". If you get what I mean. Chris signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal: Build a ruleset for new packages and package quality
On 12/12/19 1:21 PM, Christian Rebischke via arch-dev-public wrote: > 8.2 I can't find any list about punishments for violations of these > rules. > > Best regards, > Chris > Do we have such lists of punishment in any of our other guidelines? I think we generally assume that other team members are acting in good faith, if someone is doing something by mistake - point them towards it and I'm sure you can figure it out. All without threatening someone with /punishments/. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: OpenPGP digital signature
[arch-dev-public] Proposal: Build a ruleset for new packages and package quality
Hello everybody, Due to a longer discussion around alpha and beta packages in our repositories in IRC yesterday, I would like to start a hopefully more constructive discussion around this topic on the ML. Short summary for everybody what happened: I wanted to get caddy2.0.0-beta into [community], people started discussing that we don't ship betas in our repositories and I should either wait or ship the stable caddy v1 release. I don't want to start this discussion around caddy again (I will wait for a stable release). What I want to accomplish with this mail is: 1. find a consensus on rules which packages we allow in our repositories and which don't. 2. find a consensus on rules on violating our rules regarding package requirements. (e.g. What happens when TU/Dev XY violates our package requirements? what is the punishment?) 3. revive the discussion around better PKGBUILD quality (see also Eli's thread about PKGBUILD quality on arch-tu: https://lists.archlinux.org/private/arch-tu/2019-November/83.html) 4. I would like to have this rules written down somewhere, either in the TU bylaws (in dev bylaws if this exists) or in a new format like "community bylaws" (maybe we could combine this with the question about a new leader). 5. What do we do with the existing beta and alpha packages? Are they granted asylum? Or do we remove them, to be consistent? extra libmspack 1:0.10.1alpha-2 extra qt5-webkit 5.212.0alpha3-6 community d-containers 0.8.0alpha.19-1 extra frozen-bubble 2.2.1beta1-14 extra hddtemp 0.3.beta15.53-1 extra libcaca 0.99.beta19-2 extra tsocks 1.8beta5-8 community hydrogen 1.0.0beta1-1 community lablgtk3 3.0.beta6-2 community modclean 3.0.0beta.1-1 community sdedit 4.2beta8-1 community sniffit 0.3.7.beta-17 community vbindiff 3.0_beta5-1 community wqy-microhei 0.2.0_beta-9 community wqy-microhei-lite 0.2.0_beta-9 6. How do we define stable packages? beta or alpha is just a human made word. I've seen devs who said their "1.0" version is unstable and shouldn't be used in production. Should such a software get packaged? And what about projects who use semantic versioning (the devs said so), but they have a 0.* prefix release? 7. Another topic is a rule about "touching packages of others". In the #archlinux-tu channel we came to the conclusion that TUs or devs should ask the package maintainer before touching another devs/TUs package, how do we want to handle this? Is this the consensus, or are touches without prior question allowed? What do we do if somebody violates our rules? etc 8. A few guys in the IRC pointed me to this guidelines in our wiki: Note: This page is only editable with Wiki-Admin/Dev Permission. https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning My questions to this guidelines: 8.1. under which consensus where this rules defined? Are these rules the result of a developer vote? of a leader decision? Or are they made up by a few persons without consensus. 8.2 I can't find any list about punishments for violations of these rules. 8.3 There is no documentation about our alpha and beta packages. I see that there are exceptions for alpha and betas, but it's not clear for me how these exceptions apply to the packages we have in our repositories. This needs to be documented, otherwise every person could push an alpha package and just 'claim' that one of those exceptions apply for the package and if nobody checks this claim, the package will be in the repository. 9. Do we consider packages, that are build from the latest git tag, as alphas or betas? >> pacman -Ss|grep -E '\+[0-9]+\+g' 10. Do we need to ask software developers in the future if they consider their project stable? It's not clear which versioning schema the devs use, some consider their 0.1 release as unstable, some consider it as stable. Is semantic versioning applied? Do they follow a different schema? 11. What do we do when a package is stable, but the API is unstable? Is the whole package considered unstable? The current guidelines are not clear about APIs, but many users use Arch Linux for software development and maybe rely on stable APIs. Disclaimer: I don't know how we want to find concensus yet (TUs have a transparent vote process, but devs don't have an equivalent for this), therefore I hope for a "final decision" of our still-leader aaron. This topic doesn't need to be decided this year. I am fine with reviving this thread in January or late replies in January. Best regards, Chris signature.asc Description: PGP signature
