June 2019 - Arch-dev-public - lists.archlinux.org

[arch-dev-public] Archweb updates
by Jelle van der Waa 04 Jun '19

04 Jun '19

Hi all, In the latest archweb release on our website there is a new report called "non existing dependencies" which shows packages with missing (opt|check|make)depends these should be fixed. [1] Apart from that, the signoff overview page on /devel now shows the packager and maintainer which can be useful for rebuilds. [2] [1] https://www.archlinux.org/devel/reports/non-existing-dependencies/ [2] https://www.archlinux.org/devel/ -- Jelle van der Waa

1 0

[arch-dev-public] Proposal for a new organisation structure
by Christian Rebischke 03 Jun '19

03 Jun '19

Hello everybody, ---------------------------- DISCLAIMER: Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. ---------------------------- inspired by the last thread about moving proprietary software to community, our general problem of getting more people involved in Arch Linux and the (for me) chaotic organisation structure and … [View More]hierarchy I would like to propose a discussion about changes. Please don't see this thread as an attack on your current position or whatever. I would like to propose a more democratic, simplified and more contribution friendly approach for our current hierarchy and organisation structure. At the moment we have the following three Groups (If I miss something feel free to correct me): - Devs - Trusted Users - Support Staff These three groups have the following 'features' and tasks: - Devs: - Tasks: The developers care about [core] and [extra] repositories, they form a direction for the whole project 'arch linux' and they seem to have a veto-permission for TU decisions. Furthermore they have access on most infrastructure and they are maintaining/developing the core software like pacman. Some devs also care about trademarks, legal requests and finance or community events. - How to be a developer?: The developers will decide in a non public and secrete ritual who is worthy to be a developer. The process is unclear. - Trusted Users: - Tasks: The trusted users care about the [community] repository, somehow some TUs have more tasks like: security team involvement, wiki administration, infrastructure administration, maintainership of software projects and other infrastructure projects like docker images, reproducible builds etc. Furthermore they care mostly about the package quality in the AUR (eg. answering submitted requests...) - How to be a trusted user?: It's well documented, we have rules for misbehavior, rules for applying, guidelines for moving packages into community and more. - Support Staff: - Tasks: They do various tasks like infrastructure administration, wiki administration, bug wrangling, software contribution, forum moderators, security team, but they have no access to any repository. - How to be a support staff: It's unclear, mostly a new contributor just knows the right people and does the right thing at the right time and get somehow acknowledged by developers or TUs for their work. Ok, I hope this gives a good overview over all three groups. Besides these groups, we have also people in more than of these groups. Anthraxx is for example listed as (dev,tu and support staff) on our website, I am listed as (tu and support staff) and so on. So what is my actual proposal. Well my proposal is to simplify the whole organisational structure, tear down bureaucracy, tear down 'walls' and unify the community and make it easier for 'outsiders' to contribute to the project we all love. Therefore I would like to propose a discussion around the following things: 1. Simplified repositories Currently we have [core], [extra] and [community]. These three repositories are there, because they have grown to this structure over time. At the moment I don't see any real meaning for the split of [core] and [extra]. So one suggestion would be to either: - merge [extra] and [core] - or use [extra] for a new purpose, like for example a proprietary repository, for all proprietary software. (I know that this is not possible for all packages, because we have binary blobs in device drivers and kernel modules). 2. Repository access At the moment a TU can access all packages inside of the [community] repository. Therefore they are able to modify packages in a good or bad manner. This can have nice effects and bad effects, how the past has shown to use, such as: - rapid updates in case of security vulnerabilities (good effect) - updates of packages, because somebody thought it needs an update, but the real reason for the delay was a bug inside of the new version of a software (bad effect) 3. Organisation structure Depending on the repository access, we could reduce our organisation structure to just two groups: Devs and maintainers (a similar approach to big distributions like Debian). Devs could still have the 'superpower' for caring about infrastructure and legal/finance stuff and the group of trusted users and support staff would merge to one group of maintainers. With person-related access to package repositories we could tear down the whole repository structure to one, maybe two, repositories and we could give co-maintainership an actual meaning (permission to modify a foreign package). 4. More transparency At the moment the recruiting process for developers is pretty unclear, as well as the actual decision making inside of the developers group, veto permissions and other things. This leads to a 'they vs/with us' thinking and makes it difficult to increase contribution in the community. Therefore I would like to propose more transparency for all groups who are involved in Arch Linux development and more communication between devs and TUs. At the moment the devs will mostly say:"Ok, this is a TU thingie, so I don't need to get involved in this question regarding TU rules or rules for community or anything else". It would be also nice to form an actual roadmap (yes.. I know.. we are not a company, but a roadmap or overview over all current projects inside of our community would be nice). This way it would be also easier to contribute for 'outsiders'. Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. Best regards and many thanks for reading the whole mail, shibumi / chris [View Less]

7 11

[arch-dev-public] bringing vivaldi browser to community
by Ike Devolder 02 Jun '19

02 Jun '19

3 years have passed since I first proposed to bring vivaldi into community. Now there is a clear differentiation between what vivaldi offers out-of-the box compared to other browsers. Vivaldi offers a ton of customisation features out of the box, and is also able to just use the chrome/ium addons from the chrome webstore. Personally I'm using vivaldi as my main browser since somewhere in 2015 (shortly after the first beta was released) and the key features no other browser currently offers … [View More]

4 9

[arch-dev-public] GCC 9 removed from [testing]
by Bartłomiej Piotrowski 02 Jun '19

02 Jun '19

Hi all, I just deleted GCC 9 and related packages from [testing] due to the filesystem corruption bug when bcache is used[1]. You will have to -Syuu your systems. People hungry for breakage can install it from [gcc9] repo I uploaded to pkgbuild.com: [gcc9] Server = https://pkgbuild.com/~bpiotrowski/gcc9/ Bartłomiej

3 5