> In the coming weeks our Starcraft team (responsible for Snapcraft 2, Rockcraft 5, Charmcraft 1) will begin prototyping debcraft, which will (in time) become the de facto method for creating, testing and uploading packages to the Ubuntu archive.
Hopefully this won't in any way adversely affect development and maintenance of packages for Debian.
Nobody wants embrace-extend-extinguish, nor poaching of volunteers, nor Debian starting to get second-hand packaging that goes to Ubuntu first, etc., even accidentally.
> The Debcrafters must spend the majority of their work time on Ubuntu, but they will be encouraged to spend a day per week contributing to other distributions to gain understanding, and bring fresh perspectives to Ubuntu (and the reverse, hopefully!). This will be structured as a literal day per week, agreed with the team management - for example “I work on NixOS on Tuesdays”.
That's a good open source company practice. And takes some of the edge off of Ubuntu getting so much mileage out of Debian effort, but making the brand all their commercial one.
I'll still continue to be all about Debian Stable, since it's actually been better for production use than Ubuntu has been for me.
jnsgruk · 6h ago
Indeed, we'll need to be very careful to ensure that a new tool doesn't preclude our contribution to Debian, nor complicate our ability to work as a functioning downstream.
Early versions of debcraft will focus on compatibility with the existing format, and aim to help unify workflow across our Ubuntu Developer community.
chupasaurus · 6h ago
> Debian starting to get second-hand packaging that goes to Ubuntu first, etc., even accidentally.
A notorious number of maintaining teams are the same for both distros and there hasn't been a problem I could think of.
> And takes some of the edge off of Ubuntu getting so much mileage out of Debian effort
And if you look on those teams' Debian QA pages you'll see that Sid isn't the upstream, this "mileage" has worked both ways for many years, for example Plasma 5 and 6 updates started in Unstable after they were deployed and ate most of the bugs in Ubuntu.
> I'll still continue to be all about Debian Stable
Which is the reason you probably don't know about the above since all of that work is to get updates into Testing.
neilv · 6h ago
Thank you. I used to use Testing and Unstable, and appreciate immensely the work of all the Debian contributors.
mvdtnz · 4h ago
Isn't the entire point of Debian that we get old second hand known-good stable packages?
jnsgruk · 8h ago
Earlier this year, Canonical’s Ubuntu Engineering organisation gained a new team, seeded with some of our most prolific contributors to Ubuntu. Debcrafters is a new team dedicated to the maintenance of the Ubuntu Archive.
The team’s primary goal is to maintain the health of the Ubuntu Archive, but its unique construction aims to attract a broad range of Linux distribution expertise; contributors to distributions like Debian, Arch Linux, NixOS and others are encouraged to join the team, and will even get paid to contribute one day per week to those projects to foster learning and idea sharing
loloquwowndueo · 7h ago
> others are encouraged to join the team
What are the requirements for joining? Will I be asked about my high-school grades? Pass a psychometric test?
Thanks.
geodel · 7h ago
One of the key requirement is high on sarcasm and low on contribution.
rpcope1 · 5h ago
Maybe that's why they got rid of Stéphane Graber...too much good work done too earnestly and too quietly.
jnsgruk · 6h ago
Yes, candidates for the team will still be expected to go through our usual hiring process.
Twirrim · 5h ago
Here's hoping Canonical leadership will some day finally accept how broken the process is.
Congratulations on making it through that crazy, unscientific process.
NewJazz · 6h ago
Then the project is doomed.
vovavili · 6h ago
Good luck with that.
rbanffy · 7h ago
Does that mean they are reducing work on snaps?
bArray · 7h ago
I wish they would stop with snap, snaps have been nothing but a pain. Ubuntu keep pushing half-baked ideas into the wild - who asked for a system that would randomly kill apps without warning? It's like the Rust SSH thing, they are going to make it the default whether you like it or not, even though they know it is not 1:1 and probably never will be.
I'm currently having an issue with Firefox where it will not stop crashing all of the time, even whilst using Hackernews. Not a RAM or CPU issue, just buggy software pushed through a "move fast and break things" attitude.
loloquwowndueo · 7h ago
Google “remove snaps Ubuntu 24.04” (or whichever version you’re on). I did so, nuked all snaps and replaced Firefox with an upstream Deb repository. Everything’s working fine so far.
bokchoi · 6h ago
Or run PopOS which is Ubuntu without the snaps.
somanyphotons · 7h ago
May as well run Debian at that point
loloquwowndueo · 7h ago
I’ve found that Ubuntu comes with more things set up out of the box than Debian, so it gets me up and running faster. Or could look into Mint. Sure, to each their own - as long as it has no snaps!
stebian_dable · 6h ago
Try Mx Linux :)
blacksmith_tb · 5h ago
On a server, 100% but on a desktop/laptop, Ubuntu does bring some conveniences (though Pop_OS! improves that balance, the good stuff minus the over-dependence on snaps).
rbanffy · 4h ago
> snaps have been nothing but a pain.
I remember being vocal about it being a bad solution to a problem nobody had while I was working for Canonical. That's probably one of the reasons it seems unlikely they'll ever hire me again.
msgodel · 6h ago
It's like they saw RedHat and though "ah the reason people complain about that is because they're just not going fast enough."
simion314 · 7h ago
I like using snap on my LTS servers,
I can test new CLI tools there and see if the new version has soem fixes that I need or not, if the snap works better I can use it without messing around with installing some PPA to update the tool and it's dependencies.
Jnr · 6h ago
What I dislike about snaps is the performance. Somehow they have managed to make them practically unusable on computers older than a few years.
jnsgruk · 6h ago
No, this is an orthogonal effort.
We have two channels for distributing software in Ubuntu: the archive and the snap store. Each are suited to different scenarios.
Irrespective of any view on Snap as a packaging format, the workflow and developer experience is, in my opinion, much simpler to work with. The barrier to contribution is much lower.
The work on debcraft is to try and bring some of the lessons we've learned there to those developers working with debs - while also introducing new primitives that will allow for extended integration testing of the distribution using some of our existing (well tested) machinery.
OsrsNeedsf2P · 7h ago
Nope, they're still pushing it:
> In the coming weeks our Starcraft team (responsible for Snapcraft, Rockcraft 1, Charmcraft) will begin prototyping debcraft, which will (in time) become the de facto method for creating, testing and uploading packages to the Ubuntu archive.
notpushkin · 6h ago
> The first prototype of debcraft will focus on unifying the current workflow adopted by most Ubuntu Developers at Canonical.
Canonical’s debcraft will be a close relation of snapcraft, rockcraft and charmcraft, built using the craft-application and associated libraries.
CoastalCoder · 6h ago
Please rename. No good will come from a name collision here. Especially for two pieces of software in the same problem space.
diggan · 6h ago
> No, that's an unfortunate naming collision.
Unfortunate? Ubuntu developers surely know what exists in Debian already, especially since both of them share the same packaging format (at least originally). They must have realized where the "deb" part of the name comes from, no?
Twirrim · 5h ago
I get how tempting it is to stick with a theme, but you're now running full speed into a name collision in the exact same space that you're attempting to work in. It's probably time to let go of that naming convention.
NewJazz · 6h ago
Not too late to rename.
AdmiralAsshat · 6h ago
> > In the coming weeks our Starcraft team (responsible for Snapcraft 2, Rockcraft 5, Charmcraft 1) will begin prototyping debcraft, which will (in time) become the de facto method for creating, testing and uploading packages to the Ubuntu archive.
Do they play Starcraft?
neogodless · 5h ago
I'm confused. The "-craft" part of this all makes sense. But... why is the team called StarCraft?
Or is it a "star" team that works on their "craft" solutions?
bb88 · 5h ago
I think it makes sense if you see "star" as the unix glob character, "*".
jnsgruk · 5h ago
Starcraft as in *craft, as in they work on all the crafts - the star is a wildcard :)
tonymet · 6h ago
what's Debian's trademark on .deb , debian, and the release names? While I understand Debcrafters technically refers to the .deb format, to the uninitiated it sounds like a Debian project not an ubuntu one.
Debian branding is an important signal of quality. Ubuntu has always seemed like a lower quality product.
chrsw · 3h ago
Hopefully this makes things easier and simpler for users? Not being a Linux application developer or maintainer, I always wondered why we needed snaps, flatpaks, etc when we have .deb packages. I just like doing 'apt install something'. As a user, I prefer one central way to manage software and have the complexity automatically handled behind the scenes. It's great when things are open so I can dig into that stuff if I want to. But I shouldn't really need to.
thesuperbigfrog · 7h ago
Maybe this is more of a Debian question since a lot of Ubuntu packages come from Debian, but what process is used to deprecate unmaintained packages?
If a package is abandoned (i.e. there is no current maintainer), how is it determined if a package should be updated and maintained by Debcrafters or someone else?
Is there any kind of download metrics to know if a package is used?
How would package maintenance be prioritized?
chupasaurus · 6h ago
Here[1][2] are some info of how it works in Debian.
Hopefully this won't in any way adversely affect development and maintenance of packages for Debian.
Nobody wants embrace-extend-extinguish, nor poaching of volunteers, nor Debian starting to get second-hand packaging that goes to Ubuntu first, etc., even accidentally.
> The Debcrafters must spend the majority of their work time on Ubuntu, but they will be encouraged to spend a day per week contributing to other distributions to gain understanding, and bring fresh perspectives to Ubuntu (and the reverse, hopefully!). This will be structured as a literal day per week, agreed with the team management - for example “I work on NixOS on Tuesdays”.
That's a good open source company practice. And takes some of the edge off of Ubuntu getting so much mileage out of Debian effort, but making the brand all their commercial one.
I'll still continue to be all about Debian Stable, since it's actually been better for production use than Ubuntu has been for me.
Early versions of debcraft will focus on compatibility with the existing format, and aim to help unify workflow across our Ubuntu Developer community.
A notorious number of maintaining teams are the same for both distros and there hasn't been a problem I could think of.
> And takes some of the edge off of Ubuntu getting so much mileage out of Debian effort
And if you look on those teams' Debian QA pages you'll see that Sid isn't the upstream, this "mileage" has worked both ways for many years, for example Plasma 5 and 6 updates started in Unstable after they were deployed and ate most of the bugs in Ubuntu.
> I'll still continue to be all about Debian Stable
Which is the reason you probably don't know about the above since all of that work is to get updates into Testing.
The team’s primary goal is to maintain the health of the Ubuntu Archive, but its unique construction aims to attract a broad range of Linux distribution expertise; contributors to distributions like Debian, Arch Linux, NixOS and others are encouraged to join the team, and will even get paid to contribute one day per week to those projects to foster learning and idea sharing
What are the requirements for joining? Will I be asked about my high-school grades? Pass a psychometric test?
Thanks.
Congratulations on making it through that crazy, unscientific process.
I'm currently having an issue with Firefox where it will not stop crashing all of the time, even whilst using Hackernews. Not a RAM or CPU issue, just buggy software pushed through a "move fast and break things" attitude.
I remember being vocal about it being a bad solution to a problem nobody had while I was working for Canonical. That's probably one of the reasons it seems unlikely they'll ever hire me again.
We have two channels for distributing software in Ubuntu: the archive and the snap store. Each are suited to different scenarios.
Irrespective of any view on Snap as a packaging format, the workflow and developer experience is, in my opinion, much simpler to work with. The barrier to contribution is much lower.
The work on debcraft is to try and bring some of the lessons we've learned there to those developers working with debs - while also introducing new primitives that will allow for extended integration testing of the distribution using some of our existing (well tested) machinery.
> In the coming weeks our Starcraft team (responsible for Snapcraft, Rockcraft 1, Charmcraft) will begin prototyping debcraft, which will (in time) become the de facto method for creating, testing and uploading packages to the Ubuntu archive.
Is it the same debcraft as the Debian one? https://salsa.debian.org/debian/debcraft
Canonical’s debcraft will be a close relation of snapcraft, rockcraft and charmcraft, built using the craft-application and associated libraries.
Unfortunate? Ubuntu developers surely know what exists in Debian already, especially since both of them share the same packaging format (at least originally). They must have realized where the "deb" part of the name comes from, no?
Do they play Starcraft?
Or is it a "star" team that works on their "craft" solutions?
Debian branding is an important signal of quality. Ubuntu has always seemed like a lower quality product.
If a package is abandoned (i.e. there is no current maintainer), how is it determined if a package should be updated and maintained by Debcrafters or someone else?
Is there any kind of download metrics to know if a package is used?
How would package maintenance be prioritized?
[1] https://www.debian.org/devel/join/#contributing
[2] https://www.debian.org/devel/wnpp/