Members of the openSUSE Election Committee have provided an update regarding this year’s Board election. This election will fill three board seats. All eligible openSUSE members are encouraged to participate in shaping the future of the project.

The nomination process, originally scheduled for completion in December, has been extended due to an insufficient number of candidates. The updated timeline aims to provide more opportunities for members to engage in the process.

Revised Election Timeline

• Jan. 3, 2025: Extension for nominations and applications for Board candidacy; membership drive begins
• Jan. 18, 2025: Final candidate list announced; campaign begins; membership drive continues (new members can vote but not run)
• Jan. 19, 2025: Voting opens
• Feb. 2, 2025: Voting closes
• Feb. 3, 2025: Election results announced

The three open seats are held by Douglas DeMaio, Neal Gompa, and Patrick Fitzgerald. Board members serve as guides for the community, handle key project functions, facilitate initiatives, organize meetings, and manage openSUSE domains and trademarks. They also uphold community standards, including overseeing complaints and ensuring compliance with the openSUSE Code of Conduct.

How to Participate

Any openSUSE member can stand for election by sending an email to project@lists.opensuse.org and election-officials@lists.opensuse.org. Members can also nominate others by contacting the Election Committee, who will confirm the nominee’s interest.

Eligibility Requirements

Per the Election Rules, only current members are eligible to run for board positions. New members joining during the membership drive can participate in voting but cannot stand as candidates.

The election is overseen by committee members Ish Sookun, Edwin Zakaria, and Ariez Vachha. Their responsibilities include finalizing the candidate list and ensuring a smooth election process.

Let’s work together to make this election a success and continue driving openSUSE forward into 2025!

Resistance is not futile. If you try to force change like the Borg, your efforts to help teams will likely be foiled. Even worse, if you succeed at imposing your desired change, you’ll destroy the very potential of those you’re trying to help. 

In my experience teams following Extreme Programming (XP) values and practices have had some of the most joy in their work: fulfilment from meaningful results, continually discovering better ways of working, and having fun while doing so. As a manager, I wish everyone could experience joy in their work. 

I’ve had the privilege to work in, build, and support many teams; some have used XP from the get go, some have re-discovered XP from first principles, and some have been wholly opposed to XP practices. 

XP Teams are not only fun, they take control of how they work, and discover better ways of working. 

Who wouldn’t want that? Where does resistance come from? Don’t get me wrong; XP practices are not for everyone, and aren’t relevant in all contexts. However, it saddens me when people who would otherwise benefit from XP are implicitly or accidentally deterred.

Developers discount XP based on misconceptions. Managers say they support collaborative working while simultaneously reinforcing incentives that demonstrate the opposite. Let’s explore sources of resistance to XP from developers, management, systems, and tools, along with how to help…if appropriate.

Paradox of Giving Control

One cannot coerce teams to take control. Control must be taken. XP Teams take control of and own their ways of working. Management imposed XP is not XP. 

Supportive managers have significant power to influence ways of working, but can only invite and encourage ways of working; coercion cannot create teams that take control.

Developers’ resistance to XP

Curiously, given XP’s origins, much resistance to XP ways of working comes from developers. Perhaps even more so than management. 

It’s not what we’re used to

XP practices are incredible, in the full sense of the word. Not only are they highly effective but it is often difficult to believe they will work well for you, until you’ve had the chance to try them.

Most developers are familiar with the open source development workflows that have gained popularity thanks to GitHub—Long lived branches, pull requests, individual autonomy and collaboration amongst large groups of people across many time zones. This way of working is effective for large open source projects but it’s not as effective as small teams can be at working together towards a common goal. 

Furthermore, many XP practices are both counterintuitive and require a lot of skill. TDD is hard if you’ve not had the privilege to work in a team skilled at it. Many folks say they practice TDD, comparatively few do or can. Ditto Pairing. Ditto CI. People think TDD is about writing “the tests” first, think pairing is about discussing code from time to time, and think CI is about test/build automation. Actually integrating your changes every hour, driving implementation from a single failing test assertion for the next micro-unit of behaviour, and working collaboratively with another person throughout the work are both hard and unfamiliar. 

Pairing conflicts with the popular understanding of “flow”, and stereotypes of introverted developer needs. Pairing requires skill at collaborating in real time. It feels less efficient because you’re shaping the design collaboratively as you go rather than hammering out your personal vision. It takes experience of good pairing to see how flow is improved by continuity, resistance to distractions, and focus on different levels of abstraction throughout. It takes experience of good pairing to see how it saves on re-work on review. It takes experience of good pairing to be convinced it’s fun, even for self-identifying introverts. 

CI conflicts with the popular experience with pull request workflows. It takes skill to break a change down so that you can make an integrable small step in less than an hour. It takes humility and compassion for yourself and your team to accept the overhead of breaking work down into such small steps. It takes experience to see how working in small steps with some overhead of crafting each step will save time in the long run with less rework or breakages. 

TDD is hard, perhaps the hardest of the XP practices to learn, it requires both expertise and also humility. The humility to accept that the design may end up better through working in smaller steps with continuous feedback, than it would through shaping it out first.

These factors often lead to bad experiences where people see more examples of misunderstandings  than good practices. This leads to misnomers like  “TDD couples the tests to the implementation”, “pairing is for extroverts”, and “you must have CI on a branch“

Developers’ resistance to their own understanding and experience of XP practices are not then wrong or surprising. They likely will be more effective with the ways of working they understand and have become skilled in, even if they’re at a local maximum, even if their team could be more effective.

Individual Autonomy is Glorified

Popular developer culture glorifies individual autonomy and preferences above all else. What helps an individual focus, get into flow, get most done, avoid distractions. Maximise flow, minimise meetings. 

Embracing XP values requires embracing what’s best for the team and the team’s outcomes; at the expense of individual freedom and productivity. 

This wrankles.

Pairing requires preceding at the speed of conversation, and often accepting a more emotionally draining way of working. Pairing requires agreeing on a common tech setup often involving tradeoffs from keyboards to editor of choice.

CI requires effort to keep your changes integrated with everyone else’s rather than blasting off alone.

In short it needs humility and a commitment to the needs of the team. 

The needs of the many outweigh the needs of the few. 

Management incentives that resist XP

Of course resistance to different ways of working doesn’t just come from developers, managers have even more influence. Even managers who think and say they support collaborative working may be oblivious to the ways they signal and support systems that demonstrate the opposite.

Rewarding and Managing Individuals

Do you have OKRs for individuals? Are you performance managing individuals’ outcomes? Do you build promotion packets for individuals based on their direct contributions to the company results?

You are incentivising individuals to avoid collaborating and maximise their individual visible contributions. 

There’s a paradox for managers that managing individuals and optimising individual performance undermines team impact. You lose out on the impact multiplier that teams can have.

Helping teams means switching from holding people accountable for output, to holding them accountable for behaviours. This is often uncomfortable; it’s easier to point at a number that’s not good enough, than have a conversation about behaviour that isn’t meeting your needs or the team’s needs. 

Short termism

Management incentives often conspire to maximise short term results. How much can we get done this quarter, this week, today. It requires effort to support sustainability and protect teams from self-imposed deadlines and urgency stealing their discretion to work collaboratively.

Lack of time discretion 

Can your teams choose what they work on day to day or is their time managed and tracked to project plans and budgets by armies of bureaucrats? Without space to adapt, nobody will.

Lack of Control

Does everyone have to use Jira? There’s your problem ;)

Is a team allowed to not plan every week? Can they choose to not have a standup? Can they work differently?

“But how will we track without standardisation?” You won’t. “How will we manage without metrics?” you have to have real meaningful conversations, not just watch numbers on dashboards that are comforting lies.

Teams need control over their ways of working to be able to uncover better ways of working.

Tools reinforce resistance to XP

The tools we use, and the language and metaphors they employ have a surprisingly big effect on our ways of working.

This impact was starkly visible when a team switched from having daily “standup” conversations from around a Jira board, to a freeform custom layout for their workflow on a Miro board. There was an immediate improvement to the quality of conversation around who needed to work with whom on what, towards which outcomes.

Not to pick on Jira (but it’s such a good example of a tool antithetical to agility) Jira encourages each “issue” (everything is a problem) to be “assigned” (not self organised) to an individual (not a group). The default board view focuses on the work and not the team.

Similarly Github’s UX nudges towards work in isolation, and asynchronous blocking review flows. Building porcelain scripts around the tooling that represent your team’s workflow rather than falling into line with the assumed workflows of the tools designers can change the direction of travel.

While completely compatible with collaborative team-working when used in the right ways, commonplace tools are source of friction to departing from the most common workflows. Friction nudges teams who are starting to explore working together back towards isolation. 

How to help overcome resistance

As a manager, or member of the team with sufficient influence, how can you help teams discover the joy of ways of working that you’ve enjoyed?

Should you?

It’s fundamental that a team is in control and owns its ways of working. That has to include ways of working that you think are worse. 

Help must be offered as a gift, not as a mandate to work in a particular way.

So how to help?

Don’t force it

Explicitly give control to the team and invite them to try new things.

Hiring

If you’re a manager you likely have significant influence over hiring. Hiring people with experiences you think will be beneficial into the team, can have an enormous influence on the team culture and effectiveness. 

However, transplants can be rejected. Beware risks of trying to transplant people you’ve seen succeed elsewhere in different team cultures. What worked elsewhere may not work here. People who were highly effective in other team systems may be ineffective here. Bringing someone who wants to work in a different way into a team may help transform things for the better… or make the existing team and the new joiner unhappy. 

Furthermore, teams that really take control of their work, also take control of hiring. Overruling team hiring decisions will undermine their trust that you genuinely want them to take control.

Share experiences  

What have you seen work? How did it play out? What pitfalls were there? Your team may not have experienced these things, at least share what you’ve seen with them.

Practise together

If you have the time, skills, and trust, getting hands on working with the team can help. Giving folks the experience of working with beneficial practices is a powerful tool. 

The counterintuitive/countercultural nature of some of the practices mean that the best way to understand how they help, is to see it in practice through working with someone experienced.

Coaching

You can help through individual coaching; asking the right questions and inviting people to discover better ways and why, themselves. Beware advising people to do things the way that worked for you, instead be curious, and ask how you can help rather than imposing your help.

Accountability 

A team deciding to try a new practice may never really give it a proper go. Pairing may be squeezed out by some of the management incentives above that they aren’t even consciously aware of. Holding folks accountable to behaviours they’ve agreed to try/change shows that you care and support them. 

Inquiring about dropped working agreements can help signal that you see them as more important than whatever contrary signals you may be sending, unbeknownst to you, through the wider organisational incentives. 

If you’re not a manager you can explicitly ask your manager to help hold yourself, the team and team members accountable to working agreements.

Explicitly Make Time available

Time pressure gets in the way of trying new things. Like the proverbial “too busy to try the wheels“. Try making time explicitly available through simple habits like “On Fridays we mob program”, “We start each morning reviewing code together”, or “We leave a week between planning cycles to try new things”

In summary

Teams practising XP can be highly effective and have great joy in their work. Paradoxically this can’t be imposed, its effectiveness is counterintuitive, and faces resistance from all quarters. You can help by sharing what works, inviting folks to try, and coaching. 

What else have you found that helps? 

Good luck helping! 

The post Overcoming Resistance to Extreme Programming appeared first on Benji's Blog.

Bit of the why

So often I come across the need to avoid my system to block forever, or until a process finishes, I can’t recall how did I came across systemd inhibit, but here’s my approach and a bit of motivation

Motivation

I noticed that the Gnome Settings, come with Rygel

After some fiddling (not much really), it starts directly once I login and I will be using it instead of a fully fledged plex or the like, I just want to stream some videos from time to time from my home pc over my ipad :D using VLC.

The Hack

systemd-inhibit --who=foursixnine --why="maybe there be dragons" --mode block \
    bash -c 'while $(systemctl --user is-active -q rygel.service); do sleep 1h; done'

One can also use waitpid and more.

Thank you for comming to my ted talk.

I think Freeciv has hex tiles earlier than Civilization. Freeciv exists even, when newest Civilization is 3. Perhaps I am not 100% correct in all sentence here, but I only wrote, what I remember about hex tiles. I start play Freeciv even Civilization does not have hex tiles.

There is proof Freeciv supports hex currently and I think it supports it earlier than Civilization. Do not look at Freeciv in web version. Freeciv have many configuration options and on web, it default to rectangle tiles.

Also, Freeciv offers founders and navigable rivers many years after not yet released Civilization 7. There was difference in founders. Founders are special settlers, which create city with two population.

That is all for today.

Dear Tumbleweed users and hackers,

The end is near—the end of 2024, of course. This will be the last weekly review I’ll compose this year, as I’ll be logging off for the next two weeks. But worry not: Tumbleweed will continue rolling as it did in the past. So if you have spare time, feel free to submit your changes when they are ready.

During the last week, we managed to publish 5 snapshots (1213, 1215, 1216, 1217, and 1218), containing these changes:

• KDE Gear 24.12.0
• cURL 8.11.1
• GPG 2.5.2
• KDE Frameworks 6.9.0
• Mozilla Firefox 133.0.3
• lvm 2.03.29
• Ruby Rails 8.0

There are still a few things in the staging areas – whatever is being submitted will be staged. Currently, we are testing these changes:

• Ruby 3.4: subversion test suite fails
• Linux kernel 6.12.5
• systemd 257
• RPM 4.20
• Haskell 9.10

With this, I wish you a great time ahead and will be looking forward to working with you all on Tumbleweed in 2025 again.

The name for this project was updated to Myrlyn on Jan. 9, 2025.

YQPkg, a promising new package management tool for openSUSE, is preparing to make waves in the Linux community.

Designed as a standalone GUI, the software package offers a lightweight, intuitive alternative to traditional tools like YaST for users of openSUSE distributions.

YQPkg provides a glimpse into the future of package management on openSUSE systems. The usable alpha when packaged and released for Tumbleweed and Slowroll will include most of the key features necessary for effective package management.

YQPkg was developed during Hack Week 24 and is a standalone Qt-based package manager, free from YaST dependencies. It supports real package installation, updates, and removals with dependency resolution and user feedback. It’s alpha but usable, with read-only and root modes.

Users can run it as root for full functionality or as a regular user in read-only mode. It features a straightforward progress bar and users can toggle detailed views during operations.

However, some limitations remain. Repository refresh operations and gpg key handling are not yet implemented, so users are advised to manually refresh repositories (sudo zypper ref) before starting the program. YQPkg is still in active development, with known bugs and potential issues; IT IS RECOMMENDED TO AVOID USING IT ON CRITICAL PRODUCTION SYSTEMS AT THIS POINT.

Unlike its predecessor, YQPkg does not depend on YaST infrastructure as it relies only on libzypp. This independence ensures a streamlined experience and reduces some complexity. Libzypp is a C++-based package management library that handles package dependency resolution and management, independent of any graphical user interface framework like Qt.

The tool will introduce flexible summary views, allowing users to review completed tasks or return to previous steps for additional changes. Preferences like summary page settings and countdown timers are saved for future sessions.

Users wanting to explore YQPkg will be able to easily get started upon its release; after refreshing repositories with sudo zypper ref, users can download the latest alpha release and run the tool in either non-root read-only mode or with root permissions for full functionality; this accessibility ensures YQPkg is ready to meet the needs of both casual users and power users alike.

Though still in development, YQPkg is steadily evolving. Future updates promise enhancements like improved error handling, GPG key management, and repository refresh prompts. YQPkg is shaping up for a bright future related to package management within the openSUSE ecosystem.

You can build it from source from its GitHub repo. The current development status and screenshots are available here; scroll down for the latest news.

Introduction This post is part of a series on locally using AI models. Previous posts are Running AI locally Generating images with LocalAI using a GPU Introduction to AI training with openSUSE Adding own Documents to your Local AI Using RAG In the last post I explained how to use RAG to add your own […]

The post Local AI and Confluence appeared first on SUSE Communities.

The release of Leap 15.6 on June 12 set in motion the End of Life for maintenance and security for Leap 15.5, which will happen at the end of December.

Users should upgrade to openSUSE Leap 15.6 to continue to receive security and maintenance updates. Leap versions have a six-month end-of-life period after the release of a new version.

The openSUSE Project is in the development for stage forLeap 16.0 with the pre-Alpha version people can test.

Early adopters and contributors are encouraged to explore this release and provide feedback to shape the next Leap release, which will come with the Agama installer.

Visit get.opensuse.org to try an openSUSE distribution. For users seeking extended support, SUSE offers long-term support options through its subscription services.